Behandle et krav som en transaksjon, ikke et knapptrykk
Et daglig gevinstgrensesnitt ser enkelt ut: vis en kalender, behev i dag, og la spilleren hevde. Den vanskelige delen er alt bak den knappen. En klient kan sende samme forespørsel gjentatte ganger. To servere kan observere samme lagrede tilstand. En datalagringsforespørsel kan mislykkes etter at en del av belønningslogikken har kjørt. En spiller kan koble fra mellom utholdenhet og presentasjon. Hvis gjennomføringen behandler hver forespørsel som tillatelse til å gi, duplisere valuta og elementer er et forventet resultat i stedet for et kant tilfelle.
Den sikrere modellen er en servereide transaksjon. Kunden ber om å hevde, men det bestemmer aldri om en belønning skal betales, hva belønningen inneholder, eller om bidraget lykkes. Serveren utledes den gjeldende belønningsperioden, laster autoritative profiltilstanden, validerer den konfigurerte belønningen, prøver en atomtilstandsovergang, og returnerer bare et resultat som klienten kan vise.
Denne separasjonen er den sentrale regelen: brukergrensesnittet kommuniserer intensjon; serveren eier kvalifiserthet og mutasjon.
Definere den minste autoritative staten
Daglige belønninger trenger ikke en historie over alle grensesnitt interaksjon. De trenger nok holdbar tilstand til å svare på tre spørsmål: hvilken belønningsperiode som sist ble begått, hvilken streakposisjon som følger av den staten, og om den nåværende forespørselen kan flytte staten fremover.
En praktisk profil trenger vanligvis en stabil periodenøkkel, en siste suksessfull gjenopprettingsnøkkel og en streikverdi. Periodenøkkelen skal komme fra servertid og en dokumentert tilbakestillingspolicy. Om produktet tilbakestilles ved UTC midnatt, ved en konfigurert regional grense, eller etter en rullende varighet er en produktbeslutning, men beslutningen må være deterministisk på serveren. Kundeklokker bør aldri bestemme kvalifisering.
Hold konfigurasjonen adskilt fra spillertilstand. Den konfigurerte kalenderen kan definere belønningsidentifikatorer, mengder, valutanavn, streikadferd og aktive datoer. Spillertilstanden bør referere til en validert konfigurasjonsversjon eller stabil belønningsidentifikator i stedet for å kopiere vilkårlige klientlaster til lagring.
Valider fjernkontrollen før du berører lagringen
Roblox sikkerhetsveiledning behandler hver verdi som krysser klient-server grensen som upålitelig. For et daglig krav, bør forespørselen være bevisst kjedelig. I mange design serveren trenger ingen belønningsbeløp, streikenummer eller dagindeks fra klienten i det hele tatt; det kan hente disse verdiene i seg selv.
Før datalagringsarbeidet starter, bør serveren bruke en liten avvisningskjede:
- bekrefte forespørselen som ankom på den tiltenkte serveren RemoteEvent eller RemoteFunction;
- avvise uventede typer, ekstra identifikatorer eller feilaktige nyttelaster;
- satsgrensekravsforsøk per spiller på serveren;
- verifisere spillerprofilen og relevant funksjonskonfigurasjon er tilgjengelig;
- Avslå forespørsler mens et krav for den spilleren allerede behandles lokalt.
Prisbegrensning er ikke duplikat-garantien. Den beskytter serverkapasiteten og reduserer misbruk. Den holdbare garantien må fortsatt overleve to servere, retries, reconnects og prosessen starter på nytt.
Gjør begrunnelse og engasjement én atomoppdatering
En «GetAsync()» etterfulgt senere av «SetAsync()» forlater et løpsvindu. To servere kan lese den samme uavklarte tilstanden, begge bestemmer spilleren er kvalifisert, og begge skriver et bidrag. Roblox dokumenterer «UpdateAsync()» som den tryggere multi-server-operasjonen fordi den leser den gjeldende verdien og retrierer tilbakekallingen når samtidig oppdateringer konflikt.
Sett begrunnelsesbeslutningen inne i den atomoppdateringen. Tilbakekallelsen mottar den nyeste lagrede verdien, sjekker om den aktuelle perioden allerede er utført, og returnerer enten en ny tilstand eller «nil» for å kansellere. Tilbakekallelsen må ikke gi, så den bør ikke ringe eksterne tjenester, vente på forekomster eller utføre det synlige belønningstilskuddet selv.
Den forpliktede staten bør inneholde en varig tilskuddsmarkør: belønningsperioden og den stabile belønningsidentifikatoren eller transaksjonsnøkkelen som vant oppdateringen. Hvis tilbakekallingen oppdager at markøren allerede eksisterer, er det riktige resultatet \"foreløpig hevdet\", ikke et annet bidrag.
Dette mønsteret konverterer gjentatte forespørsler til gjentatte leser av det samme resultatet. Den første gyldige overgangen vinner. Senere forsøk på å observere den forpliktede markøren og bli ingen-ops.
Lukk gapet mellom utholdenhet og belønningslevering
Atomisk profiltilstand hindrer to kravoverganger, men utformingen trenger fortsatt en klar leveringsordre. Hvis valutaen legges til før kravmarkøren er varig, kan en datalagringsfeil forlate verdi som er gitt uten rekord. Hvis markøren lagres først og serveren krasjer før levering, kan spilleren ha et forpliktet krav uten elementet.
Det robuste svaret er en idempotensiell tildelingspost. Legg inn en transaksjonsidentifikator og en leveringstilstand, og gjør deretter belønningslevering trygt å gjenta mot den identifikatoren. Valuta, lager, merke eller rettighetstjenester bør erkjenne at en bestemt transaksjon allerede har blitt anvendt. En gjenopprettingssti kan inspisere dedikert-men-undeleverte poster og prøve dem på nytt uten å skape en annen belønning.
Ikke alle erfaringer trenger en kompleks leder, men hver opplevelse trenger et eksplisitt svar på det delvise feilspørsmålet. \"Forespørselen er sannsynligvis fullført\" er ikke en garanti.
Bevar driftsordre under retries
Datalagringssamtaler kan mislykkes, og LiveOps Goblin kjøretid foundation bruker en sikker datalagrings wrapper med reprøve og backoff atferd. Forsøk er ikke det samme som å sende den samme operasjonen igjen fra flere uavhengige oppgaver. Roblox advarer om at naive retries kan omorganisere statlige operasjoner.
Bruk en serierisert kravsti per spiller, bevar rekkefølgen av profilendringer, og hold transaksjonsidentifikatoren stabil på tvers av retries. Prøv bare den mislykkede operasjonen med avgrenset backoff. Ikke reberegn en ny belønningsperiode eller transaksjonsnøkkel på hvert forsøk. Hvis spilleren forlater, bør holdbar gjenoppretting kunne fortsette fra lagret tilstand i stedet for fra et minneflagg.
Diagnostiske bør skille avviste forespørsler, satsgrenser, datalagringsadvarsler, allerede innhentede utfall, engasjerte krav og leveringsgjenvinning. Disse hendelsene er operasjonelle bevis; de bør ikke avsløre hemmeligheter eller fabrikere aktivitet når ingen analyseleverandør er konfigurert.
Hold konfigurasjonen trygg før den når spillet
Duplikatbeskyttelse er svekket når den eksporterte belønningskalenderen i seg selv er tvetydig. LiveOps Goblin validerer umulige mengder, manglende datalagringsnøkler, tvetydige valutanavn, dupliserte koder og utløpte tidsplaner før du produserer en versjon av Roblox konfigurasjon.
En belønningsdefinisjon bør bruke stabile identifikatorer, avgrensede mengder, kjente valuta- eller lagermål, eksplisitte tidsplanregler og en versjon som kan spores i diagnostikk. Tomme kalendere bør forbli tomme til en skaper legger til reelle belønninger. Demoverdier i produksjonskonfigurasjon er farligere enn en ærlig tom tilstand fordi de kan bli reell økonomi mutasjoner.
Når en kalender endres, bestemmer du hva som skjer med spillere midt i streak. Stabile belønningsidentifikatorer og versjonskonfigurasjon gjør den policyen testbar. Stilling-bare antakelser gjør det enkelt for \"dag tre\" å referere til ulike belønninger før og etter en oppdatering.
Test feilene, ikke bare den lykkelige veien
En nyttig daglig-belønnet testmatrise bør inneholde mer enn \"krav en gang og motta mynter.\" I det minste trening:
- to raske forespørsler fra samme klient;
- forespørsler fra to server sammenhenger mot den samme lagrede profilen;
- et krav i en periode som allerede er inngått,
- feilutformede eksterne nyttelaster og hastighetsgrenseadferd;
- Datalagringskonflikt, forbigående svikt og utmattet gjenforsøksstier;
- frakoble etter forpliktelse, men før klientbekreftelse;
- leveringsprøve på nytt med den samme transaksjonsidentifikatoren;
- en kalenderversjon endring under en aktiv streik;
- en manglende eller ugyldig belønningskonfigurasjon;
- Analyser deaktivert med diagnostikk som fortsatt fungerer.
Det forventede resultatet er ikke bare \"ingen krasj.\" Hver test bør hevde den endelige holdbare tilstanden, antall stipend som brukes, det klient-synlige utfall og den diagnostiske hendelsen.
En koncis implementeringssjekkliste
Den endelige designen kan gjennomgås med ti spørsmål. Er begrunnelse avledet på serveren? Er tilbakestillingstid deterministisk? Sender klienten kun hensikt? Er eksterne forespørsler validert og server-rate-begrenset? Er kravet overgang atom? Har den lagrede staten en stabil transaksjonsmarkør? Kan belønningslevering gjentas uten duplikasjon? Bevarer retries bestilling? Er konfigurasjoner versjon og validert? Betyr koncurrency og partiell-feil-tester nøyaktig én holdbart bidrag?
Når alle ti svarene er konkrete, slutter en daglig belønning å være en skjøre knapphåndterer og blir en liten, forståelig LiveOps-transaksjon.
