A követelést tranzakcióként kell kezelni, nem gombnyomással.
A DAily- jutalom felület egyszerűnek tűnik: naptár megjelenítése, kiemelés ma, és hagyja, hogy a játékos igénye. A nehéz része minden mögött, hogy a gomb. Az ügyfél küldheti ugyanazt a kérést többször. Két szerverek lehet megfigyelni ugyanazt a tárolt állapot. Egy adatsorrend kérés sikertelen után egy része jutalom logika fut. A játékos leválaszthatja között perzisztencia és a prezentáció. Ha a végrehajtás úgy kezeli minden kérelmet, hogy engedélyt adjon, másolja a valuta és a tételek egy várható eredmény, nem pedig egy szélén eset.
A biztonságosabb modell egy szerveralapú tranzakció. Az ügyfél azt kéri, hogy követelje, de soha nem dönti el, hogy a jutalom esedékes-e, mit tartalmaz a jutalom, vagy hogy a támogatás sikerrel járt-e. A szerver a jelenlegi jutalomidőszakot kapja, betölti a hiteles profil állapotot, érvényesíti a konfigurált jutalmat, megkísérel egy atomállami átmenetet, és csak akkor adja vissza az eredményt, amit az ügyfél megjeleníthet.
Ez a szétválasztás a központi szabály: a felhasználói felület kommunikál a szándékkal; a szerver rendelkezik jogosultsággal és mutációval.
A legkisebb autoritatív állapot meghatározása
A napi jutalmak nem igényelnek történelmet minden interfész interakció. Szükségük van elég tartós állapot válaszolni három kérdést: melyik jutalom időszak volt utoljára elkötelezett, mi csík pozíció következik ebből az állapotból, és hogy a jelenlegi kérés tudja-e előre az állam.
A gyakorlati profil általában szüksége van egy stabil időszak kulcs, egy last-succulful-clay kulcs, és egy csík érték. A periódus kulcs kell érkezzen a szerver idő és dokumentált reset politika. Akár a termék újraindul UTC éjfélkor, egy konfigurált regionális határ, vagy a gördülési időtartam után egy termék döntés, de a döntést kell meghatározni a szerveren. Ügyfél órák soha nem határozza meg a jogosultságot.
A konfigurálás elkülönítve marad a játékos állapotától. A beállított naptár meghatározhatja a jutalomazonosítót, a mennyiségeket, a devizaneveket, a szériaviselkedést és az aktív dátumokat. A lejátszónak egy validált konfigurációs verzióra vagy stabil jutalomazonosítóra kell hivatkoznia, ahelyett, hogy önkényes kliens terheléseket másol a tárolóba.
A távirányító hitelesítése a tárolás megkezdése előtt
Roblox biztonsági útmutató kezeli minden értéket átlépve az ügyfél-szerver határ megbízhatatlan. Napi igénylés, a kérés kell szándékosan unalmas. Sok tervezés a szerver nem kell jutalom összeg, csík szám, vagy nap index az ügyfél egyáltalán; ez levezetheti ezeket az értékeket maga.
Az adatsori munka megkezdése előtt a szervernek egy kis visszautasítási láncot kell alkalmaznia:
- a RemoteEvent vagy RemoteFunction tervezett szerveren érkezett kérés megerősítése;
- a nem várt típusok, extra azonosítók vagy hibás terhelések elutasítása;
- rate- limit igénylési kísérletek játékosonként a szerveren;
- ellenőrzi a játékos profilját és rendelkezésre áll a vonatkozó funkció konfigurációja;
- utasítsa vissza a kéréseket, amíg az adott játékosra vonatkozó igényt már helyben feldolgozzák.
Rate limiting nem a kettős-támogatás garancia. Védi a szerver kapacitását, és csökkenti a visszaélést. A tartós garancia továbbra is túléli két szerver, retry, reconnects, és a folyamat újraindul.
A támogathatóság és a kötelezettségvállalás egy atomfrissítéssel
A 'GetAsync ()' később a 'SetAsync ()' kihagy egy versenyablakot. Két szerver is el tudja olvasni ugyanazt az ismeretlen állapotot, mindkettő úgy dönt, hogy a játékos jogosult, és mindketten írjanak egy támogatást. Roblox dokumentumok "UpdateASync ()", mint a biztonságosabb multi- szerver művelet, mert olvassa a jelenlegi értéket, és próbálja újra a visszahívást, ha az egyidejű frissítések konfliktus.
Helyezze a támogathatósági döntést az atomfrissítésbe. A visszahívás megkapja a legújabb tárolt értéket, ellenőrzi, hogy a jelenlegi időszakot már lekötték-e, és vagy egy új állapotot vagy egy nullát ad vissza. A visszahívás nem jöhet létre, így nem hívhat külső szolgáltatásokat, nem várhatja meg az eseteket, vagy maga hajthatja végre a látható jutalmat.
A lekötött államnak tartalmaznia kell egy tartós támogatási jelölőt: a jutalomidőszak és a stabil jutalomazonosító vagy tranzakciós kulcs, amely megnyerte a frissítést. Ha a visszahívás már felfedezi, hogy a marker létezik, a helyes eredmény "már kérelmezett", nem pedig egy másik támogatás.
Ez a minta az ismétlődő kéréseket ugyanazon eredmény ismételt olvasatává alakítja át. Az első érvényes átmenet nyer. Később megpróbálja megfigyelni az elkötelezett jelölőt, és nem működik.
A perzisztencia és a jutalom kézbesítése közötti szakadék megszüntetése
Atomic profile state megakadályozza a két követelés átmenetet, de a design még mindig szüksége van egy egyértelmű szállítási megbízás. Ha a valuta hozzáadása előtt a követelés marker tartós, egy adatsori hiba hagyhat értéket nem rekord. Ha a marker tárolására először, és a szerver összeomlik a szállítás előtt, a játékos lehet egy elkötelezett követelés nélkül a tételt.
A megbízható válasz egy idempotens támogatási rekord. A tranzakciós azonosító és a szállítási állapot, majd tegye jutalom szállítás biztonságosan megismételni az azonosítót. Pénznem, leltár, jelvény, vagy jogosultsági szolgáltatások fel kell ismernie, hogy egy adott tranzakció már alkalmazták. A helyreállítási útvonal ellenőrizheti a kötelezettséget-but-delivered rekordok, és próbálja meg őket anélkül, hogy egy második jutalom.
Nem minden tapasztalatra van szükség egy összetett főkönyv, de minden tapasztalatra kell egy explicit választ a részleges kudarc kérdés. "A kérés valószínűleg befejeződik" nem garancia.
Tartózkodási műveleti megbízás a relék során
A Datastore hívások sikertelenek lehetnek, és az LiveOps Goblin futásidõ alapítvány biztonságos adatsori csomagolást használ relével és háttérrel. Az ismétlés nem ugyanaz, mintha ugyanazt a műveletet több független feladatból küldenénk újra. Roblox figyelmeztet arra, hogy a naiv regtries visszaállíthatja a tekintélyes műveleteket.
Használjon egy sorozatos igénylési útvonalat játékosonként, őrizze meg a profilváltozások sorrendjét, és tartsa stabilan az ügyleti azonosítót a visszafordítások során. Csak a hibásan végrehajtott műveletet próbálja meg visszaállítani a kijelölt mentéssel. Ne számítson ki egy új jutalomidőszakot vagy tranzakciós kulcsot minden egyes kísérletnél. Ha a játékos elhagyja, akkor a tartós helyreállítást a tárolt állapotból kell folytatni, nem pedig egy inmemóriás zászlóból.
A diagnosztikának meg kell különböztetnie az elutasított kérelmeket, a kamatlábkorlátokat, az adatsorokra vonatkozó figyelmeztetéseket, a már bejelentett eredményeket, az elkötelezett követeléseket és a teljesítés helyreállítását. Ezek az események operatív bizonyítékok; nem fedhetnek fel titkokat vagy nem készíthetnek tevékenységet, ha nincs analitikus szolgáltató konfigurálva.
A konfiguráció biztonságos marad, mielőtt elérné a játékot
A kétszeres védelem meggyengül, ha maga az exportált jutalomnaptár kétértelmű. LiveOps Goblin érvényesül lehetetlen mennyiségek, hiányzó datastore kulcsok, kétértelmű devizanemek, duplikált kódok, és lejárt ütemezés előtt egy reverzibilis Roblox konfiguráció.
A jutalom definíció kell használni stabil azonosítók, határolt mennyiségek, ismert valuta vagy leltár célok, explicit menetrend szabályok, és egy verzió, amely nyomon követhető a diagnosztika. Üres naptárak kell üresnek maradni, amíg az alkotó hozzáad valódi jutalmak. Demo értékek a gyártási konfiguráció veszélyesebb, mint egy őszinte üres állam, mert azok lehetnek reálgazdasági mutációk.
Amikor egy naptár változik, döntse el, mi történik a játékosok középszériája. Stabil jutalom azonosítók és reverzioned konfiguráció teszi, hogy a politika tesztable. Pozíció-csak feltételezések könnyebbé teszi a "harmadik nap", hogy hivatkozzon a különböző jutalmak előtt és után frissítést.
Tesztelje a hibákat, nem csak a boldog utat.
A hasznos daily- jutalom teszt mátrix kell több, mint "igény egyszer és kap érmék". Legalább, gyakorolni:
- ugyanazon ügyfél két gyors kérése;
- két szerver közötti kapcsolat kérései ugyanazon tárolt profilhoz képest;
- a már vállalt időszakra vonatkozó követelés;
- hibás, távoli terhelések és az ár-limit viselkedés;
- adatsori konfliktus, átmeneti meghibásodás és kimerült újrafeldolgozási útvonalak;
- az ügyfél visszaigazolása előtt, de az elkötelezettség után szüntesse meg a kapcsolatot;
- a szállítás újraindítása ugyanazon ügyleti azonosító használatával;
- naptár verzióváltoztatás aktív széria alatt;
- hiányzó vagy érvénytelen jutalomkonfiguráció;
- A diagnosztikával letiltott analitikusok még működnek.
A várt eredmény nem csupán "nem összeomlik". Minden tesztnek a végleges tartós állapotot, az alkalmazott támogatások számát, az ügyfél-látható eredményt és a diagnosztikai eseményt kell érvényre juttatnia.
Egy tömör végrehajtási ellenőrző lista
A végleges design lehet felülvizsgálni tíz kérdést. A jogosultság származtatott a szerveren? Az újraindítási idő determinista? Vajon az ügyfél küld csak szándékkal? Vannak távoli kérések validált és szerver- rate- korlátozott? Van-e a követelés átmenet atomi? Vajon a tárolt állapot tartalmazza a stabil tranzakciós marker? Lehet jutalmazás szállítás ismétlődik átfedések nélkül?
Amikor mind a tíz válasz konkrét, a napi jutalom megszűnik, hogy egy törékeny gombkezelő, és válik egy kis, érthető LiveOps tranzakció.
