Kohtele vaadetta liiketoimena, ei painiketta painamalla
Päivittäinen palkitseminen käyttöliittymä näyttää yksinkertaiselta: näytä kalenteri, Korosta tänään, ja anna pelaajan väittää. Vaikea osa on kaikki takana että painike. Asiakas voi lähettää saman pyynnön toistuvasti. Kaksi palvelinta voi tarkkailla samaa tallennettu tila. Datasto pyyntö voi epäonnistua, kun osa palkita logiikka on toiminut. Pelaaja voi irrottaa välillä pysyvyys ja esitystapa. Jos toteutus käsittelee kunkin pyynnön luvan myöntää, kaksoisvaluutta ja kohteet ovat odotettu tulos eikä reuna tapauksessa.
Turvallisempi malli on palvelin-omistettu tapahtuma. Asiakas pyytää vaatia, mutta se ei koskaan päätä, onko palkkion on määrä, mitä palkkio sisältää, tai onko apuraha onnistunut. Palvelin saa nykyisen palkitsemisjakson, lataa arvovaltaisen profiilin tilan, validoi konfiguroidun palkkion, yrittää yhden atomivaltion siirtymän, ja vasta sitten palauttaa tuloksen, jonka asiakas voi näyttää.
Tämä erottaminen on keskeinen sääntö: käyttöliittymä kommunikoi tahallaan; palvelimella on kelpoisuus ja mutaatio.
Määrittele pienin arvovaltainen valtio
Päivittäiset palkinnot eivät tarvitse historian jokaisen käyttöliittymän vuorovaikutuksen. Ne tarvitsevat tarpeeksi kestävä tila vastatakseen kolmeen kysymykseen: mikä palkitsemisaika oli viimeksi sitoutunut, mikä juova asema seuraa kyseisestä valtiosta, ja voiko nykyinen pyyntö siirtää valtiota eteenpäin.
Käytännön profiili tarvitsee yleensä vakaan ajanjakson avaimen, viimeisen onnistuneen vaateen avaimen ja viivan arvon. Aika-avaimen tulisi tulla palvelinajasta ja dokumentoidusta nollauskäytännöstä. Olipa tuote nollataan keskiyöllä, konfiguroidulla aluerajalla tai rullaavan keston jälkeen on tuotepäätös, mutta päätöksen tulee olla deterministinen palvelimella. Asiakaskellojen ei tulisi koskaan määrittää kelpoisuus.
Pidä konfiguraatio erillään pelaajan tilasta. Määritellyssä kalenterissa voidaan määritellä palkitsemistunnisteet, määrät, valuutan nimet, juovakäyttäytyminen ja aktiiviset päivämäärät. Pelaajan tilan tulisi viitata validoituun konfiguraatioversioon tai vakaaseen palkitsemistunnisteeseen sen sijaan, että kopioitaisiin mielivaltaisia asiakaskuormia.
Vahvista kaukosäädin ennen kuin kosketat tallennustilaa
Roblox:n turvallisuusohjeistus kohtelee jokaista asiakaspalvelinrajan ylittävää arvoa epäluotettavana. Päivittäisen väitteen osalta pyynnön pitäisi olla tarkoituksellisesti tylsä. Monissa malleissa palvelimen ei tarvitse palkkiosummaa, putkinumeroa tai päiväindeksiä asiakkaalta lainkaan; se voi saada nämä arvot itse.
Ennen kuin datakauppatyö alkaa, palvelimen tulisi soveltaa pientä hylkäysketjua:
- vahvistaa aiotulle palvelimelle saapuneen pyynnön RemoteEvent tai RemoteFunction;
- hylkäävät odottamattomat tyypit, lisätunnisteet tai epämuodostuneet hyötykuormat;
- hintarajoitusvaatimusyritykset pelaajaa kohti palvelimella;
- varmistaa, että pelaajan profiili ja merkitykselliset ominaisuudet ovat saatavilla;
- hylkää pyynnöt samalla kun kyseistä pelaajaa koskeva vaatimus käsitellään jo paikallisesti.
Hintarajoitus ei ole kaksinkertaisen tuen takuu. Se suojaa palvelinkapasiteettia ja vähentää väärinkäytöksiä. Kestävä takuu on edelleen hengissä kaksi palvelinta, retries, uudelleen yhteydet, ja prosessi käynnistyy uudelleen.
Tehdä tukikelpoisuus ja sitoumus yksi atomipäivitys
`GetAsync()`-kutsun jälkeen myöhemmin tehtävä `SetAsync()`-kutsu jättää tilaa kilpailutilanteelle. Kaksi palvelinta voi lukea saman tilan, jossa palkintoa ei vielä ole lunastettu, todeta molemmat pelaajan olevan oikeutettu palkintoon ja kirjata kumpikin palkinnon myöntämisen. Robloxin dokumentaatio suosittelee `UpdateAsync()`-kutsua turvallisemmaksi operaatioksi usean palvelimen tilanteissa, koska se lukee nykyisen arvon ja suorittaa takaisinkutsun uudelleen, jos samanaikaiset päivitykset ovat ristiriidassa.
Aseta kelpoisuuspäätös atomipäivityksen sisälle. Callback saa viimeisimmän tallennetun arvon, tarkistaa, onko nykyinen kausi on jo sitoutunut, ja palauttaa joko uuden valtion tai . Callback ei saa tuottaa, joten se ei saa soittaa ulkoisia palveluja, odottaa tapauksia, tai suorittaa näkyvä palkkio avustus itse.
Sitoumusvaltiossa tulisi olla kestävä apurahamerkki: palkkioaika ja vakaa palkkion tunniste tai tapahtuma-avain, joka voitti päivityksen. Jos takaisinkutsu havaitsee, että merkki on jo olemassa, oikea tulos on jo aiemmin esitetty, ei toinen apuraha.
Tämä malli muuntaa toistuvat pyynnöt toistuvia lukee saman tuloksen. Ensimmäinen voimassa siirtymä voittaa. Myöhemmin yritykset tarkkailla sitoutunut merkki ja tulla ei-ops.
Kavenna sinnikkyyden ja palkitsemisen välistä kuilua
Atomiprofiilin tila estää kaksi vaateen siirtymää, mutta malli tarvitsee silti selkeän toimitusmääräyksen. Jos valuutta lisätään ennen kuin korvausmerkki on kestävä, tietovaraston virhe voi jättää arvo myönnetty ilman tietuetta. Jos merkki tallennetaan ensin ja palvelin kaatuu ennen toimitusta, pelaaja voi olla sitoutunut vaatimus ilman kohdetta.
Vahva vastaus on idemopotentti avustusrekisteri. Toimita tapahtumatunniste ja toimitusvaltio, sitten tehdä palkintotoimitus turvallinen toistamaan tätä tunnistetta vastaan. Valuutta, inventaario, merkki tai oikeutuspalvelut pitäisi tunnistaa, että tietty tapahtuma on jo sovellettu. Takaisinperintäpolku voi tarkastaa sidotut mutta toimittamatta kirjaa ja yrittää niitä uudelleen luomatta toista palkintoa.
Kaikki kokemukset eivät tarvitse monimutkaista tilikirjaa, mutta jokainen kokemus tarvitsee selkeän vastauksen osittaiseen virheeseen.
Säilytä toimintatilaus korjausten aikana
Datastore-puhelut voivat epäonnistua, ja LiveOps Goblin-runtime-säätiö käyttää turvallista käärepaperia, jossa on uusinta- ja backoff-käyttäytyminen. Yrittäminen ei ole sama asia kuin saman toiminnon lähettäminen uudelleen useista itsenäisistä tehtävistä. Roblox varoittaa siitä, että naiivit retries voi tilata uudelleen tilauksia.
Käytä yhtä sarjaistettua korvauspolkua pelaajaa kohti, säilytä profiilin muutosten järjestys ja pidä tapahtuman tunniste vakaana retriesissä. Yritä uudelleen vain epäonnistunutta operaatiota, jossa on rajoitettu backoff. Älä hyvitä uutta palkitsemisjaksoa tai tapahtuma-avainta jokaisesta yrityksestä. Jos pelaaja lähtee, pysyvän palautuksen pitäisi voida jatkua tallennetusta tilasta eikä muistin sisäisestä lipusta.
Diagnostiikassa olisi erotettava hylätyt pyynnöt, nopeusrajat, tietovarastovaroitukset, jo perityt tulokset, sitoumukset ja toimitukset. Nämä tapahtumat ovat toiminnallisia todisteita; ne eivät saa paljastaa salaisuuksia tai faktaa toimintaa, kun analytiikan tarjoajaa ei ole määritetty.
Pidä konfiguraatio turvallinen ennen kuin se saavuttaa pelin
Kaksinkertaista suojausta heikennetään, kun vientipalkkiokalenteri itsessään on epäselvä. LiveOps Goblin validoi mahdottomia määriä, puuttuu datakaupan avaimet, epäselvät valuutan nimet, kaksoiskoodit ja vanhentuneet aikataulut ennen versioidun Roblox:n konfiguroinnin tuottamista.
Palkkion määritelmässä olisi käytettävä vakaita tunnisteita, rajoitettuja määriä, tunnettuja valuutta- tai varastotavoitteita, selkeitä aikataulusääntöjä ja versiota, joka voidaan jäljittää diagnostiikkaan. Tyhjien kalenterien olisi pysyttävä tyhjinä, kunnes luoja lisää todellisia palkintoja. Demo-arvot tuotantokonfiguraatiossa ovat vaarallisempia kuin rehellinen tyhjä tila, koska niistä voi tulla reaalitalouden mutaatioita.
Kun kalenteri muuttuu, päätä, mitä tapahtuu pelaajille puolivälissä-streak. Vakaat palkita tunnisteet ja versioidut asetukset tekevät tästä politiikan testattavissa. Position-vain oletukset tekevät helpoksi viitata eri palkitsemista ennen ja jälkeen päivityksen.
Testaa epäonnistumisia, ei vain onnellinen polku
Hyödyllinen päivittäisen palkitsemisen testimatriisi tulisi sisältää enemmän kuin ... claim kerran ja vastaanottaa kolikoita... vähintään, käyttää:
- kaksi saman asiakkaan nopeaa pyyntöä;
- pyynnöt kahdelta palvelimelta samassa tallennetussa profiilissa;
- vaatimus, joka koskee jo sidottua ajanjaksoa;
- epämuodostuneet kaukokuormat ja nopeusrajoituskäyttäytyminen
- tietovaraston ristiriidat, ohimenevät viat ja uupuneet uudelleenreitit;
- katkaista yhteyden sitoumuksen jälkeen, mutta ennen asiakkaan vahvistusta;
- toimitusta yritetään uudelleen käyttäen samaa tapahtumatunnistetta;
- kalenteriversion muutos aktiivisen putkiston aikana;
- puuttuva tai virheellinen palkkion määritys;
- analytiikka ei toimi diagnostiikalla.
Odotettu tulos ei ole pelkästään kaatumisia...Jokaisessa testissä pitäisi vahvistaa lopullinen kestävä tila, apurahojen määrä, asiakkaan näkymätön tulos, ja diagnostinen tapahtuma.
Lyhyitä täytäntöönpanoluetteloita
Viimeinen suunnittelu voidaan tarkistaa kymmenen kysymystä. Onko tukikelpoisuus johdettu palvelimella? Onko nollausaika deterministinen? Lähettääkö asiakas vain tarkoitus? Ovatko etäpyynnöt validoitu ja palvelin-nopeus rajoitettu? Onko vaatimus siirtymä atomi? Onko tallennettu tila sisältää vakaa tapahtumamerkki? palkinto toimitus voidaan toistaa ilman päällekkäisyyttä? Onko uusintaa säilyttää tilaus? Onko konfiguraatiot versioitu ja validoitu? Onko concurrency ja osittainen viallinen testit todistavat täsmälleen yksi kestävä apuraha?
Kun kaikki kymmenen vastausta ovat konkreettisia, päivittäinen palkkio lakkaa olemasta hauras painikkeen käsittelijä ja tulee pieni, ymmärrettävä LiveOps tapahtuma.
