Escrituras multirrexión: onde se confirma realmente o cambio?
O enrutamento leva unha petición a unha rexión; só unha fronteira de transacción fai atómicas as escrituras. Nomee a invariante, escolla o propietario e deseñe despois o reintento arredor dela.
Dous servidores de aplicación en dúas rexións, un cliente que escribe a través dunha VPN e unha pregunta que ninguén escribiu: que compoñente decide que a escritura ocorreu? O enrutamento leva a petición ata un proceso. Unha fronteira de transacción decide cando o cambio pasa a ser duradeiro e visible. Son traballos distintos feitos por sistemas distintos, e a fenda entre eles é onde viven a maioría dos erros de escritura multirrexión.
Comece pola regra de negocio, non polo mapa
Comece cunha frase sobre a regra de negocio e non sobre a xeografía: que lecturas e escrituras teñen que ter éxito xuntas e que cambios concorrentes deben ser imposibles mentres o fan. Para unha reserva de inventario iso significa que a comprobación de existencias e a reserva ou ambas toman efecto ou ningunha, e ningún segundo pedido pode consumir a mesma unidade entretanto.
| 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 |
Esa fila central é a que os equipos saltan. A atomicidade sen illamento suficiente permite que dúas transaccións se confirmen correctamente cada unha e aínda así produzan un estado que o negocio considera imposible, e ningunha cantidade de lóxica de reintento o repara despois.
Unha fronteira autoritativa gaña a dous servidores rexionais
Os servidores de aplicación rexionais poden quedar onde están, sempre que envíen a operación a un servizo que a execute dentro dunha única fronteira de transacción admitida. A capa de aplicación convértese nun enrutador de intención; a capa de datos posúe a verdade.
Manteña esa fronteira curta e preto dos datos que toca. Unha transacción aberta mentres unha persoa responde a un aviso, ou mentres unha chamada cruza dúas rexións, pasa o tempo suxeitando bloqueos e aumentando a probabilidade de que algo máis expire detrás dela. Ese fallo parece un problema de base de datos e en realidade é un problema de deseño disfrazado de un. Mover a decisión á capa de datos adoita eliminalo por completo.
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;Lea ese esbozo como unha fronteira, non como unha recomendación de rendemento. A clave é que a comprobación e a inserción comparten unha confirmación, así que un pedido concorrente ou ve o stock consumido ou non o ve nunca.
Que lle dá e que non lle dá unha base de datos replicada
Unha base de datos replicada pode ofrecer unha fronteira máis ampla cando o seu propio modelo de transacción o permite. Spanner documenta transaccións atómicas de lectura e escritura dentro dunha soa base de datos entre táboas, con illamento e comportamento de reintento definidos. É unha garantía que un le, proba e emprega a propósito.
Tamén é unha garantía que vén do produto, non da ruta. Unha VPN entre rexións cambia como viaxan os paquetes e como se presentan os fallos. Non estende unha fronteira de transacción nin unha soa fila, por moi san que pareza o túnel. Confundir ambas as dúas cousas produce arquitecturas nas que cada compoñente pasa a súa propia comprobación e os datos seguen sen coincidir.
Dúas bases de datos non se converten nun só sistema
Dúas bases de datos xestionadas de forma independente non adquiren un xestor de transaccións compartido porque os clientes poidan alcanzar ambas. Se o negocio necesita de verdade un compromiso atómico entre as dúas, o mecanismo de coordinación, os participantes e o proceso de recuperación teñen que escollerse e cualificarse en lugar de darse por supostos.
Pense no momento en que un participante ou unha ligazón desaparece despois de que o traballo se preparase. Unha confirmación distribuída admitida pode deixar un estado en dúbida que necesita un procedemento de recuperación e unha decisión humana, e non vén coa promesa de que cada rexión siga sendo escribible durante cada partición.
Se en cambio é aceptable unha coordinación asíncrona, dígao explicitamente e escriba os estados de negocio intermedios xunto coas regras de reconciliación. Unha cadea de pasos confirmados localmente con compensación é un deseño lexítimo; simplemente non é unha transacción atómica con outro nome.
Deseñe o reintento antes da primeira caída
Un cliente pode perder a resposta despois de que a operación se confirme, así que quen chama non pode tratar un tempo de espera como un fallo. Preserve unha identidade de petición duradeira e use o resultado do servizo ou un mecanismo de idempotencia antes de reintentar unha mutación, ou o reintento convértese nunha segunda escritura.
As chamadas de retorno automáticas de transaccións tamén poden executarse máis dunha vez tras un aborto reintentable, o que as fai un mal lugar para efectos externos irreversibles. Manteña os fóra da chamada de retorno a non ser que o fluxo de traballo defina un protocolo seguro explícito para eles. A mesma precaución se aplica a calquera cousa que custe diñeiro ou envíe unha mensaxe. Un cargo duplicado é unha conversación moito máis difícil que unha liña de rexistro duplicada.
A aceptación debería reproducir catro escenarios: dous clientes competindo pola mesma fila, un aborto que o servizo di que se pode reintentar, unha confirmación cuxa resposta nunca chega e a perda dunha rexión ou da ligazón entre elas. Rexistre o resultado de negocio confirmado e os estados sen resolver xunto ao deseño de enrutamento, para que ninguén confunda a rede co compoñente que achega a garantía.