Sono Katie McCaffrey Sono un distribuito
ingegnere dei sistemi è la mia felpa da discoteca
Io programma in questo a volte quindi lavoro a
il Twitter è attualmente attivo
infrastruttura e piattaforma specificamente
osservabilità e ho appena entrato in
Gennaio e vivo a San Francisco
prima però ho passato sei sei
più anni di lavoro nel nostro team in
industria su giochi come anni di guerra due
e tre e poi halo 4 è l’unico
che ho trascorso la maggior parte del mio tempo su
costruire come servizi e networking
e sistemi distribuiti che essenzialmente
alimenta molto l’ intrattenimento
Esperienza che quando accendi il tuo
xbox e inizia a giocare che vedi così
questo è il mio Twitter e ho un blog tecnologico
se vuoi parlare con me sul
internet lo farei quindi sentiti libero okay
così come ho detto, ho lavorato in aureola
nel 2010 quando 343 Industries era uno studio
creato all’interno di Microsoft per prendere in consegna
il franchise di Halo di Bungie che
deciso che vogliono andare a fare altri giochi
e hanno appena reso il destino giusto così io
era come il servizio web numero due
assunto in questo piccolo studio a 30 anni
le persone a capire cosa avremmo fatto
fare con questo vecchio stack halo perché il
i giochi originali avevano i servizi che c’erano
come l’ alone uno due tre e poi raggiungere
e ODST aveva tutti servizi aggiuntivi a
aiutarti a giocare e vivere il gioco
ma erano si conosce il modo in cui siamo stati
usato per costruire vecchi servizi dove tu
ha avuto il gioco parlando con un servizio statico
che puoi semplicemente scalare in modo lineare
fuori e poi hai avuto un sequel gigante
database che tutto ciò che ospitava il
fonte di verità per tutti come Halo tutto
dei giochi di Halo e così ci siamo resi conto
quello che non sarebbe andato in scala per noi
quando abbiamo visto cosa volevamo fare
per Halo four e il futuro del
franchising andando avanti così come sapevamo
o abbiamo effettivamente colpito i numeri di 1,5
Miliardi di giochi per Halo 4 giocati e poi
11,6 milioni di utenti unici e così via
non si adatterebbe su un singolo gigante
sequel database più così siamo finiti
andando e riscrivendo tutti i servizi e
spostandoci verso il cloud di Ezra e siamo finiti
utilizzando il table store di Azure come nostro
la più grande forma di memoria senza sequel simile
e quindi questo è un valore fondamentale per
quelli di voi che non hanno familiarità con esso
e così ora in questo mondo abbiamo avuto questo
sfida dove eravamo abituati a fare cose
con transazioni su un singolo database
dato che siamo abituati alla programmazione
contro le transazioni su questo
database e che ha mantenuto il nostro sistema
coerente e questo è stato davvero bello ma
ora non abbiamo più avuto questo perché tutti
i nostri dati sono stati suddivisi su più punti
partizioni quindi abbiamo deciso di pensarci
davvero difficile su come vogliamo farlo
per me pensare davvero è difficile
decisamente come andare in un bar e
leggendo un sacco di carte e bevendo
bourbon ma ci siamo imbattuti nella saga
modello che è una carta che era
pubblicato nel 1987 che dirò
voi ragazzi e in realtà siamo andati
implementato in modo che potessimo
elaborare le statistiche in una sorta di a
modo transazionale e lo sto usando in
citazioni perché ne stiamo rinunciando
le cose se lo vedete in una casa parlano noi
non abbiamo la possibilità di serializzare
rinunciare ad alcune cose ma dà
noi un modo per garantire coerenza come
dall’inizio alla fine del
transazione e cosa fare in caso di fallimento
scenari quindi parlerò con voi ragazzi
oggi le saghe ti danno un po ‘
di motivazione per il motivo per cui ne abbiamo bisogno e
allora parleremo del documento originale
il suo contributo al distribuito o
allo spazio del database perché
in realtà è venuto fuori che la sua data
comunità e poi parleremo di come
lo fai in un mondo distribuito
perché è un po ‘diverso
ci sono ulteriori sfide e
vincoli che è necessario imporre e
allora parleremo di come effettivamente
ha fatto questo in Halo 4 ok così giusto come il nostro
i sistemi utilizzati per essere molto semplici sono stati utilizzati
essere in grado di avere come un’app o un
sito web che ha parlato con un apolide
servizio e parlato con questo gigante
database canonico fonte di verità e
quindi hai le transazioni che hai
serializza abilità e acido in modo corretto
la serializzabilità è la nostra garanzia
le cose sembrano come se accadessero
sequenzialmente a Thomas City è questa idea
che sia successo o no
e non vediamo lo stato delle cose
in elaborazione tra coerenza
è la consistenza a livello di applicazione che è
non linearizzare la consistenza dell’abilità ma
è fondamentalmente che il nostro sistema è ancora
in uno stato valido dopo che abbiamo noi quando
abbiamo iniziato la transazione alla fine
della transazione il sistema è in a
stato valido e che sia come
totalmente se la transazione
completato o non isolato è quello
queste transazioni non influiscono su ciascuna
altro se sono in esecuzione contemporaneamente
e quindi la durabilità è questa idea
una volta che abbiamo commesso qualcosa
persiste in così tanto tempo e come noi
non perdere i dati così bene ma ora siamo
in questo mondo abbiamo un servizio orientato
architetture e micro servizi e tu
non avere fonti di verità canoniche
più spesso
quando scriviamo le applicazioni che eravamo
interagire con magari un po ‘della nostra
api o stiamo interagendo con qualcuno
le altre API e usarle e così noi
in realtà non possono e hanno tutti il loro
proprio negozi di supporto giusto quindi non c’è
come una fonte canonica di verità noi
non ottenere più le transazioni, semplicemente
non posso averli e così alcuni modi
abbiamo provato a risolvere il distribuito
problema di transazione come commit a due fasi
così il commit a due fasi è un atomico
protocollo di impegno e in fondo è a
versione specializzata del consenso
protocollo quindi a volte va bene e
è stato implementato e fatto in piccolo
scala e in fondo vado molto
rapidamente attraverso di esso ma hai un
prepara la fase in cui avrai un singolo
coordinatore il coordinatore è molto
speciale nel sistema è un singolo
punto di errore e lui proporrà di
tutte le risorse coinvolte, ehi
andando a fare questa cosa e poi tutto
le risorse arrivano a votare sì, voglio
fai questa cosa o no non voglio farlo
questa cosa e il coordinatore raccoglie
tutti i voti
così una volta che il coordinatore ha ricevuto tutto
dei voti ora entriamo nel commit
fase e se tutti hanno detto sì allora
diciamo andare e fare il commit della transazione
e così è così che ottengono
atomicità perché tutti stanno commettendo
allo stesso tempo o se qualcuno dice di no
poi dicono di non farlo bene così
non c’è stato come dove potresti
avere l’auto riservata e non avere il
hotel riservato nella tua app di viaggio
tutti alla fine devono dire fatto
ordine in un vero sistema distribuito così
che puoi conoscere al coordinatore
cosa è successo , questo è un po ‘
bello e questo è in realtà la gente usa
questo ma in realtà non scala tutto
quel bene e le condizioni di fallimento che puoi
avere fino a Oh N messaggi al quadrato in corso
attraverso il tuo sistema è il tuo coordinatore
ancora una volta un singolo punto di rottura quindi
se quella cosa muore in qualsiasi momento durante
la transazione come se fosse appena abortita
e così più risorse hai
più latenza c’è probabilmente e
sei limitato dalla risorsa più lenta
nel sistema e quindi così
il coordinatore ha una maggiore possibilità di
in mancanza e c’è solo una sorta di ridotto
throughput attraverso il tuo sistema perché
sei ancora come tenere queste serrature
queste risorse mentre stai operando
loro e quindi questo è un po ‘lento anche
vale la pena sottolineare che nessuno dei
implementano grandi provider di servizi cloud
protocollo di commit a due fasi e loro
in realtà specificatamente dicono di no
come Azure come post di blog su questo
perché non si adatta bene e
non è qualcosa che ti vogliono
utilizzando
il loro sistema perché sono preoccupati
su tutte queste cose va bene e poi
Google ha una chiave, questo è come
fanno i loro database distribuiti questo
è anche un altro documento che è venuto fuori
Google consiglio vivamente di andare e
leggendolo, lo coprirò brevemente
è anche un grande punto di sfida
la tua nozione di tempo perché non è così
esiste davvero o non possiamo averne uno
uso logico del tempo, quindi spanner è il
modo che Google fa a livello globale
database e transazioni distribuiti
tra database in tutto il mondo e
il modo in cui fanno tutto questo
il lavoro è che hanno le loro API in tempo reale
e hanno GPS e orologi atomici
installato in tutti i data center è
vale anche la pena sottolineare che Google ha
fibra ottica tra tutti i loro data center
quindi non stanno andando oltre nella rete
come se non stavano andando oltre il normale
rete che la maggior parte di noi usa e così
questo è molto più veloce e quindi ciò che è vero
l’API del tempo fa è tutto il
input dal sistema che include
il GPS e gli orologi atomici e poi
conta è in grado di calcolare un limite di
momento in cui questo evento si è verificato e così
lo usano per creare un ordinamento totale
nel sistema ma stanno ottenendo solo
da zero a sette millisecondi come
non è ancora la sincronizzazione non è un
problema risolto loro lo capiscono davvero
finestra veramente piccola e così funziona
abbastanza bene
quindi ovviamente Google Spanner non lo è
disponibile a tutti noi è davvero
costoso ed è proprietario quindi scrivi
transazioni distribuite non è una volta
di nuovo risolto per le masse ed è
sai davvero che la sincronizzazione non lo è
risolto quindi quello che sto cercando di ottenere qui
è che le transazioni distribuite sono
veramente difficile e sono davvero costosi
soprattutto se vuoi abilitare la serializzazione
e acido, quindi possiamo fare di meglio che possiamo
otteniamo transazioni distribuite con
serializzare la capacità di un pozzo acido non lo sono
ricercatore, ho appena costruito su larga scala
sistemi distribuiti così adesso
la risposta è no, non possiamo a causa del tappo
piramide non possiamo avere cose belle e
i sistemi distribuiti sono terribili ma noi
può iniziare a rinunciare ad alcuni di questi
vincoli davvero difficili come la serializzazione
capacità di un acido se cosa possiamo rinunciare
e programma ancora in questo modello
siamo abituati e abbiamo ancora costruito
sistemi corretti
quindi è qui che entrano le saghe
Sarkis è in realtà dai distributori
dalla letteratura del database nel 1987 I
è stato pubblicato da Hector Garcia Molina
e kenneth salem da princeton
università ed è un giornale che è
guardando esattamente come facciamo a lungo
transazioni live su un singolo database
così loro incontrarono questo problema
dove se stiamo facendo una transazione
consuma molte risorse o corre per
un tempo veramente lungo come il calcolo di una banca
affermazione o qualcosa che deve andare
attraverso una vasta gamma di storia che
crea un collo di bottiglia anche solo a
database singolo perché è in attesa
blocca un mucchio di risorse diverse
come sta facendo questo e così loro volevano
forse sapevano che non potevano ottenere
capacità acida e serializzata ma
sono come quello che possiamo fare per farlo
più veloce e ottenere ancora alcune garanzie e
così hanno escogitato questo concetto di a
saga e lo scopo di questo per lunga vita
transazioni su un singolo database così
hanno definito le saghe come una lunga vita
transazione che può essere scritta come
sequenza di transazioni e questi
le transazioni possono essere intercalate con una
un altro tutte le transazioni nella sequenza
o completato con successo alla fine
della saga o transazioni compensative
vengono eseguiti per modificare l’esecuzione parziale così
Rompiamo questo giù quindi è un po ‘
un po ‘più comprensibile, hanno detto
una saga è una raccolta di sub
le transazioni si prende qualsiasi cosa di grandi dimensioni
cosa vuoi fare quando la rompi
giù in questi piccoli pezzi di
transazioni e queste tutte le transazioni
può avere risorse su un singolo database
riguarda i trucchi che non possono
come dipendere l’uno dall’altro così che tu sia
la parte interfogliata come la chiave
non può prendere o insegnare, non si può prendere
input da t1 e non ce l’hanno
non può avere alcun ordine che si suppone
accadere per loro quindi se puoi rompere
il tuo lavoro in una sorta di sistema normale o
in queste cose poi hai come il
inizio di una saga ogni transazione nel
saga ha una transazione di compensazione e
ancora una volta l’interleaving e il
non dipendendo l’uno dall’altro
il principio vale anche qui e il
cosa su questi compensare
transazioni che stanno per
semanticamente annullare la transazione che
corrispondono a e così la carta
effettivamente riconosciuto è quello perché
dividiamo il lavoro in questi
pezzi a volte non puoi non puoi
restituire il sistema allo stesso stato se
esegui una transazione e poi tu
devi risarcirti per te
potrebbe non essere in grado di tornare allo stesso
Stato come era prima della transazione
iniziato come per esempio se tu fossi
manderò un’email come una delle tue
transazioni con l’invio di una email
non posso annullare l’invio di questa email ma puoi inviarla
una email di follow-up per dire come hey questo
è quello che è successo e così come lo siamo noi
correggendolo e quindi è un po ‘come
questo modello di gestione dei guasti che
stiamo andando bene e poi dopo di noi
definire tutto questo abbiamo questo bello
garantire che tutti o il
transazioni completate quindi la nostra saga è stata
successo e come qualsiasi unità di
il lavoro che volevamo fare è finito o
alcune delle transazioni sono state completate
e tutte le transazioni compensative
hanno corso così la saga è fallita ma lo siamo
ora di nuovo semanticamente coerente
stato che eravamo prima abbiamo iniziato la
saga questo è davvero un gran bel
modello da programmare contro perché è
molto simile alle transazioni come
o stiamo mantenendo la coerenza
e correttezza dell’applicazione in tutto
il nostro sistema quindi quello che abbiamo fatto qui è però
abbiamo scambiato l’atomicità per la disponibilità
abbiamo visto queste um sub transazioni
stanno per essere indipendenti su uno
un altro e così vedrai pezzi di
la saga completa prima di tutto
la saga ha completato e quindi se ne hai bisogno
atomicità questo non funziona per te ma
per molte delle nostre applicazioni questo è
okay e poi mi piace anche molto
saghe nel loro complesso perché sono a
modello di gestione degli errori e così via
costruire sistemi distribuiti dovremmo
pianifica solo che tutto fallisce
soprattutto se sei nel cloud
soprattutto se non ti piace il tuo
proprie reti anche se si possiede la propria
reti che dovresti pianificare per tutto
fallire e quindi forzare la tua applicazione
gli sviluppatori pensano al fallimento come
come il primo e il primo nel tuo
il modello di progettazione ti aiuterà a costruire
sistemi più robusti e aiuterà
costruisci più come sistemi meno fragili
perché non si limita a codificare il Golden
Sentiero che in realtà stai avendo
pensa come quello che succede quando andiamo
fuori dal sentiero d’oro va bene così come questo
funziona in un unico database è se tu
lo faremo, avremo il nostro
applicazione di viaggio che vorresti provare e
prenota il nostro viaggio e invece di avere questo
una grande transazione che avrebbe cercato di
riservare tutte le cose di cui avevamo bisogno
andare nel nostro viaggio in cui l’avremmo diviso
come queste unità logiche di lavoro come
prenotazione di un hotel prenotazione di un auto prenotazione a
volo e poi cancellando tutti quelli
prenotazioni nel caso che la saga
fallisce nel modo in cui funziona
database singoli hai questo processo
chiamato il coordinatore di esecuzione saga o
la SEC con cui vive SEC
il tuo database e quindi una specie di condivisioni
la stessa faccia quindi non siamo in a
mondo distribuito solo ancora ma il suo lavoro
è quello di andare ed eseguire questi sub
transazioni e quindi nel caso di
fallimento iniziare applicando compensazione
transazioni hai anche un log della saga
è proprio come il tuo normale database
log e così sta andando a fare le cose come
stai andando a impegnare i messaggi a
mi piace iniziare saga termina saga abort saga
e poi tutto l’inizio e il commit
messaggi per le transazioni e
compensare le transazioni e quindi cosa
questo sembra come stai attraversando
solo per darti un’idea è se a
saga di successo sarebbe come voglio un
prenota un viaggio vero, inizierò il mio
saga nel registro inizierò a prenotare il
hotel a questo punto ora possiedo quell’hotel
risorsa che il resto del mondo può vedere
questo diritto non abbiamo atomicità lo farò
Continuerò a prenotare l’auto che finirò
prenotando l’auto che ho completato ora
avere quella macchina e poi finalmente
se riesco a prendere il volo, posso andare avanti
il mio viaggio e possiamo dire che noi
completato con successo la saga cosa c’è
anche bello notare qui è quello nel tuo
applicazione è possibile ordinare le cose nel
in modo altrettanto rischioso, così giusto
a volte ci sono sanzioni con
cancellando un volo quindi forse questo è il
l’ultima cosa che vogliamo fare perché non lo faccio
voglio andare e rotolare così indietro
c’è un motivo che sto mostrando
tu l’ordine in questo modo va bene così
cosa succede quando cose simili falliscono e
le cose si infrangono
abbiamo saghe senza successo e la carta
in realtà discute una coppia diversa
le modalità di fallimento sono come indietro
recupero e inoltro recupero e a
un paio di altri ma sto per parlare
sulla ripresa a ritroso perché penso
è il più comune e il più utile
e questa è l’idea che non appena abbiamo
avere un fallimento o non possiamo completare a
transazione o qualcosa succede solo noi
iniziare il rollback iniziamo ad applicare il nostro
compensare le transazioni per qualsiasi cosa
che era stato gestito così senza successo
saga apparirà come questo nel registro
inizia la saga forse iniziamo la prenotazione
l’ hotel e che ha successo quindi possediamo
quella prenotazione e poi per qualsiasi cosa
motivo per cui la macchina fallirà perché
forse non c’era un noleggio disponibile
macchina quel giorno così ora abbiamo bisogno di tornare indietro
e inizia ad applicare la compensazione
transazioni così inizierai ad applicare
le transazioni compensative lo farà
liberare tutte le risorse che capita di avere
stato preso e poi libererai il
prenotazione alberghiera
e ora siamo tornati in semanticamente il
lo stesso stato sono triste perché non capisco
al mio viaggio e posso provare e riprenotare
più tardi ma giusto come siamo ancora in a
Stato coerente per applicazione uniforme
anche se ci piace trattenersi in quell’hotel
risorsa per un breve periodo di tempo
qualcun altro può andare e prenderlo è
proprio come una normale transazione un singolo
database quindi è la transazione che è
bene o completare con successo o
non interrompere in un unico database è
come se qualcuno lo cancellasse okay
così azionario è in un sistema distribuito il
la carta in realtà commenta questo e questo
fa la cosa che preferisco così presto
la letteratura di database fa dove dicono
a causa delle limitazioni di spazio discutiamo solo
su un sistema centralizzato, anche se
chiaramente può essere implementato in a
database distribuito e ho riso
perché questa è la mia vita, quindi grazie
Hector Garcia Molina quindi siamo veramente
andando a passare e implementare questo
ci sono post sul blog e cose scritte
su questo schema ma non mi piace nessuno
di loro perché in realtà non penso
ti danno abbastanza dettagli da implementare
la piena garanzia quindi stiamo andando a
parla di come lo fai davvero perché
è diverso in un mondo distribuito
e alcune delle ulteriori restrizioni
dobbiamo applicare per piacere ottenere
la stessa garanzia quindi siamo tornati a questo
mondo giusto non siamo più su uno
database canonico fonte di verità noi
probabilmente stanno funzionando con un mucchio di
servizi che stanno trattenendo
data diversa come utilizzare qualsiasi dato
negozio che scelgono di utilizzare e applicare
i propri vincoli e quindi questo tipo
di traduce davvero bene che possiamo
ancora rompere le unità di lavoro in questi
come richiedere un libro libro auto libro Hotel libro
volo e poi la cancellazione
richieste così tanto positive che farò
un po ‘ridefinizione termine perché io
non mi piace usare la parola transazione in
il senso distribuito perché non lo è
davvero una transazione è generalmente
sarà una richiesta è anche un
la transazione si applica a me semantica acida
e puoi ottenere come queste richieste
potrebbe essere acido se quel servizio come ha dato
che la garanzia ma è davvero fino a
il servizio per definire ciò che ti garantisce
ho qui quindi spero che ti diano
come la consistenza e la durata sei tu
probabilmente non otterrò isolamento o
l’atomicità da uno di questi va bene forse
dipende da quale API sei
interagendo con così e così ancora
anche le tue richieste secondarie vanno bene
annulleranno semanticamente il
richieste che sono accadute
così la saga distribuita di successo sembra
esattamente lo stesso e abbiamo ancora il nostro
ceppo
abbiamo ancora bisogno di un registro ma ora non lo è
co-situato con un database perché noi
non abbiamo un singolo database così abbiamo
avere un registro duraturo e distribuito
che vive da qualche parte così potrebbe essere
Kafka come il tuo servizio di autobus o come
qualunque cosa tu voglia usare, ha solo bisogno
per funzionare come un log
hai ancora bisogno di un’esecuzione Saga
coordinatore questo è ancora una volta che elaboro
e non vive in co-locazione con
tutto ciò che non è speciale, voglio
Fai notare che questa cosa non è speciale
non gli piace il nostro coordinatore e
commit a due fasi può morire ha no
affermare che non fa nulla di speciale tutto
della nostra fonte di verità è ancora in questo
log così il coordinatore dell’esecuzione è spiacente
questo processo che sta per interpretare
e giusto ai log della saga che applicherà i nostri
saga sub richieste e poi nel caso
di fallimento si deciderà quando è necessario
iniziare ad applicare le richieste di compensazione così
Vediamo in che cosa questo assomiglia
perché le cose sono un po ‘diverse
ora avrò il nostro servizio che lo farà
inviare un messaggio al nostro log Saga per dire
Voglio iniziare una saga di una grande unità di
lavoro può impegnare un sacco di dati a
questo registro questi non sono solo come inizio
e impegni i messaggi ora che possono commettere
tutto ciò di cui ho bisogno di sapere
elaborare questa richiesta di una saga di esecuzione
il coordinatore può essere attivato o lo sarà
lì per vedere che ho bisogno di iniziare
elaborando questa saga e poi quella
inizierà a leggere la saga e il figurare
fuori ciò che deve fare
per prima cosa comincerà a impegnarsi a
messaggio al registro che dice che sto andando
fare la prima richiesta nella saga e
che ha due commit con successo prima
può fare qualsiasi altra cosa poi va
per inviare una richiesta al servizio
responsabile della gestione di questo e poi
una volta che risponde, si impegnerà a farlo
Ho finito il messaggio della saga sul registro
quindi ho camminato abbastanza lentamente
per dimostrarti che ora ne abbiamo quattro
ulteriori punti di errore che abbiamo fatto
non avere quando eravamo su un singolo
database in cui tutto è stato co-localizzato
e in sostanza se si è schiantato ogni
il sec il registro e tutti questi come
le transazioni hanno condiviso lo stesso destino così noi
avere un sacco di posti dove le cose possono
ora falliamo di nuovo così passeremo attraverso
come se facesse la stessa cosa
impegna il messaggio nel registro per
questa è la seconda richiesta e poi lo farà
fare la richiesta che riceverà il
risposta e quindi impegnerà il
messaggio al log e poi lo stesso
con il terzo si impegnerà il messaggio
inviare la richiesta ricevere una risposta e
fine della saga questa è una saga di successo
e funziona ancora allo stesso modo
e
come la vita è bella, quindi cosa succede quando
le cose falliscono quando abbiamo bisogno di iniziare
applicando queste richieste di compensazione
giusto possiamo ancora avere questa idea di un
la saga abortita la nostra risposta come la
i servizi potrebbero dire no che non ho intenzione di
fai questa cosa per te perché io solo
non possono o potrebbero dire come se non lo fossi
disponibile come servizio o potrebbero dire
cose come te non hanno accesso a fare
queste richieste di avvio falliscono proprio così
questo potrebbe essere come qualsiasi HTTP o
risposta di errore che genera un servizio
non è lì e poi in alcuni casi se
in caso di crash in secondo luogo dovremmo iniziare
azioni compensative perché queste
richieste che non abbiamo applicato alcun
ulteriori vincoli su di loro
non devi essere impotente c’è
niente di speciale su di loro che puoi fare
qualunque cosa tu voglia con loro e lo faremo
parla di più sul sec crash in a
secondo, quindi, cosa succede qui camminiamo
attraverso come un caso di fallimento, quindi abbiamo
fatto la prima cosa che abbiamo raggiunto
qualunque sia la prima richiesta è
con successo ora ho iniziato il secondo
richiesta e il servizio dice no io non sono
andando a fare questo voglio che tu abortisca il
saga o ottiene un messaggio di errore e
il sec poi impegnerà una saga di interruzione
messaggio nel registro così ora sappiamo che
siamo in rollback, dobbiamo iniziare
applicare le transazioni compensative
o chiede scusa, quindi quello che farà è
farà la stessa cosa come è
rispondendo alle richieste regolari lo farà
commetta il messaggio di avvio al registro
invierà la richiesta di compensazione iniziale
speriamo che il servizio possa riuscire
e quindi impegnerà il messaggio a
il registro e poi la stessa cosa con il
terzo perché è solo leggendo il
accedi per capire che come oh lo sono ancora
per applicare la richiesta di compensazione per
servizio uno così è fantastico e
ora abbiamo ancora lo stesso tipo
di una garanzia che avevamo ma che se
le richieste di compensazione falliscono adesso
siamo in questo mondo dove sono
un altro non transazionale cosa se loro
fallire così perché possono fallire, abbiamo bisogno di
essere in grado di riprovarli indefinitamente fino al
ci riescono e quindi questo pone un extra
vincolo che non avevamo nel
mondo di database sul nostro sistema che sono
richieste di compensazione devono essere
idempotente devo essere in grado di ripetere
loro fino a quando non riescono quindi questo è un
un po ‘diverso rispetto al nel
caso normale singolo database va bene e
poi finalmente cosa succede quando il nostro FEC
fallisce come ho detto che questo ragazzo non è questo
questo piccolo processo non è speciale noi
può semplicemente farne un altro
per continuare qualunque cosa accada come
non deve nemmeno essere sullo stesso
macchina abbiamo dovuto determinare se il
La SEC era dentro o la saga era in una cassaforte
stato quando CC si è bloccato o meno e
quindi uno stato sicuro è tutto il sottotitolo
le richieste sono complete in modo da avere il
inizio e fine entrambi registrati perché a
quel punto sappiamo come sappiamo cosa
successo che abbiamo appena lasciato da qualche parte e
possiamo solo continuare a raccogliere con il
saga ovunque sia stato interrotto e poi se
sei in uno stato abortito perché
le richieste di compensazione sono idempotente siamo
sappiamo che possiamo semplicemente continuare a riprodurli
anche se mi sono impegnato a iniziarne uno
basta inviarlo di nuovo e quindi questa è una cassaforte
Stato come bene dove dobbiamo iniziare
applicare il rollback come quando entriamo
questo caso di incertezza di è fatto noi
avviare una richiesta e non abbiamo il
registri delle richieste finali perché non so se
si è schiantato prima ancora di aver inviato il
richiesta non so se si è schiantato
perché ha ricevuto una risposta e poi
si è schiantato come non conosco lo stato di
come se il servizio avesse visto anche questo
ma non è sicuro ripetere questa richiesta
perché non abbiamo aggiunto altro
vincoli su di loro se nel tuo sistema
puoi anche fare la tua richiesta normale
Potente articolo che non puoi mai avere
preoccuparti del recupero della SEC come te
basta riportarlo su e iniziare
rielaborare ma penso di fare tutto
Richiesta voce potente è un compito arduo per
imporre come il tuo normale metodo di
esecuzione e quindi quello che succede sei tu
ho appena commesso un messaggio di abort saga su
un registro se tu se la SEC ritorna in su
uno stato non sicuro e si avvia il
richieste di compensazione okay
quindi essenzialmente quello che abbiamo fatto qui noi
Devo definire qualche richiesta di messaggistica
semantica in cima a come questi
le richieste definiranno una eSATA o
le richieste secondarie sono al massimo una volta che lo faranno
consegnato zero o una volta e poi
le nostre richieste di compensazione sono almeno
una volta così verranno consegnati almeno
una o più volte nel sistema e così via
questo è ciò che devi sapere quando lo sei
progettando la tua saga per assicurarti che
i sistemi che stai facendo questi
le richieste su possono gestirlo ma ora
siamo tornati in questo mondo dove abbiamo
la stessa saga garantisce che abbiamo fatto
il singolo database e questo è davvero
ottimo vero perché ora lo so
o la mia intera saga ha completato e
Sono in uno stato semanticamente coerente
per la mia applicazione o per la mia intera saga
non completato e sono ancora in a
stato semanticamente coerente per il mio
applicazione e quindi è una grande vittoria per
essere in grado di programmare con questi limiti
okay, solo per ricapitolare
sagas distribuiti sono molto simili
al singolo tranne per ora tu
bisogno di un registro saga durevole distribuito e
è possibile utilizzare qualsiasi cosa che ti piace
ha bisogno di un processo SEC , non è speciale ma
hai bisogno di qualcosa che piacerà
continua a girare e assicurati
che è in esecuzione e quindi è necessario
questi compensano o commentano qualsiasi
le richieste ora devono essere fuori in un attimo
quindi è diverso, ma penso
va bene e non penso che lo sia anche
alto di un ordine per noi come applicazione
sviluppatori perché piace se pensi
circa come servizi di riposo come post è
non o come cancellare è idempotente giusto
o semanticamente dovrebbe essere un oggetto
potente okay , torniamo al cielo
questo è il capo maestro è il principale
personaggio della serie Halo in Halo 4
e come ho detto prima quando abbiamo iniziato
guardando come passare dal singolo
mondo di database in questo multi come
mondo partizionato di Azeroth seguito noi
si sono imbattuti in alcuni problemi quindi parlerò
riguardo al servizio di statistica che è il
servizio principale in Halo che controlla
tutto del tuo giocatore ho scritto il
la maggior parte di questo servizio e così noi
avere analisi molto dettagliate su
cosa stai facendo in ogni momento
nel gioco e così facciamo questo ottenendo
un gigantesco blob di dati caricato a noi a
la fine di ogni partita e qualche volta
mentre stai giocando e quindi uno dei
problemi che abbiamo incontrato in questo sistema
era che la gente si preoccupa molto di questi
le statistiche come si ottengono davvero
sconvolto quando lo fai a pezzi è sempre
il miglior gioco che abbia mai avuto sempre
scioccante e così così e intendo come cuz
come il gioco giusto è una cosa che le persone giocano
gioco come alone per soldi e competizione
e premi in denaro e poi alla gente piace
dovrebbe parlare con i loro amici così e
anche a loro piace come abbiamo
questo intero sito web in cui puoi entrare
come un tuffo profondo e questo è giusto
come una frazione di ciò che abbiamo per
giocatore quindi alcune cose da sapere sul
il servizio di statistica è che potresti
avere da uno a 32 giocatori per partita tutti
i nostri dati dei giocatori quando lo abbiamo fatto
migrazione a cloud e storage completi come
un servizio era sul tavolo di Azure che è un
valore chiave negozio e ogni giocatore nel
il negozio di valore chiave aveva una propria partizione
e quindi ora scommetti che stai parlando
scrivere dati su 32 partizioni e
deve ancora assomigliare a uno
unità di lavoro e tutti o riescono o
tutti falliscono così noi
sai un po ‘perplesso ma saghe
è arrivato e ci ha aiutato a fare questo così è
se hai visto qualcuno dei miei discorsi di aureola
prima di dove parlo dei nostri pene questo
è quello che normalmente mostro così abbiamo costruito il
massa dei servizi utilizzando un attore MSR
quadro chiamato Arleen’s non è super
integrale a questo ma i piccoli diamanti
sono attori o chicchi di orleans e così via
quello che succede è che la xbox ci invierà a
gruppo di statistiche l’attore del gioco o
come processo puoi pensarlo come
che se non hai familiarità con il
modello di attore piacerà aggregare quelli
giusto è un archivio blob e poi a
Alla fine diremo hey a tutti i giocatori
per favore aggiorna le tue statistiche e
allora tutti quei giocatori scriveranno a
la loro partizione corrispondente e come
la tua memoria del tavolo e poi lo faccio
mano ondeggiante canzone-e-ballo dove sono
non fallisce proprio come c’è un modo
affrontare il fallimento e così è
in realtà ciò che sembra perché
può fallire e quindi cosa è successo realmente
abbiamo avuto la nostra Xbox in esecuzione nel nostro
servizio front-end stateless che noi
ha scritto in F sharp che quindi registrava a
messaggio al capo del servizio di Azure che è un
servizio è un servizio di accodamento e
broker di messaggi in Azure che è possibile utilizzare
e commetterebbe il carico utile delle statistiche
al servizio di autobus e come hey come andare
inizia la saga per questo gioco così è stato
è come quello che usiamo come log della nostra saga
avevamo questi grani del router questi
lavoratori di router senza stato che avrebbero solo
notare che come hey qualcosa ho capito
impegnato e quindi abbiamo bisogno di spendere
qualcuno su per andare ed elaborare questo lavoro
e abbiamo trattato i nostri attori di gioco o a
processi di gioco come il nostro secondo coordinatore
quindi tutti i router hanno fatto solo loro
notare che come nuovo lavoro c’era e
poi avrebbero fatto ruotare il giusto il
grano gioco giusto per andare a gestirlo
quindi il grano di gioco si è poi comportato come il
a questo punto e lo sapresti fare
il tutto come invia tutti i messaggi e
quindi riprendi l’ indirizzo uh come
il tuo log del bus di servizio, quindi cos’è successo
errore nel fallimento forse non lo fai
voglio solo ripristinare le statistiche a destra
perché se ho commesso il tuo
statistiche e puoi vederle anche
anche se i tuoi amici non possono e poi io
rotoli indietro che sembra davvero stridente
per dire come se avessi cento uccisioni
e ora hai 90 uccisioni
questa è davvero una brutta esperienza utente
anche se volevamo solo elaborarlo
alla fine comunque non è come lo eravamo noi
andando buttare via che i dati
se non siamo riusciti a scrivere per un giocatore così
abbiamo implementato il recupero in avanti che è
un altro modello specificato nella saga
carta che dice semplicemente questo
saga come sempre ha bisogno per avere successo in modo
riprenditi in avanti come no
tornare indietro e quindi la premessa di base qui
è di controllare il punto e si dice quando sono io
a un sicuro stato controlli questi
stati sicuri e se si ha un fallimento
torni allo stato sicuro e poi
si tira avanti fortunatamente per noi qualsiasi
i giocatori che riuscivano a scrivere erano
essenzialmente uno stato sicuro che non avevamo
fare qualsiasi rollback quindi vorremmo
riprova la saga dopo se qualcuno ha fallito
scrivere e ti accompagnerò
attraverso quello che sembrava giusto così
abbiamo avuto il nostro scarico di giochi che è il nostro SEC
ha parlato a tutti i giocatori e
i giocatori hanno parlato a tutti loro
partizioni e così dire come giocatore 3
non potrei scrivere sulla sua partizione perché
abbiamo fatto saltare il budget di I su quel deposito
conto o qualcosa che non so e così
come tre dei giocatori ora lo farò
essere in grado di vedere le loro statistiche per questo
gioco su Halo Waypoint e giocatore 3 lo farà
Non e va bene così ci piace la gente sapesse
che le nostre statistiche elaborano il seeing
era un po ‘ asincrono in generale alone
i giocatori sono un po ‘narcisisti loro
non stavano guardando le statistiche dei loro amici
stavano guardando più alle loro statistiche così
in realtà non ci siamo mai lamentati
su questo, quindi andava bene e così noi
sarebbe poi dovuto andare e riproduzione
in tutto il sistema dovremmo farlo
go replay layer player 3 così noi
in realtà metterebbe questo messaggio
e mi piace tornare a elaborare questo per
un po ‘per dare al sistema una possibilità
mettiti in pari quindi non vuoi solo piacerti
martella di nuovo il tuo account di archiviazione se
è già come saturo così ma
A causa di questo, se si sta notando Sono
non tornare indietro e in realtà sono
ripetendo la richiesta di interpretarla
attraverso di nuovo e perché ah questo è
ottimo lo scarico del gioco non sapevo dove
che ha fallito non sapeva se ha scritto
e poi come se non mi piacesse capirlo
indietro o come quello che era successo e così così
inoltrare richieste o se lo farai
inoltro del ripristino nel sistema in a
sistema distribuito quindi le richieste secondarie
Devo anche essere idempotente, così eravamo
in grado di fare alcuni piccoli trucchi e
fare affidamento sulla coerenza dei nostri database con
assicurarsi che non fossimo come il doppio
contando le statistiche o tutto quanto
le nostre richieste sono idempotenti perché così
era essenzialmente solo le operazioni impostate
comunque perché sei proprio come aggiungere
come richieste quindi quando è arrivata la saga
riprovare più tardi e per recuperare il gioco
lo scarico lo manderebbe al grano delle nostre statistiche
giocatore 3 avrebbe memorizzato con successo il suo
statistiche e ora sappiamo di averlo
elaborati tutti i dati nella presente
gioco e quindi possiamo solo un po ‘come
lo scarteremmo in realtà non lo facevamo
avere come un registro persistente di tutto
perché non ci è stato utile
in realtà memorizzava i dati di cui avevamo bisogno e
poi lo gettò via
e così a questo punto ora abbiamo quello
garantire che come tutti i giocatori
nel gioco avevano elaborato il loro
alle statistiche e il nostro sistema era in a
stato coerente e tutti potevano vedere
il loro stato queste statistiche per il gioco
bello, quindi sto mentendo un po ‘
questo ciò che abbiamo effettivamente fatto e questo è
dove mi piace entrare e sintonizzare i sistemi
c’è un compromesso qui giusto se
scriverai per 32 giocatori indietro
al registro del bus di servizio azzurro che ha
per essere coerenti, c’è un po ‘
un po ‘ di consistenza di filtraggio, se lo stai facendo
un registro CP speranzoso perché non lo fai
voglio solo come dati di caduta o come avere
errori in là che è tipo di
costoso parlare con quella cosa 32 volte
per gioco, quindi ottimizziamo il nostro fallimento
caso perché lo scrivi su un singolo
la partizione non era costosa perché
i giocatori lo stavano facendo solo una volta
ogni 20 minuti quando avevano finito
un gioco e quindi per noi è stato più facile
solo riprovare è stato un compromesso migliore
latenza di rete e tutte le cose
considerato saggio solo riprovare tutto
perché sapevamo di essere idempotenti
quindi questo è un compromesso che puoi fare
quando avremmo un fallimento per cui ci esprimiamo
il recupero delle parole in realtà sarebbe proprio come
Reeb dura tutti e dì processa il tuo
statistiche e quelle che già avevano
quando raddoppiano e ripristinano
loro direbbero semplicemente che lo sto elaborando
correttamente e siamo stati fatti così mi piace
segnalalo perché penso come un
l’industria si nasconde un po ‘come alcuni di
le scorciatoie che prendiamo ma penso che sia
in realtà davvero valido per prenderli
scorciatoie quando si sta andando a mettere a punto un
istanza molto su misura di un sistema come
questa è un’istanza unica come te
potrebbe andare a costruire una saga generale
distribuito esecuzione saga distribuita
coordinatore nel sistema ma come tu puoi
anche solo andare e costruirne uno che funzioni
per il tuo sistema e questo è totalmente valido
questo è un modello per voi da utilizzare e
costruire le tue applicazioni e fare
sicuro che siano corretti così solo per
tipo di riassunto scrivere saghe sono questi
transazioni distribuite a vita lunga e
dovresti usarli nel tuo sistema
perché penso che siano davvero utili
modo di pensare, progettare e programmare
contro in un modello a cui siamo abituati
la programmazione contro di te si sta negoziando
atomicità per disponibilità quindi se
non puoi tollerare di vedere parziale
esecuzione della cosa accade nel
saga e non puoi farlo ma in più
casi possiamo farlo bene e poi noi
può intraprendere azioni correttive che costruisco a
come la mia inclinazione nel mondo è verso
sistemi di gioco altamente disponibili, giochi giusti
roba dei social media come quella che c’è
conseguenza del business del mondo reale a
noi non siamo in grado di agire e fare
cose come se non potessi interpretare Halo allora
ciò influenza la quantità di denaro che noi
fare e così è male
così come fare questo trade-off va bene
per noi e noi se dovessimo prendere
azioni correttive che dovevamo fare
fai questo e poi finalmente è un fallimento
modello di gestione proprio come aiuta
costruisci più affidabile e robusto
sistemi e sistemi meno fragili e così via
Mi piace questo come uno schema e un buco
per questo alla fine voglio ringraziare
un gruppo di persone che mi hanno aiutato con
questo discorso Peter Bayliss conosci Sombra
Tarocchi di Thomson Kyle Kingsbury Jeff Hodges
e il bassista di Clements senza di loro
non avrei potuto farlo e ora se tu
i ragazzi hanno domande che sono felice di prendere
loro
ingegnere dei sistemi è la mia felpa da discoteca
Io programma in questo a volte quindi lavoro a
il Twitter è attualmente attivo
infrastruttura e piattaforma specificamente
osservabilità e ho appena entrato in
Gennaio e vivo a San Francisco
prima però ho passato sei sei
più anni di lavoro nel nostro team in
industria su giochi come anni di guerra due
e tre e poi halo 4 è l’unico
che ho trascorso la maggior parte del mio tempo su
costruire come servizi e networking
e sistemi distribuiti che essenzialmente
alimenta molto l’ intrattenimento
Esperienza che quando accendi il tuo
xbox e inizia a giocare che vedi così
questo è il mio Twitter e ho un blog tecnologico
se vuoi parlare con me sul
internet lo farei quindi sentiti libero okay
così come ho detto, ho lavorato in aureola
nel 2010 quando 343 Industries era uno studio
creato all’interno di Microsoft per prendere in consegna
il franchise di Halo di Bungie che
deciso che vogliono andare a fare altri giochi
e hanno appena reso il destino giusto così io
era come il servizio web numero due
assunto in questo piccolo studio a 30 anni
le persone a capire cosa avremmo fatto
fare con questo vecchio stack halo perché il
i giochi originali avevano i servizi che c’erano
come l’ alone uno due tre e poi raggiungere
e ODST aveva tutti servizi aggiuntivi a
aiutarti a giocare e vivere il gioco
ma erano si conosce il modo in cui siamo stati
usato per costruire vecchi servizi dove tu
ha avuto il gioco parlando con un servizio statico
che puoi semplicemente scalare in modo lineare
fuori e poi hai avuto un sequel gigante
database che tutto ciò che ospitava il
fonte di verità per tutti come Halo tutto
dei giochi di Halo e così ci siamo resi conto
quello che non sarebbe andato in scala per noi
quando abbiamo visto cosa volevamo fare
per Halo four e il futuro del
franchising andando avanti così come sapevamo
o abbiamo effettivamente colpito i numeri di 1,5
Miliardi di giochi per Halo 4 giocati e poi
11,6 milioni di utenti unici e così via
non si adatterebbe su un singolo gigante
sequel database più così siamo finiti
andando e riscrivendo tutti i servizi e
spostandoci verso il cloud di Ezra e siamo finiti
utilizzando il table store di Azure come nostro
la più grande forma di memoria senza sequel simile
e quindi questo è un valore fondamentale per
quelli di voi che non hanno familiarità con esso
e così ora in questo mondo abbiamo avuto questo
sfida dove eravamo abituati a fare cose
con transazioni su un singolo database
dato che siamo abituati alla programmazione
contro le transazioni su questo
database e che ha mantenuto il nostro sistema
coerente e questo è stato davvero bello ma
ora non abbiamo più avuto questo perché tutti
i nostri dati sono stati suddivisi su più punti
partizioni quindi abbiamo deciso di pensarci
davvero difficile su come vogliamo farlo
per me pensare davvero è difficile
decisamente come andare in un bar e
leggendo un sacco di carte e bevendo
bourbon ma ci siamo imbattuti nella saga
modello che è una carta che era
pubblicato nel 1987 che dirò
voi ragazzi e in realtà siamo andati
implementato in modo che potessimo
elaborare le statistiche in una sorta di a
modo transazionale e lo sto usando in
citazioni perché ne stiamo rinunciando
le cose se lo vedete in una casa parlano noi
non abbiamo la possibilità di serializzare
rinunciare ad alcune cose ma dà
noi un modo per garantire coerenza come
dall’inizio alla fine del
transazione e cosa fare in caso di fallimento
scenari quindi parlerò con voi ragazzi
oggi le saghe ti danno un po ‘
di motivazione per il motivo per cui ne abbiamo bisogno e
allora parleremo del documento originale
il suo contributo al distribuito o
allo spazio del database perché
in realtà è venuto fuori che la sua data
comunità e poi parleremo di come
lo fai in un mondo distribuito
perché è un po ‘diverso
ci sono ulteriori sfide e
vincoli che è necessario imporre e
allora parleremo di come effettivamente
ha fatto questo in Halo 4 ok così giusto come il nostro
i sistemi utilizzati per essere molto semplici sono stati utilizzati
essere in grado di avere come un’app o un
sito web che ha parlato con un apolide
servizio e parlato con questo gigante
database canonico fonte di verità e
quindi hai le transazioni che hai
serializza abilità e acido in modo corretto
la serializzabilità è la nostra garanzia
le cose sembrano come se accadessero
sequenzialmente a Thomas City è questa idea
che sia successo o no
e non vediamo lo stato delle cose
in elaborazione tra coerenza
è la consistenza a livello di applicazione che è
non linearizzare la consistenza dell’abilità ma
è fondamentalmente che il nostro sistema è ancora
in uno stato valido dopo che abbiamo noi quando
abbiamo iniziato la transazione alla fine
della transazione il sistema è in a
stato valido e che sia come
totalmente se la transazione
completato o non isolato è quello
queste transazioni non influiscono su ciascuna
altro se sono in esecuzione contemporaneamente
e quindi la durabilità è questa idea
una volta che abbiamo commesso qualcosa
persiste in così tanto tempo e come noi
non perdere i dati così bene ma ora siamo
in questo mondo abbiamo un servizio orientato
architetture e micro servizi e tu
non avere fonti di verità canoniche
più spesso
quando scriviamo le applicazioni che eravamo
interagire con magari un po ‘della nostra
api o stiamo interagendo con qualcuno
le altre API e usarle e così noi
in realtà non possono e hanno tutti il loro
proprio negozi di supporto giusto quindi non c’è
come una fonte canonica di verità noi
non ottenere più le transazioni, semplicemente
non posso averli e così alcuni modi
abbiamo provato a risolvere il distribuito
problema di transazione come commit a due fasi
così il commit a due fasi è un atomico
protocollo di impegno e in fondo è a
versione specializzata del consenso
protocollo quindi a volte va bene e
è stato implementato e fatto in piccolo
scala e in fondo vado molto
rapidamente attraverso di esso ma hai un
prepara la fase in cui avrai un singolo
coordinatore il coordinatore è molto
speciale nel sistema è un singolo
punto di errore e lui proporrà di
tutte le risorse coinvolte, ehi
andando a fare questa cosa e poi tutto
le risorse arrivano a votare sì, voglio
fai questa cosa o no non voglio farlo
questa cosa e il coordinatore raccoglie
tutti i voti
così una volta che il coordinatore ha ricevuto tutto
dei voti ora entriamo nel commit
fase e se tutti hanno detto sì allora
diciamo andare e fare il commit della transazione
e così è così che ottengono
atomicità perché tutti stanno commettendo
allo stesso tempo o se qualcuno dice di no
poi dicono di non farlo bene così
non c’è stato come dove potresti
avere l’auto riservata e non avere il
hotel riservato nella tua app di viaggio
tutti alla fine devono dire fatto
ordine in un vero sistema distribuito così
che puoi conoscere al coordinatore
cosa è successo , questo è un po ‘
bello e questo è in realtà la gente usa
questo ma in realtà non scala tutto
quel bene e le condizioni di fallimento che puoi
avere fino a Oh N messaggi al quadrato in corso
attraverso il tuo sistema è il tuo coordinatore
ancora una volta un singolo punto di rottura quindi
se quella cosa muore in qualsiasi momento durante
la transazione come se fosse appena abortita
e così più risorse hai
più latenza c’è probabilmente e
sei limitato dalla risorsa più lenta
nel sistema e quindi così
il coordinatore ha una maggiore possibilità di
in mancanza e c’è solo una sorta di ridotto
throughput attraverso il tuo sistema perché
sei ancora come tenere queste serrature
queste risorse mentre stai operando
loro e quindi questo è un po ‘lento anche
vale la pena sottolineare che nessuno dei
implementano grandi provider di servizi cloud
protocollo di commit a due fasi e loro
in realtà specificatamente dicono di no
come Azure come post di blog su questo
perché non si adatta bene e
non è qualcosa che ti vogliono
utilizzando
il loro sistema perché sono preoccupati
su tutte queste cose va bene e poi
Google ha una chiave, questo è come
fanno i loro database distribuiti questo
è anche un altro documento che è venuto fuori
Google consiglio vivamente di andare e
leggendolo, lo coprirò brevemente
è anche un grande punto di sfida
la tua nozione di tempo perché non è così
esiste davvero o non possiamo averne uno
uso logico del tempo, quindi spanner è il
modo che Google fa a livello globale
database e transazioni distribuiti
tra database in tutto il mondo e
il modo in cui fanno tutto questo
il lavoro è che hanno le loro API in tempo reale
e hanno GPS e orologi atomici
installato in tutti i data center è
vale anche la pena sottolineare che Google ha
fibra ottica tra tutti i loro data center
quindi non stanno andando oltre nella rete
come se non stavano andando oltre il normale
rete che la maggior parte di noi usa e così
questo è molto più veloce e quindi ciò che è vero
l’API del tempo fa è tutto il
input dal sistema che include
il GPS e gli orologi atomici e poi
conta è in grado di calcolare un limite di
momento in cui questo evento si è verificato e così
lo usano per creare un ordinamento totale
nel sistema ma stanno ottenendo solo
da zero a sette millisecondi come
non è ancora la sincronizzazione non è un
problema risolto loro lo capiscono davvero
finestra veramente piccola e così funziona
abbastanza bene
quindi ovviamente Google Spanner non lo è
disponibile a tutti noi è davvero
costoso ed è proprietario quindi scrivi
transazioni distribuite non è una volta
di nuovo risolto per le masse ed è
sai davvero che la sincronizzazione non lo è
risolto quindi quello che sto cercando di ottenere qui
è che le transazioni distribuite sono
veramente difficile e sono davvero costosi
soprattutto se vuoi abilitare la serializzazione
e acido, quindi possiamo fare di meglio che possiamo
otteniamo transazioni distribuite con
serializzare la capacità di un pozzo acido non lo sono
ricercatore, ho appena costruito su larga scala
sistemi distribuiti così adesso
la risposta è no, non possiamo a causa del tappo
piramide non possiamo avere cose belle e
i sistemi distribuiti sono terribili ma noi
può iniziare a rinunciare ad alcuni di questi
vincoli davvero difficili come la serializzazione
capacità di un acido se cosa possiamo rinunciare
e programma ancora in questo modello
siamo abituati e abbiamo ancora costruito
sistemi corretti
quindi è qui che entrano le saghe
Sarkis è in realtà dai distributori
dalla letteratura del database nel 1987 I
è stato pubblicato da Hector Garcia Molina
e kenneth salem da princeton
università ed è un giornale che è
guardando esattamente come facciamo a lungo
transazioni live su un singolo database
così loro incontrarono questo problema
dove se stiamo facendo una transazione
consuma molte risorse o corre per
un tempo veramente lungo come il calcolo di una banca
affermazione o qualcosa che deve andare
attraverso una vasta gamma di storia che
crea un collo di bottiglia anche solo a
database singolo perché è in attesa
blocca un mucchio di risorse diverse
come sta facendo questo e così loro volevano
forse sapevano che non potevano ottenere
capacità acida e serializzata ma
sono come quello che possiamo fare per farlo
più veloce e ottenere ancora alcune garanzie e
così hanno escogitato questo concetto di a
saga e lo scopo di questo per lunga vita
transazioni su un singolo database così
hanno definito le saghe come una lunga vita
transazione che può essere scritta come
sequenza di transazioni e questi
le transazioni possono essere intercalate con una
un altro tutte le transazioni nella sequenza
o completato con successo alla fine
della saga o transazioni compensative
vengono eseguiti per modificare l’esecuzione parziale così
Rompiamo questo giù quindi è un po ‘
un po ‘più comprensibile, hanno detto
una saga è una raccolta di sub
le transazioni si prende qualsiasi cosa di grandi dimensioni
cosa vuoi fare quando la rompi
giù in questi piccoli pezzi di
transazioni e queste tutte le transazioni
può avere risorse su un singolo database
riguarda i trucchi che non possono
come dipendere l’uno dall’altro così che tu sia
la parte interfogliata come la chiave
non può prendere o insegnare, non si può prendere
input da t1 e non ce l’hanno
non può avere alcun ordine che si suppone
accadere per loro quindi se puoi rompere
il tuo lavoro in una sorta di sistema normale o
in queste cose poi hai come il
inizio di una saga ogni transazione nel
saga ha una transazione di compensazione e
ancora una volta l’interleaving e il
non dipendendo l’uno dall’altro
il principio vale anche qui e il
cosa su questi compensare
transazioni che stanno per
semanticamente annullare la transazione che
corrispondono a e così la carta
effettivamente riconosciuto è quello perché
dividiamo il lavoro in questi
pezzi a volte non puoi non puoi
restituire il sistema allo stesso stato se
esegui una transazione e poi tu
devi risarcirti per te
potrebbe non essere in grado di tornare allo stesso
Stato come era prima della transazione
iniziato come per esempio se tu fossi
manderò un’email come una delle tue
transazioni con l’invio di una email
non posso annullare l’invio di questa email ma puoi inviarla
una email di follow-up per dire come hey questo
è quello che è successo e così come lo siamo noi
correggendolo e quindi è un po ‘come
questo modello di gestione dei guasti che
stiamo andando bene e poi dopo di noi
definire tutto questo abbiamo questo bello
garantire che tutti o il
transazioni completate quindi la nostra saga è stata
successo e come qualsiasi unità di
il lavoro che volevamo fare è finito o
alcune delle transazioni sono state completate
e tutte le transazioni compensative
hanno corso così la saga è fallita ma lo siamo
ora di nuovo semanticamente coerente
stato che eravamo prima abbiamo iniziato la
saga questo è davvero un gran bel
modello da programmare contro perché è
molto simile alle transazioni come
o stiamo mantenendo la coerenza
e correttezza dell’applicazione in tutto
il nostro sistema quindi quello che abbiamo fatto qui è però
abbiamo scambiato l’atomicità per la disponibilità
abbiamo visto queste um sub transazioni
stanno per essere indipendenti su uno
un altro e così vedrai pezzi di
la saga completa prima di tutto
la saga ha completato e quindi se ne hai bisogno
atomicità questo non funziona per te ma
per molte delle nostre applicazioni questo è
okay e poi mi piace anche molto
saghe nel loro complesso perché sono a
modello di gestione degli errori e così via
costruire sistemi distribuiti dovremmo
pianifica solo che tutto fallisce
soprattutto se sei nel cloud
soprattutto se non ti piace il tuo
proprie reti anche se si possiede la propria
reti che dovresti pianificare per tutto
fallire e quindi forzare la tua applicazione
gli sviluppatori pensano al fallimento come
come il primo e il primo nel tuo
il modello di progettazione ti aiuterà a costruire
sistemi più robusti e aiuterà
costruisci più come sistemi meno fragili
perché non si limita a codificare il Golden
Sentiero che in realtà stai avendo
pensa come quello che succede quando andiamo
fuori dal sentiero d’oro va bene così come questo
funziona in un unico database è se tu
lo faremo, avremo il nostro
applicazione di viaggio che vorresti provare e
prenota il nostro viaggio e invece di avere questo
una grande transazione che avrebbe cercato di
riservare tutte le cose di cui avevamo bisogno
andare nel nostro viaggio in cui l’avremmo diviso
come queste unità logiche di lavoro come
prenotazione di un hotel prenotazione di un auto prenotazione a
volo e poi cancellando tutti quelli
prenotazioni nel caso che la saga
fallisce nel modo in cui funziona
database singoli hai questo processo
chiamato il coordinatore di esecuzione saga o
la SEC con cui vive SEC
il tuo database e quindi una specie di condivisioni
la stessa faccia quindi non siamo in a
mondo distribuito solo ancora ma il suo lavoro
è quello di andare ed eseguire questi sub
transazioni e quindi nel caso di
fallimento iniziare applicando compensazione
transazioni hai anche un log della saga
è proprio come il tuo normale database
log e così sta andando a fare le cose come
stai andando a impegnare i messaggi a
mi piace iniziare saga termina saga abort saga
e poi tutto l’inizio e il commit
messaggi per le transazioni e
compensare le transazioni e quindi cosa
questo sembra come stai attraversando
solo per darti un’idea è se a
saga di successo sarebbe come voglio un
prenota un viaggio vero, inizierò il mio
saga nel registro inizierò a prenotare il
hotel a questo punto ora possiedo quell’hotel
risorsa che il resto del mondo può vedere
questo diritto non abbiamo atomicità lo farò
Continuerò a prenotare l’auto che finirò
prenotando l’auto che ho completato ora
avere quella macchina e poi finalmente
se riesco a prendere il volo, posso andare avanti
il mio viaggio e possiamo dire che noi
completato con successo la saga cosa c’è
anche bello notare qui è quello nel tuo
applicazione è possibile ordinare le cose nel
in modo altrettanto rischioso, così giusto
a volte ci sono sanzioni con
cancellando un volo quindi forse questo è il
l’ultima cosa che vogliamo fare perché non lo faccio
voglio andare e rotolare così indietro
c’è un motivo che sto mostrando
tu l’ordine in questo modo va bene così
cosa succede quando cose simili falliscono e
le cose si infrangono
abbiamo saghe senza successo e la carta
in realtà discute una coppia diversa
le modalità di fallimento sono come indietro
recupero e inoltro recupero e a
un paio di altri ma sto per parlare
sulla ripresa a ritroso perché penso
è il più comune e il più utile
e questa è l’idea che non appena abbiamo
avere un fallimento o non possiamo completare a
transazione o qualcosa succede solo noi
iniziare il rollback iniziamo ad applicare il nostro
compensare le transazioni per qualsiasi cosa
che era stato gestito così senza successo
saga apparirà come questo nel registro
inizia la saga forse iniziamo la prenotazione
l’ hotel e che ha successo quindi possediamo
quella prenotazione e poi per qualsiasi cosa
motivo per cui la macchina fallirà perché
forse non c’era un noleggio disponibile
macchina quel giorno così ora abbiamo bisogno di tornare indietro
e inizia ad applicare la compensazione
transazioni così inizierai ad applicare
le transazioni compensative lo farà
liberare tutte le risorse che capita di avere
stato preso e poi libererai il
prenotazione alberghiera
e ora siamo tornati in semanticamente il
lo stesso stato sono triste perché non capisco
al mio viaggio e posso provare e riprenotare
più tardi ma giusto come siamo ancora in a
Stato coerente per applicazione uniforme
anche se ci piace trattenersi in quell’hotel
risorsa per un breve periodo di tempo
qualcun altro può andare e prenderlo è
proprio come una normale transazione un singolo
database quindi è la transazione che è
bene o completare con successo o
non interrompere in un unico database è
come se qualcuno lo cancellasse okay
così azionario è in un sistema distribuito il
la carta in realtà commenta questo e questo
fa la cosa che preferisco così presto
la letteratura di database fa dove dicono
a causa delle limitazioni di spazio discutiamo solo
su un sistema centralizzato, anche se
chiaramente può essere implementato in a
database distribuito e ho riso
perché questa è la mia vita, quindi grazie
Hector Garcia Molina quindi siamo veramente
andando a passare e implementare questo
ci sono post sul blog e cose scritte
su questo schema ma non mi piace nessuno
di loro perché in realtà non penso
ti danno abbastanza dettagli da implementare
la piena garanzia quindi stiamo andando a
parla di come lo fai davvero perché
è diverso in un mondo distribuito
e alcune delle ulteriori restrizioni
dobbiamo applicare per piacere ottenere
la stessa garanzia quindi siamo tornati a questo
mondo giusto non siamo più su uno
database canonico fonte di verità noi
probabilmente stanno funzionando con un mucchio di
servizi che stanno trattenendo
data diversa come utilizzare qualsiasi dato
negozio che scelgono di utilizzare e applicare
i propri vincoli e quindi questo tipo
di traduce davvero bene che possiamo
ancora rompere le unità di lavoro in questi
come richiedere un libro libro auto libro Hotel libro
volo e poi la cancellazione
richieste così tanto positive che farò
un po ‘ridefinizione termine perché io
non mi piace usare la parola transazione in
il senso distribuito perché non lo è
davvero una transazione è generalmente
sarà una richiesta è anche un
la transazione si applica a me semantica acida
e puoi ottenere come queste richieste
potrebbe essere acido se quel servizio come ha dato
che la garanzia ma è davvero fino a
il servizio per definire ciò che ti garantisce
ho qui quindi spero che ti diano
come la consistenza e la durata sei tu
probabilmente non otterrò isolamento o
l’atomicità da uno di questi va bene forse
dipende da quale API sei
interagendo con così e così ancora
anche le tue richieste secondarie vanno bene
annulleranno semanticamente il
richieste che sono accadute
così la saga distribuita di successo sembra
esattamente lo stesso e abbiamo ancora il nostro
ceppo
abbiamo ancora bisogno di un registro ma ora non lo è
co-situato con un database perché noi
non abbiamo un singolo database così abbiamo
avere un registro duraturo e distribuito
che vive da qualche parte così potrebbe essere
Kafka come il tuo servizio di autobus o come
qualunque cosa tu voglia usare, ha solo bisogno
per funzionare come un log
hai ancora bisogno di un’esecuzione Saga
coordinatore questo è ancora una volta che elaboro
e non vive in co-locazione con
tutto ciò che non è speciale, voglio
Fai notare che questa cosa non è speciale
non gli piace il nostro coordinatore e
commit a due fasi può morire ha no
affermare che non fa nulla di speciale tutto
della nostra fonte di verità è ancora in questo
log così il coordinatore dell’esecuzione è spiacente
questo processo che sta per interpretare
e giusto ai log della saga che applicherà i nostri
saga sub richieste e poi nel caso
di fallimento si deciderà quando è necessario
iniziare ad applicare le richieste di compensazione così
Vediamo in che cosa questo assomiglia
perché le cose sono un po ‘diverse
ora avrò il nostro servizio che lo farà
inviare un messaggio al nostro log Saga per dire
Voglio iniziare una saga di una grande unità di
lavoro può impegnare un sacco di dati a
questo registro questi non sono solo come inizio
e impegni i messaggi ora che possono commettere
tutto ciò di cui ho bisogno di sapere
elaborare questa richiesta di una saga di esecuzione
il coordinatore può essere attivato o lo sarà
lì per vedere che ho bisogno di iniziare
elaborando questa saga e poi quella
inizierà a leggere la saga e il figurare
fuori ciò che deve fare
per prima cosa comincerà a impegnarsi a
messaggio al registro che dice che sto andando
fare la prima richiesta nella saga e
che ha due commit con successo prima
può fare qualsiasi altra cosa poi va
per inviare una richiesta al servizio
responsabile della gestione di questo e poi
una volta che risponde, si impegnerà a farlo
Ho finito il messaggio della saga sul registro
quindi ho camminato abbastanza lentamente
per dimostrarti che ora ne abbiamo quattro
ulteriori punti di errore che abbiamo fatto
non avere quando eravamo su un singolo
database in cui tutto è stato co-localizzato
e in sostanza se si è schiantato ogni
il sec il registro e tutti questi come
le transazioni hanno condiviso lo stesso destino così noi
avere un sacco di posti dove le cose possono
ora falliamo di nuovo così passeremo attraverso
come se facesse la stessa cosa
impegna il messaggio nel registro per
questa è la seconda richiesta e poi lo farà
fare la richiesta che riceverà il
risposta e quindi impegnerà il
messaggio al log e poi lo stesso
con il terzo si impegnerà il messaggio
inviare la richiesta ricevere una risposta e
fine della saga questa è una saga di successo
e funziona ancora allo stesso modo
e
come la vita è bella, quindi cosa succede quando
le cose falliscono quando abbiamo bisogno di iniziare
applicando queste richieste di compensazione
giusto possiamo ancora avere questa idea di un
la saga abortita la nostra risposta come la
i servizi potrebbero dire no che non ho intenzione di
fai questa cosa per te perché io solo
non possono o potrebbero dire come se non lo fossi
disponibile come servizio o potrebbero dire
cose come te non hanno accesso a fare
queste richieste di avvio falliscono proprio così
questo potrebbe essere come qualsiasi HTTP o
risposta di errore che genera un servizio
non è lì e poi in alcuni casi se
in caso di crash in secondo luogo dovremmo iniziare
azioni compensative perché queste
richieste che non abbiamo applicato alcun
ulteriori vincoli su di loro
non devi essere impotente c’è
niente di speciale su di loro che puoi fare
qualunque cosa tu voglia con loro e lo faremo
parla di più sul sec crash in a
secondo, quindi, cosa succede qui camminiamo
attraverso come un caso di fallimento, quindi abbiamo
fatto la prima cosa che abbiamo raggiunto
qualunque sia la prima richiesta è
con successo ora ho iniziato il secondo
richiesta e il servizio dice no io non sono
andando a fare questo voglio che tu abortisca il
saga o ottiene un messaggio di errore e
il sec poi impegnerà una saga di interruzione
messaggio nel registro così ora sappiamo che
siamo in rollback, dobbiamo iniziare
applicare le transazioni compensative
o chiede scusa, quindi quello che farà è
farà la stessa cosa come è
rispondendo alle richieste regolari lo farà
commetta il messaggio di avvio al registro
invierà la richiesta di compensazione iniziale
speriamo che il servizio possa riuscire
e quindi impegnerà il messaggio a
il registro e poi la stessa cosa con il
terzo perché è solo leggendo il
accedi per capire che come oh lo sono ancora
per applicare la richiesta di compensazione per
servizio uno così è fantastico e
ora abbiamo ancora lo stesso tipo
di una garanzia che avevamo ma che se
le richieste di compensazione falliscono adesso
siamo in questo mondo dove sono
un altro non transazionale cosa se loro
fallire così perché possono fallire, abbiamo bisogno di
essere in grado di riprovarli indefinitamente fino al
ci riescono e quindi questo pone un extra
vincolo che non avevamo nel
mondo di database sul nostro sistema che sono
richieste di compensazione devono essere
idempotente devo essere in grado di ripetere
loro fino a quando non riescono quindi questo è un
un po ‘diverso rispetto al nel
caso normale singolo database va bene e
poi finalmente cosa succede quando il nostro FEC
fallisce come ho detto che questo ragazzo non è questo
questo piccolo processo non è speciale noi
può semplicemente farne un altro
per continuare qualunque cosa accada come
non deve nemmeno essere sullo stesso
macchina abbiamo dovuto determinare se il
La SEC era dentro o la saga era in una cassaforte
stato quando CC si è bloccato o meno e
quindi uno stato sicuro è tutto il sottotitolo
le richieste sono complete in modo da avere il
inizio e fine entrambi registrati perché a
quel punto sappiamo come sappiamo cosa
successo che abbiamo appena lasciato da qualche parte e
possiamo solo continuare a raccogliere con il
saga ovunque sia stato interrotto e poi se
sei in uno stato abortito perché
le richieste di compensazione sono idempotente siamo
sappiamo che possiamo semplicemente continuare a riprodurli
anche se mi sono impegnato a iniziarne uno
basta inviarlo di nuovo e quindi questa è una cassaforte
Stato come bene dove dobbiamo iniziare
applicare il rollback come quando entriamo
questo caso di incertezza di è fatto noi
avviare una richiesta e non abbiamo il
registri delle richieste finali perché non so se
si è schiantato prima ancora di aver inviato il
richiesta non so se si è schiantato
perché ha ricevuto una risposta e poi
si è schiantato come non conosco lo stato di
come se il servizio avesse visto anche questo
ma non è sicuro ripetere questa richiesta
perché non abbiamo aggiunto altro
vincoli su di loro se nel tuo sistema
puoi anche fare la tua richiesta normale
Potente articolo che non puoi mai avere
preoccuparti del recupero della SEC come te
basta riportarlo su e iniziare
rielaborare ma penso di fare tutto
Richiesta voce potente è un compito arduo per
imporre come il tuo normale metodo di
esecuzione e quindi quello che succede sei tu
ho appena commesso un messaggio di abort saga su
un registro se tu se la SEC ritorna in su
uno stato non sicuro e si avvia il
richieste di compensazione okay
quindi essenzialmente quello che abbiamo fatto qui noi
Devo definire qualche richiesta di messaggistica
semantica in cima a come questi
le richieste definiranno una eSATA o
le richieste secondarie sono al massimo una volta che lo faranno
consegnato zero o una volta e poi
le nostre richieste di compensazione sono almeno
una volta così verranno consegnati almeno
una o più volte nel sistema e così via
questo è ciò che devi sapere quando lo sei
progettando la tua saga per assicurarti che
i sistemi che stai facendo questi
le richieste su possono gestirlo ma ora
siamo tornati in questo mondo dove abbiamo
la stessa saga garantisce che abbiamo fatto
il singolo database e questo è davvero
ottimo vero perché ora lo so
o la mia intera saga ha completato e
Sono in uno stato semanticamente coerente
per la mia applicazione o per la mia intera saga
non completato e sono ancora in a
stato semanticamente coerente per il mio
applicazione e quindi è una grande vittoria per
essere in grado di programmare con questi limiti
okay, solo per ricapitolare
sagas distribuiti sono molto simili
al singolo tranne per ora tu
bisogno di un registro saga durevole distribuito e
è possibile utilizzare qualsiasi cosa che ti piace
ha bisogno di un processo SEC , non è speciale ma
hai bisogno di qualcosa che piacerà
continua a girare e assicurati
che è in esecuzione e quindi è necessario
questi compensano o commentano qualsiasi
le richieste ora devono essere fuori in un attimo
quindi è diverso, ma penso
va bene e non penso che lo sia anche
alto di un ordine per noi come applicazione
sviluppatori perché piace se pensi
circa come servizi di riposo come post è
non o come cancellare è idempotente giusto
o semanticamente dovrebbe essere un oggetto
potente okay , torniamo al cielo
questo è il capo maestro è il principale
personaggio della serie Halo in Halo 4
e come ho detto prima quando abbiamo iniziato
guardando come passare dal singolo
mondo di database in questo multi come
mondo partizionato di Azeroth seguito noi
si sono imbattuti in alcuni problemi quindi parlerò
riguardo al servizio di statistica che è il
servizio principale in Halo che controlla
tutto del tuo giocatore ho scritto il
la maggior parte di questo servizio e così noi
avere analisi molto dettagliate su
cosa stai facendo in ogni momento
nel gioco e così facciamo questo ottenendo
un gigantesco blob di dati caricato a noi a
la fine di ogni partita e qualche volta
mentre stai giocando e quindi uno dei
problemi che abbiamo incontrato in questo sistema
era che la gente si preoccupa molto di questi
le statistiche come si ottengono davvero
sconvolto quando lo fai a pezzi è sempre
il miglior gioco che abbia mai avuto sempre
scioccante e così così e intendo come cuz
come il gioco giusto è una cosa che le persone giocano
gioco come alone per soldi e competizione
e premi in denaro e poi alla gente piace
dovrebbe parlare con i loro amici così e
anche a loro piace come abbiamo
questo intero sito web in cui puoi entrare
come un tuffo profondo e questo è giusto
come una frazione di ciò che abbiamo per
giocatore quindi alcune cose da sapere sul
il servizio di statistica è che potresti
avere da uno a 32 giocatori per partita tutti
i nostri dati dei giocatori quando lo abbiamo fatto
migrazione a cloud e storage completi come
un servizio era sul tavolo di Azure che è un
valore chiave negozio e ogni giocatore nel
il negozio di valore chiave aveva una propria partizione
e quindi ora scommetti che stai parlando
scrivere dati su 32 partizioni e
deve ancora assomigliare a uno
unità di lavoro e tutti o riescono o
tutti falliscono così noi
sai un po ‘perplesso ma saghe
è arrivato e ci ha aiutato a fare questo così è
se hai visto qualcuno dei miei discorsi di aureola
prima di dove parlo dei nostri pene questo
è quello che normalmente mostro così abbiamo costruito il
massa dei servizi utilizzando un attore MSR
quadro chiamato Arleen’s non è super
integrale a questo ma i piccoli diamanti
sono attori o chicchi di orleans e così via
quello che succede è che la xbox ci invierà a
gruppo di statistiche l’attore del gioco o
come processo puoi pensarlo come
che se non hai familiarità con il
modello di attore piacerà aggregare quelli
giusto è un archivio blob e poi a
Alla fine diremo hey a tutti i giocatori
per favore aggiorna le tue statistiche e
allora tutti quei giocatori scriveranno a
la loro partizione corrispondente e come
la tua memoria del tavolo e poi lo faccio
mano ondeggiante canzone-e-ballo dove sono
non fallisce proprio come c’è un modo
affrontare il fallimento e così è
in realtà ciò che sembra perché
può fallire e quindi cosa è successo realmente
abbiamo avuto la nostra Xbox in esecuzione nel nostro
servizio front-end stateless che noi
ha scritto in F sharp che quindi registrava a
messaggio al capo del servizio di Azure che è un
servizio è un servizio di accodamento e
broker di messaggi in Azure che è possibile utilizzare
e commetterebbe il carico utile delle statistiche
al servizio di autobus e come hey come andare
inizia la saga per questo gioco così è stato
è come quello che usiamo come log della nostra saga
avevamo questi grani del router questi
lavoratori di router senza stato che avrebbero solo
notare che come hey qualcosa ho capito
impegnato e quindi abbiamo bisogno di spendere
qualcuno su per andare ed elaborare questo lavoro
e abbiamo trattato i nostri attori di gioco o a
processi di gioco come il nostro secondo coordinatore
quindi tutti i router hanno fatto solo loro
notare che come nuovo lavoro c’era e
poi avrebbero fatto ruotare il giusto il
grano gioco giusto per andare a gestirlo
quindi il grano di gioco si è poi comportato come il
a questo punto e lo sapresti fare
il tutto come invia tutti i messaggi e
quindi riprendi l’ indirizzo uh come
il tuo log del bus di servizio, quindi cos’è successo
errore nel fallimento forse non lo fai
voglio solo ripristinare le statistiche a destra
perché se ho commesso il tuo
statistiche e puoi vederle anche
anche se i tuoi amici non possono e poi io
rotoli indietro che sembra davvero stridente
per dire come se avessi cento uccisioni
e ora hai 90 uccisioni
questa è davvero una brutta esperienza utente
anche se volevamo solo elaborarlo
alla fine comunque non è come lo eravamo noi
andando buttare via che i dati
se non siamo riusciti a scrivere per un giocatore così
abbiamo implementato il recupero in avanti che è
un altro modello specificato nella saga
carta che dice semplicemente questo
saga come sempre ha bisogno per avere successo in modo
riprenditi in avanti come no
tornare indietro e quindi la premessa di base qui
è di controllare il punto e si dice quando sono io
a un sicuro stato controlli questi
stati sicuri e se si ha un fallimento
torni allo stato sicuro e poi
si tira avanti fortunatamente per noi qualsiasi
i giocatori che riuscivano a scrivere erano
essenzialmente uno stato sicuro che non avevamo
fare qualsiasi rollback quindi vorremmo
riprova la saga dopo se qualcuno ha fallito
scrivere e ti accompagnerò
attraverso quello che sembrava giusto così
abbiamo avuto il nostro scarico di giochi che è il nostro SEC
ha parlato a tutti i giocatori e
i giocatori hanno parlato a tutti loro
partizioni e così dire come giocatore 3
non potrei scrivere sulla sua partizione perché
abbiamo fatto saltare il budget di I su quel deposito
conto o qualcosa che non so e così
come tre dei giocatori ora lo farò
essere in grado di vedere le loro statistiche per questo
gioco su Halo Waypoint e giocatore 3 lo farà
Non e va bene così ci piace la gente sapesse
che le nostre statistiche elaborano il seeing
era un po ‘ asincrono in generale alone
i giocatori sono un po ‘narcisisti loro
non stavano guardando le statistiche dei loro amici
stavano guardando più alle loro statistiche così
in realtà non ci siamo mai lamentati
su questo, quindi andava bene e così noi
sarebbe poi dovuto andare e riproduzione
in tutto il sistema dovremmo farlo
go replay layer player 3 così noi
in realtà metterebbe questo messaggio
e mi piace tornare a elaborare questo per
un po ‘per dare al sistema una possibilità
mettiti in pari quindi non vuoi solo piacerti
martella di nuovo il tuo account di archiviazione se
è già come saturo così ma
A causa di questo, se si sta notando Sono
non tornare indietro e in realtà sono
ripetendo la richiesta di interpretarla
attraverso di nuovo e perché ah questo è
ottimo lo scarico del gioco non sapevo dove
che ha fallito non sapeva se ha scritto
e poi come se non mi piacesse capirlo
indietro o come quello che era successo e così così
inoltrare richieste o se lo farai
inoltro del ripristino nel sistema in a
sistema distribuito quindi le richieste secondarie
Devo anche essere idempotente, così eravamo
in grado di fare alcuni piccoli trucchi e
fare affidamento sulla coerenza dei nostri database con
assicurarsi che non fossimo come il doppio
contando le statistiche o tutto quanto
le nostre richieste sono idempotenti perché così
era essenzialmente solo le operazioni impostate
comunque perché sei proprio come aggiungere
come richieste quindi quando è arrivata la saga
riprovare più tardi e per recuperare il gioco
lo scarico lo manderebbe al grano delle nostre statistiche
giocatore 3 avrebbe memorizzato con successo il suo
statistiche e ora sappiamo di averlo
elaborati tutti i dati nella presente
gioco e quindi possiamo solo un po ‘come
lo scarteremmo in realtà non lo facevamo
avere come un registro persistente di tutto
perché non ci è stato utile
in realtà memorizzava i dati di cui avevamo bisogno e
poi lo gettò via
e così a questo punto ora abbiamo quello
garantire che come tutti i giocatori
nel gioco avevano elaborato il loro
alle statistiche e il nostro sistema era in a
stato coerente e tutti potevano vedere
il loro stato queste statistiche per il gioco
bello, quindi sto mentendo un po ‘
questo ciò che abbiamo effettivamente fatto e questo è
dove mi piace entrare e sintonizzare i sistemi
c’è un compromesso qui giusto se
scriverai per 32 giocatori indietro
al registro del bus di servizio azzurro che ha
per essere coerenti, c’è un po ‘
un po ‘ di consistenza di filtraggio, se lo stai facendo
un registro CP speranzoso perché non lo fai
voglio solo come dati di caduta o come avere
errori in là che è tipo di
costoso parlare con quella cosa 32 volte
per gioco, quindi ottimizziamo il nostro fallimento
caso perché lo scrivi su un singolo
la partizione non era costosa perché
i giocatori lo stavano facendo solo una volta
ogni 20 minuti quando avevano finito
un gioco e quindi per noi è stato più facile
solo riprovare è stato un compromesso migliore
latenza di rete e tutte le cose
considerato saggio solo riprovare tutto
perché sapevamo di essere idempotenti
quindi questo è un compromesso che puoi fare
quando avremmo un fallimento per cui ci esprimiamo
il recupero delle parole in realtà sarebbe proprio come
Reeb dura tutti e dì processa il tuo
statistiche e quelle che già avevano
quando raddoppiano e ripristinano
loro direbbero semplicemente che lo sto elaborando
correttamente e siamo stati fatti così mi piace
segnalalo perché penso come un
l’industria si nasconde un po ‘come alcuni di
le scorciatoie che prendiamo ma penso che sia
in realtà davvero valido per prenderli
scorciatoie quando si sta andando a mettere a punto un
istanza molto su misura di un sistema come
questa è un’istanza unica come te
potrebbe andare a costruire una saga generale
distribuito esecuzione saga distribuita
coordinatore nel sistema ma come tu puoi
anche solo andare e costruirne uno che funzioni
per il tuo sistema e questo è totalmente valido
questo è un modello per voi da utilizzare e
costruire le tue applicazioni e fare
sicuro che siano corretti così solo per
tipo di riassunto scrivere saghe sono questi
transazioni distribuite a vita lunga e
dovresti usarli nel tuo sistema
perché penso che siano davvero utili
modo di pensare, progettare e programmare
contro in un modello a cui siamo abituati
la programmazione contro di te si sta negoziando
atomicità per disponibilità quindi se
non puoi tollerare di vedere parziale
esecuzione della cosa accade nel
saga e non puoi farlo ma in più
casi possiamo farlo bene e poi noi
può intraprendere azioni correttive che costruisco a
come la mia inclinazione nel mondo è verso
sistemi di gioco altamente disponibili, giochi giusti
roba dei social media come quella che c’è
conseguenza del business del mondo reale a
noi non siamo in grado di agire e fare
cose come se non potessi interpretare Halo allora
ciò influenza la quantità di denaro che noi
fare e così è male
così come fare questo trade-off va bene
per noi e noi se dovessimo prendere
azioni correttive che dovevamo fare
fai questo e poi finalmente è un fallimento
modello di gestione proprio come aiuta
costruisci più affidabile e robusto
sistemi e sistemi meno fragili e così via
Mi piace questo come uno schema e un buco
per questo alla fine voglio ringraziare
un gruppo di persone che mi hanno aiutato con
questo discorso Peter Bayliss conosci Sombra
Tarocchi di Thomson Kyle Kingsbury Jeff Hodges
e il bassista di Clements senza di loro
non avrei potuto farlo e ora se tu
i ragazzi hanno domande che sono felice di prendere
loro
Please follow and like us: