sistema de transacciones distribuidas

¿Qué es una transacción distribuida?

Transacción distribuida significa que los participantes de la transacción, el servidor que soporta la transacción, el servidor de recursos y el administrador de transacciones están respectivamente ubicados en diferentes nodos de diferentes sistemas distribuidos.
En pocas palabras, una gran operación se compone de diferentes operaciones pequeñas. Estas pequeñas operaciones se distribuyen en diferentes servidores y pertenecen a diferentes aplicaciones. Las transacciones distribuidas deben garantizar que estas pequeñas operaciones tengan éxito o fracasen.
En esencia, las transacciones distribuidas son para garantizar la consistencia de los datos de diferentes bases de datos (bases de datos correspondientes a diferentes negocios, múltiples bases de datos causadas por la misma subbase de datos comercial).

características de la transacción

Las transacciones tienen cuatro atributos: atomicidad, consistencia, aislamiento y durabilidad. Estas cuatro propiedades a menudo se denominan propiedades ACID.

• Atomicidad: todas las operaciones en una transacción se completan o no se completan, y no terminarán en un cierto enlace en el medio. Si se produce un error durante la ejecución de la transacción, se restaurará al estado anterior al inicio de la transacción, como si la transacción nunca se hubiera ejecutado.
• Consistencia (consistencia): antes de que comience la transacción y después de que finalice la transacción, no se ha violado la integridad de la base de datos. La integridad incluye restricciones de clave externa, restricciones definidas por la aplicación, etc. no se violan.
• Aislamiento: la capacidad de la base de datos para permitir que múltiples transacciones simultáneas lean, escriban y modifiquen sus datos al mismo tiempo. El aislamiento puede evitar la inconsistencia de los datos causada por la ejecución cruzada cuando se ejecutan múltiples transacciones al mismo tiempo.
• Durabilidad (persistencia): Después de que finaliza el procesamiento de la transacción, la modificación de los datos es permanente, incluso si el sistema falla, no se perderá.
  Las bases de datos convencionales, como MySQL y PostgreSQL, admiten transacciones ACID y utilizan internamente la tecnología MVCC (control de concurrencia de múltiples versiones) para lograr transacciones locales de alto rendimiento y alta concurrencia.

teoría distribuida

Las transacciones distribuidas involucran múltiples nodos y son un sistema distribuido típico, que es muy diferente de un sistema independiente. Un sistema distribuido solo puede satisfacer como máximo dos de los tres elementos de consistencia (Coherencia), disponibilidad (Disponibilidad) y tolerancia de partición (Tolerancia de partición), lo que se denomina teoría CAP.

Consistencia

En un sistema distribuido, los datos generalmente existen en copias de diferentes nodos. Si los datos del primer nodo se actualizan con éxito, pero los datos del segundo nodo no se actualizan en consecuencia, entonces lea el segundo. Los datos del nodo siguen siendo los datos. antes de la actualización, es decir, datos sucios, que es el caso de inconsistencia de datos en el sistema distribuido.

Disponibilidad

Después de que fallan algunos nodos en el clúster, si el clúster en su conjunto aún puede responder a las solicitudes de lectura y escritura del cliente.
En las aplicaciones modernas de Internet, si el servicio no está disponible durante mucho tiempo debido a problemas como el tiempo de inactividad del servidor, es inaceptable.

Tolerancia de partición

En términos prácticos, la partición es equivalente a un requisito de límite de tiempo para la comunicación. Si el sistema no puede lograr la consistencia de los datos dentro del límite de tiempo, significa que se ha producido una partición y se debe elegir entre C y A para la operación actual.

compensaciones

Para la mayoría de los escenarios de aplicaciones de Internet a gran escala, hay muchos hosts e implementaciones dispersas, y el tamaño del clúster actual es cada vez más grande, por lo que las fallas de los nodos y las fallas de la red son normales, y se debe garantizar que la disponibilidad del servicio llegue a N 9, es decir , P y A están garantizados y descartados c.

teoría BÁSICA

BASE es una abreviatura de las tres frases Basically Available (básicamente disponible), Soft state (estado suave) y Eventualmente consistente (consistencia final). BASE es el resultado de la compensación entre consistencia y disponibilidad en CAP, que se deriva de la sistema de Internet a gran escala. La conclusión de la práctica distribuida se basa en la evolución gradual del teorema CAP. La idea central es que incluso si no se puede lograr una consistencia fuerte (consistencia fuerte), cada aplicación puede usar métodos apropiados de acuerdo con su propio negocio. características El sistema alcanza la consistencia eventual.

• La disponibilidad básica significa que un sistema distribuido puede perder parte de su disponibilidad en caso de fallas impredecibles. Tenga en cuenta, sin embargo, que esto de ninguna manera equivale a la indisponibilidad del sistema.
• El estado débil también se denomina estado blando, a diferencia del estado duro, lo que significa que los datos en el sistema pueden tener un estado intermedio y se cree que la existencia del estado intermedio no afectará la disponibilidad general. del sistema, es decir, el sistema está permitido entre copias de datos de diferentes nodos Hay un retraso en el proceso de sincronización de datos.
• La consistencia final enfatiza que todas las copias de datos en el sistema finalmente pueden alcanzar un estado consistente después de un período de sincronización. Por lo tanto, la esencia de la coherencia final es que el sistema debe garantizar que los datos finales puedan ser coherentes y no necesita garantizar la gran coherencia de los datos del sistema en tiempo real.

Diversos modelos de negocio en la industria.

El negocio de transferencias bancarias interbancarias es un escenario típico de transacciones distribuidas. Suponiendo que A necesita transferir dinero a B entre bancos, involucra los datos de dos bancos. El ACID de la transferencia no puede garantizarse a través de una transacción local de una base de datos. y solo puede resolverse a través de transacciones distribuidas.

Role:

• RM: administrador de recursos
• TM: Administrador de transacciones
• AplicaciónPrograma: aplicación.

Ejemplo:

Queremos realizar un negocio similar a las transferencias interbancarias, transfiriendo 30 yuanes de A a B.

Compromiso de dos fases/XA

XA es una especificación para transacciones distribuidas propuesta por la organización X/Open.La especificación XA define principalmente la interfaz entre el administrador de transacciones (global) y el administrador de recursos (RM) (local). Las bases de datos locales como mysql desempeñan el papel de RM en XA.

características

• Simple y fácil de entender, fácil de desarrollar
• Los recursos están bloqueados durante mucho tiempo y la concurrencia es baja

ejecutar lógica

La primera fase (preparar): es decir, todos los participantes RM están listos para ejecutar la transacción y bloquear los recursos requeridos. Cuando el participante está listo, le informa al TM que está listo.
La segunda fase (commit/rollback): cuando Transaction Manager™ confirma que todos los participantes (RM) están listos, envía un comando de confirmación a todos los participantes.
En la actualidad, las bases de datos principales básicamente admiten transacciones XA, incluidas mysql, oracle, sqlserver y postgre.

Diagrama de tiempo

SAGA

Una vez que Saga llega a la etapa Cancelar, Cancelar no puede fallar en términos de lógica comercial. Si no se devuelve el éxito debido a la red u otras fallas temporales, TM seguirá intentándolo hasta que Cancelar devuelva el éxito.

características

• Alta simultaneidad, sin necesidad de bloquear recursos durante mucho tiempo como las transacciones XA
• Es necesario definir la operación normal y la operación de compensación, la cantidad de desarrollo es mayor que XA
• La consistencia es débil Para la transferencia, puede suceder que el usuario A haya descontado el dinero y la transferencia final falle

ejecutar lógica

Servicio de transferencia de salida (TransOut), donde se realizará la transferencia de salida
Servicio A-30 TransOut Compensate (TransOutCompensate), retrotraer la operación de transferencia de salida anterior, es decir,
servicio de transferencia de entrada A+30 (TransIn), la transferencia de entrada será B +30
Servicio TransInCompensate (TransInCompensate), revertir la operación de transferencia anterior, es decir, B-30

Diagrama de tiempo

caso normal

caso de excepción

TCC

¿Qué es TCC? TCC es la abreviatura de las palabras Probar, Confirmar y Cancelar. Fue propuesto por primera vez por Pat Helland en un artículo titulado "La vida más allá de las transacciones distribuidas: la opinión de un apóstata" publicado en 2007.

ejecutar lógica

• Fase de prueba: intente ejecutar, complete todas las verificaciones comerciales (coherencia), reserve los recursos comerciales necesarios (cuasi-aislamiento)
• Etapa de confirmación: si la prueba de todas las sucursales tiene éxito, vaya a la etapa de confirmación. Confirm realmente ejecuta el negocio sin ninguna verificación comercial y solo utiliza los recursos comerciales reservados en la fase Try
• Fase Cancelar: Si uno de los Try de todas las ramas falla, pase a la fase Cancelar. Cancelar libera los recursos comerciales reservados en la fase Try.

características

• Alta simultaneidad, sin bloqueo de recursos a largo plazo
• La cantidad de desarrollo es grande y se debe proporcionar una interfaz Probar/Confirmar/Cancelar
• La consistencia es buena, y no sucederá que SAGA haya descontado el dinero y finalmente no haya podido transferir el dinero.

escena del juicio

• adecuado para asuntos cortos
• Aplicable a negocios de pedidos, negocios con restricciones en el estado intermedio

Diagrama de tiempo

caso normal

caso de excepción

tabla de mensajes locales

El esquema de la tabla de mensajes locales fue publicado originalmente en 2008 por el arquitecto de eBay Dan Pritchett para ACM. El núcleo del diseño es garantizar de forma asincrónica la ejecución de tareas que requieren procesamiento distribuido a través de mensajes.

ejecutar lógica

Mecanismo de tolerancia a fallas:

• Cuando falla la transacción del saldo de deducción, la transacción se revierte directamente sin más pasos
• Si el mensaje de producción de rotación falla o la transacción de aumento de saldo falla, se volverá a intentar

características

• Las transacciones largas solo necesitan dividirse en múltiples tareas, fáciles de usar
• El productor necesita crear adicionalmente la tabla de mensajes.
• Cada tabla de mensajes local necesita ser encuestada
• No se admite la reversión: si la lógica del consumidor no logra reintentar correctamente, se necesitan más mecanismos para revertir la operación.
• El sondeo de mensajes de producción es difícil de lograr. Si el sondeo regular prolongará el tiempo total de la transacción, si se suscribe a binlog, será difícil de desarrollar y mantener.

escena del juicio

• Aplicable a empresas que se pueden ejecutar de forma asincrónica y las operaciones posteriores no necesitan revertirse

mensaje transaccional

En la solución de tabla de mensajes local mencionada anteriormente, el productor necesita crear una tabla de mensajes adicional y también necesita sondear la tabla de mensajes local, y la carga comercial es pesada. El RocketMQ 4.3 de código abierto de Alibaba y las versiones posteriores admiten oficialmente los mensajes de transacción, que esencialmente colocan la tabla de mensajes locales en RocketMQ para resolver el problema de atomicidad entre el envío de mensajes en el lado de producción y la ejecución de transacciones locales.

ejecutar lógica

• enviar mensaje (medio mensaje)
• El servidor almacena el mensaje y responde al resultado de escritura del mensaje.
• Ejecute la transacción local de acuerdo con el resultado del envío (si la escritura falla, el medio mensaje es invisible para la empresa en este momento y la lógica local no se ejecuta)
• Ejecute Commit o Rollback de acuerdo con el estado de la transacción local (la operación Commit publica un mensaje y el mensaje es visible para los consumidores)
  

Proceso de compensación

Para los mensajes de transacción sin Commit/Rollback (mensajes en estado pendiente), se inicia un "chequeo" desde el servidor. Después de recibir el
mensaje de chequeo, el Productor devuelve el estado de la transacción local correspondiente al mensaje, que es el Commit o Esquema de mensaje de transacción de reversión
y mensaje local. El mecanismo de la tabla es muy similar, la principal diferencia es que la operación original de la tabla local relacionada se reemplaza por una interfaz de búsqueda inversa.

características

• Las transacciones largas solo necesitan dividirse en múltiples tareas, y se proporciona una interfaz de consulta inversa, que es fácil de usar
• No existe un buen plan para la revisión de los mensajes de transacción y pueden ocurrir errores de datos en casos extremos.

escena del juicio

• Aplicable a empresas que se pueden ejecutar de forma asincrónica y las operaciones posteriores no necesitan revertirse

notificación de mejor esfuerzo

El notificador iniciador hace todo lo posible para notificar a la parte que notifica el resultado del procesamiento comercial, pero es posible que el mensaje no se reciba. En este momento, la parte notificante debe llamar activamente a la interfaz de la parte notificante para consultar el resultado del procesamiento comercial. La confiabilidad de la notificación radica en recibir la plaza de notificación.

• Proporcione una interfaz para que la parte notificada pueda consultar los resultados del procesamiento comercial a través de la interfaz
• El mecanismo ACK de la cola de mensajes, la cola de mensajes aumenta gradualmente el intervalo de notificación según el intervalo de 1 min, 5 min, 10 min, 30 min, 1 h, 2 h, 5 h, 10 h, hasta que se alcanza el límite superior de la ventana de tiempo requerida por la notificación. sin más notificaciones

escena del juicio

• Los resultados de las transacciones de WeChat incluyen notificaciones de devolución de llamada e interfaces de consulta de transacciones.

Modo AT

Este es un modo de transacción en el asiento del proyecto de código abierto de Ali, también conocido como FMT en Ant Financial. La ventaja es que el uso de este modo de transacción es similar al modo XA. No es necesario escribir varias operaciones de compensación para el negocio, y el marco completa automáticamente la reversión. Este modo también tiene muchas desventajas. Por un lado Por otro lado, es similar a XA, y hay bloqueos a largo plazo, que no cumplen con la alta concurrencia. Por otro lado, hay problemas como la reversión sucia, que puede conducir fácilmente a la inconsistencia de los datos. Si está interesado, puede hacer clic en ATGithub , en documentos

Mensajes de dos fases (un nuevo esquema para transacciones distribuidas)

El envío de Msg se inicia en dos fases. La primera fase llama a Prepare, y la segunda fase llama a Commit. Después de que DTM recibe la llamada de Prepare, no llamará a la transacción de la sucursal, sino que esperará el envío posterior. Solo cuando se recibe Enviar, se inicia la llamada a la sucursal y finalmente se completa la transacción global.
Necesitamos transferir 30 yuanes de A a B entre bancos. Primero realizamos la operación TransOut que puede fallar, es decir, deducir 30 yuanes de A. Si A no deduce debido a saldo insuficiente, entonces la transferencia falla directamente y se devuelve un error; si la deducción es exitosa, entonces se realiza la siguiente operación de transferencia, porque no hay problema de saldo insuficiente en la transferencia. operación, se puede suponer que la operación de transferencia será exitosa.

características

• No se necesita cola, por lo que no se necesita consumidor, el usuario simplemente llama a la API
• El mensaje de la segunda etapa también tiene una respuesta, pero la respuesta es procesada automáticamente por el marco y se garantiza que los datos sean correctos.

Diagrama de tiempo

caso normal

Comprobación de excepción

Esta función de devolución consultará la tabla para ver si se ha enviado la transacción local:

• Enviado: devolución exitosa, DTM llamará a la próxima subtransacción
• Retrocedido: no se pudo regresar, DTM finaliza la transacción global y ya no llama a las subtransacciones
• En progreso: esta verificación esperará el resultado final y luego la procesará de acuerdo con la situación enviada/revertida anterior
• No iniciado: esta verificación insertará datos en la base de datos local de RM para garantizar que la transacción local finalmente falle.

Caso de excepción después de la presentación

Caso de excepción antes de la presentación

Excepciones y Barreras a Subtransacciones

PNJ

• Retardo de red: retardo de red. Aunque la red funciona bien en la mayoría de los casos, aunque TCP garantiza el orden de transmisión y la ausencia de pérdidas, no puede eliminar el problema del retraso de la red.
• Pausa del proceso: El proceso está en pausa. Hay muchas razones que pueden hacer que el proceso se detenga: por ejemplo, GC (mecanismo de recolección de basura) en los lenguajes de programación suspenderá todos los subprocesos en ejecución; por otro ejemplo, a veces suspendemos el servidor en la nube para que el servidor en la nube pueda ser reiniciado sin reiniciar Migración de un host a otro. No podemos predecir con certeza la duración de las pausas del proceso. Puede pensar que unos cientos de milisegundos es mucho tiempo, pero de hecho, no es raro que un proceso se detenga durante varios minutos.
• Deriva del reloj. En la vida real, solemos pensar que el tiempo transcurre sin problemas y aumenta monótonamente, pero no en las computadoras. Las computadoras usan hardware de reloj para medir el tiempo, generalmente relojes de cuarzo, que tienen una precisión de cronometraje limitada y se ven afectados por la temperatura de la máquina. Para sincronizar la hora entre varias máquinas en la red hasta cierto punto, el protocolo NTP generalmente se usa para alinear la hora del dispositivo local con un servidor horario dedicado.Un resultado directo de esto es que la hora local del dispositivo puede moverse repentinamente hacia adelante o hacia atrás después del salto.

Clasificación de anomalías

• Compensación nula: las operaciones de reversión se realizan antes de las solicitudes de confirmación previa
• Colgante: cuando se ejecuta la confirmación previa, se ha ejecutado la reversión
• Idempotencia: dado que cualquier solicitud puede tener excepciones de red y solicitudes repetidas, todas las operaciones de sucursales de transacciones distribuidas deben garantizar la idempotencia.

Causa anormal (TCC como ejemplo)

• Al procesar la solicitud 4, se ejecuta Cancelar antes de Probar y se debe procesar la reversión vacía
• Cuando la solicitud de procesamiento comercial 6, Cancel se ejecuta repetidamente, lo que requiere idempotencia
• Cuando la solicitud de procesamiento comercial 8, Try se ejecuta después de Cancelar, y la suspensión debe procesarse

barrera de subtransacción

Realización del principio

El principio de la tecnología de barrera de subtransacción es crear una tabla de estado de operación de sucursal dtm_barrier en la base de datos local, y la clave única es la transacción global id-branch id-branch operation

• Iniciar una transacción local
• Para la operación actual op, inserte ignore un dato gid-branchid-op, si la inserción no tiene éxito, envíe la transacción y devuelva el éxito (método de control idempotente común)
• Si la operación actual es de reversión, ignore un dato gid-branchid-op en la inserción, si la inserción es exitosa (tenga en cuenta que es exitosa), la transacción se confirmará y devolverá el éxito
• Llame a la lógica comercial en la barrera. Si el negocio regresa con éxito, la transacción se confirmará y se devolverá con éxito; si el negocio regresa fallado, la transacción se revertirá y se devolverá como falla

Principio Descripción

• Control de compensación vacío: si no se ejecuta Pre y se ejecuta directamente Rollback, la inserción de rollback en 3 será exitosa y no se seguirá la lógica en la barrera, lo que garantiza el control de compensación nula.
• Control idempotente: cualquier operación en 2 no puede insertar repetidamente la clave única, lo que garantiza que no se repetirá
• Control antibloqueo: Pre se ejecuta después de Rollback, luego Rollback insertará gid-branchid-op en 3, lo que provocará que Pre falle en 2, y la lógica en la barrera no se ejecutará, lo que garantiza el control antibloqueo.

análisis de carrera

El análisis anterior puede resolver el problema de la compensación vacía y la suspensión cuando el tiempo de ejecución de Pre y rollback no se superpone. Veamos qué sucede si el tiempo de ejecución de pre y rollback se superpone.
Suponiendo que Pre y Rollback se ejecutan simultáneamente, tanto Pre como Rollback insertarán el mismo registro gid-branchid-op. Debido al conflicto de índice único, solo una de las dos operaciones puede tener éxito, y la otra regresará después de la transacción que contiene el el bloqueo se ha completado. .

• La inserción previa de gid-branchid-op falla y la operación de reversión que inserta gid-branchid-op tiene éxito. Este es un escenario típico de suspensión y compensación nula. De acuerdo con el algoritmo de barrera de subtransacción, tanto Pre como Rollback regresarán directamente.
• Preinserta gid-branchid-op con éxito, y la operación de reversión falla al insertar gid-branchid-op.De acuerdo con el algoritmo de barrera de subtransacción anterior, el negocio se ejecutará normalmente y el orden de ejecución del negocio es pre-compromiso antes de revertir
• Si la operación de Pre y Rollback encuentra un tiempo de inactividad durante el período de superposición, dtm volverá a intentar al menos Rollback, y finalmente pasará a la situación 1 o 2.

resumen

Patrón de mensaje de dos fases

Adecuado para escenarios que no requieren reversión

• Escenario de venta flash: cuando la cantidad de visitas de venta flash es muy grande, la mayoría de los sistemas optarán por deducir el inventario en redis y crear un pedido después de que la deducción sea exitosa. No hay reversión en este escenario, que es adecuado para mensajes de dos fases. El mensaje de dos fases también puede garantizar que, en caso de que se bloquee el proceso, el inventario deducido sea exactamente igual al pedido creado.
• Escenario de administración de caché: es un escenario muy común usar el caché Redis para proporcionar datos y reducir la presión sobre la base de datos. Normalmente, la base de datos se actualizará primero y la memoria caché se actualizará sin retroceder

modo saga:

Adecuado para escenarios que requieren reversión

• Suponiendo que tiene un negocio de pedidos, debe asegurarse de que la creación de su pedido, la deducción de inventario y la deducción de cupones sean exitosas o fallidas al mismo tiempo . Bueno, se ajusta a la Saga.

modo de transacción tcc

Adecuado para escenarios con altos requisitos de consistencia

• Supongamos que tiene un negocio como la transferencia de fondos, que requiere una alta consistencia y no permite que los usuarios vean el cambio de saldo en el medio cuando falla la transferencia . Esta situación es adecuada para TCC, que puede controlar de manera flexible toda la visibilidad de datos de transacciones globales.

modo de transacción xa

Adecuado para escenarios con requisitos de simultaneidad bajos y sin contención de bloqueo de fila de base de datos

• Suponiendo que su negocio no requiera una alta simultaneidad y que no habrá múltiples solicitudes que compitan por la misma fila de datos (por ejemplo, no habrá deducción del mismo inventario de productos básicos), puede elegir XA.