Escriptures en diverses regions: on es confirma realment l’escriptura?
L’encaminament porta una petició a una regió; només una frontera de transacció fa atòmiques les escriptures. Anomeneu la invariante, trieu el propietari i dissenyeu el reintent al seu voltant.
Dos servidors d’aplicació en dues regions, un client que escriu a través d’una VPN i una pregunta que ningú no va escriure: quin component decideix que l’escriptura ha passat? L’encaminament porta la petició fins a un procés. Una frontera de transacció decideix quan el canvi esdevé durador i visible. Són feines diferents fetes per sistemes diferents, i l’escletxa entre elles és on viuen la majoria d’errors d’escriptura multiregió.
Comenceu per la regla de negoci, no pel mapa
Comenceu amb una frase sobre la regla de negoci i no sobre la geografia: quines lectures i escriptures han de reeixir juntes i quins canvis concurrents han de ser impossibles mentre ho fan. Per a una reserva d’inventari això vol dir que la comprovació d’estoc i la reserva o totes dues tenen efecte o cap, i cap segona comanda no pot consumir la mateixa unitat entremig.
| Requirement | What satisfies it | What does not |
|---|---|---|
| All-or-nothing application | A transaction inside one owning system | A VPN path between regions |
| No double spend | Isolation strong enough to exclude the conflict | Atomicity alone |
| Survive a region loss | Replication the database itself documents | Two independent databases behind one client |
Aquesta fila del mig és la que els equips salten. L’atomicitat sense aïllament suficient permet que dues transaccions es confirmin cadascuna correctament i tot i així produeixin un estat que el negoci considera impossible, i cap quantitat de lògica de reintent ho arregla després.
Una frontera autoritària guanya dos servidors regionals
Els servidors d’aplicació regionals poden quedar-se on són, sempre que enviïn l’operació a un servei que la faci dins d’una única frontera de transacció suportada. El nivell d’aplicació esdevé un encaminador d’intenció; el nivell de dades posseeix la veritat.
Manteniu aquesta frontera curta i a prop de les dades que toca. Una transacció oberta mentre una persona respon un missatge o mentre una crida travessa dues regions passa el temps aguantant panys i augmentant la possibilitat que una altra cosa caduqui al darrere. Aquesta fallada sembla un problema de base de dades i en realitat és un problema de disseny que se n’ha disfressat. Moure la decisió al nivell de dades normalment l’elimina del tot.
BEGIN;
UPDATE inventory SET reserved = reserved + 1
WHERE sku = 'A-100' AND available >= 1;
INSERT INTO reservation (sku, order_id) VALUES ('A-100', 'ord-9f');
COMMIT;Llegiu aquest esbós com una frontera, no com una recomanació de rendiment. El punt és que la comprovació i la inserció comparteixen una confirmació, així que una comanda concurrent o veu l’estoc consumit o no el veu mai.
Què us dona i què no us dona una base de dades replicada
Una base de dades replicada pot oferir una frontera més àmplia quan el seu propi model de transacció ho permet. Spanner documenta transaccions de lectura i escriptura atòmiques dins d’una sola base de dades a través de taules, amb aïllament i comportament de reintent definits. És una garantia que llegiu, proveu i feu servir deliberadament.
També és una garantia que ve del producte, no de la ruta. Una VPN entre regions canvia com viatgen els paquets i com es presenten les fallades. No allarga una frontera de transacció ni una sola fila, per sa que el túnel sembli saludable. Confondre les dues coses produeix arquitectures on cada component passa la seva pròpia comprovació i les dades encara no concorden.
Dues bases de dades no es converteixen en un sol sistema
Dues bases de dades gestionades independentment no adquireixen un gestor de transaccions compartit pel fet que els clients puguin arribar a totes dues. Si el negoci necessita de veritat un compromís atòmic entre les dues, el mecanisme de coordinació, els participants i el procés de recuperació s’han de triar i qualificar en lloc de suposar-los.
Penseu en el moment en què un participant o un enllaç desapareix després que la feina s’hagi preparat. Una confirmació distribuïda suportada pot deixar un estat en dubte que necessita un procediment de recuperació i una decisió humana, i no promet que cada regió segueixi sent escrivible durant cada partició.
Si en canvi és acceptable una coordinació asíncrona, digueu-ho explícitament i escriviu els estats de negoci intermedis més les regles de reconciliació. Una cadena de passos confirmats localment amb compensació és un disseny legítim; simplement no és una transacció atòmica amb un altre nom.
Dissenyou el reintent abans de la primera caiguda
Un client pot perdre la resposta després que l’operació s’hagi confirmat, així que el cridador no pot tractar un temps d’espera com una fallada. Preserveu una identitat de petició duradora i feu servir el resultat del servei o un mecanisme d’idempotència abans de reintentar una mutació, o el reintent es converteix en una segona escriptura.
Les crides de retorn automàtiques de transaccions també poden executar-se més d’una vegada després d’un avortament reintentable, cosa que les fa un mal lloc per a efectes externs irreversibles. Manteniu-los fora de la crida de retorn tret que el flux de treball defineixi un protocol segur explícit per a ells. La mateixa precaució val per a qualsevol cosa que costi diners o enviï un missatge. Un càrrec duplicat és una conversa molt més difícil que una línia de registre duplicada.
L’acceptació hauria de reproduir quatre escenaris: dos clients que competeixen pel mateix registre, un avortament que el servei diu que es pot reintentar, una confirmació la resposta de la qual no arriba mai, i la pèrdua d’una regió o de l’enllaç entre elles. Registreu el resultat de negoci confirmat i els estats no resolts al costat del disseny d’encaminament, perquè ningú no confongui la xarxa amb el component que dona la garantia.