Este artículo lo guiará a través de transacciones distribuidas

1. ¿Qué es una transacción distribuida?

Antes de presentar esto, primero entendamos estos problemas.

1. ¿Qué es una transacción?

2. ¿Qué son los asuntos locales?

3. ¿Qué se distribuye?

4. ¿Qué es una transacción distribuida?

1.1 ¿Qué es una transacción?

Para lograr algo, puede haber múltiples participantes que necesiten realizar múltiples pasos y, en última instancia, múltiples pasos, todos tienen éxito o todos fallan.

Por ejemplo: A transfiere 100 yuanes a B en WeChat, la cuenta de A se reduce en 100 y la cuenta de B aumenta en 100. Esta es una transacción, y esta operación tiene éxito o falla.

Hay muchos escenarios de negocios, y los participantes también son diversos.

1. El registro de usuario envía correo correctamente, incluidas 2 operaciones: insertar información de usuario en db, enviar correo al usuario, 2 participantes principales: db, servidor de correo

2. El uso de Alipay para recargar la factura del teléfono incluye 2 operaciones: disminución de los fondos de la cuenta de Alipay, aumento del saldo del teléfono móvil, dos participantes principales: cuenta de Alipay, cuenta del proveedor de servicios de número de teléfono móvil

Hay varios participantes en la transacción, pero en este artículo usamos principalmente la transacción en db para ilustrar.

1.2 ¿Qué es una transacción local?

Transacciones locales, entendimiento popular: es decir, todas las operaciones en una transacción ocurren en la misma base de datos.

Por ejemplo, si A transfiere dinero a B, las cuentas de A y B se encuentran en la misma base de datos.

Por lo general, usamos bases de datos relacionales, como: MySQL, Oracle, SQL Server. Por defecto, estas bases de datos han realizado la función de transacciones, es decir, realizar una operación de transacción en una base de datos, y la base de datos en sí misma puede garantizar que esta transacción sea correcta. de la transacción, sin necesidad de que consideremos cómo garantizar la corrección de la transacción.

1.3 Cuatro características de las transacciones de bases de datos

1.3.1 Coherencia

El resultado después de la operación de transacción es consistente con el resultado esperado. A transfiere 100 a B. Después de que finaliza la transacción, se ve que la cuenta de A debe reducirse en 100 y la cuenta de B debe aumentar en 100. No sucederá nada más.

1.3.2 Atomicidad

Todo el proceso de una transacción es como una operación atómica, y eventualmente todos tienen éxito o todos fallan. Esta atomicidad se ve en el resultado final, y el proceso es indivisible del resultado final.

1.3.3 Aislamiento

La ejecución de una transacción no puede ser interferida por otras transacciones. Es decir, las operaciones y los datos utilizados en una transacción están aislados de otras transacciones simultáneas y las transacciones ejecutadas simultáneamente no pueden interferir entre sí.

1.3.4 Durabilidad

Una vez que se confirma una transacción, sus cambios en los datos de la base de datos deben ser permanentes. Una vez confirmada la transacción, los datos se conservarán en el disco duro y la modificación será permanente.

1.4 ¿Qué se distribuye?

Hay múltiples participantes para completar una determinada cosa, y los múltiples participantes se distribuyen en diferentes máquinas, y estas máquinas se comunican a través de la red u otros métodos.

Por ejemplo, si usa una tarjeta ICBC para recargar Alipay, la cuenta de la tarjeta ICBC se encuentra en la base de datos de ICBC, y la cuenta de Alipay se encuentra en la base de datos de Alipay, y las dos bases de datos están ubicadas en diferentes lugares.

1.5 ¿Qué es una transacción distribuida?

Todos entienden los dos conceptos de distribución y transacción, entonces la transacción distribuida es fácil de entender: múltiples participantes de la transacción se distribuyen en diferentes lugares.

Es fácil para nosotros garantizar la corrección de la transacción en una sola base de datos, pero ¿cómo garantizar la corrección de la transacción cuando los participantes de la transacción se encuentran en múltiples bases de datos?

Por ejemplo: A transfiere dinero a B, A está ubicado en DB1 y B está ubicado en DB2

step1.通过网络，给DB1发送指令：给A账户减少100
step2.通过网络，给DB2发送指令：给B账户增加100

Después de que el paso 1 tiene éxito, cuando se ejecuta el paso 2, la red falla, lo que conduce a la falla de la ejecución del paso 2. Al final: A se reduce en 100, pero B no aumenta en 100. El resultado final es inconsistente con el resultado esperado, lo que conduce al fracaso de la transacción.

Antes de presentar la solución de transacción distribuida, debemos comprender otros dos conceptos: CAP y teoría base , estas dos teorías proporcionan la base para la solución de transacción distribuida.

2. Teoría de la PAC

2.1 Comprender el concepto de PAC

CAP es la abreviatura de Consistencia, Disponibilidad y Tolerancia de partición, que representan consistencia, disponibilidad y tolerancia de partición respectivamente.

Vamos a explicarlo por separado a continuación:

Para facilitar la comprensión de la teoría CAP, combinamos algunos escenarios comerciales en el sistema de comercio electrónico para comprender CAP.

La siguiente figura muestra el proceso de ejecución de la gestión de información de mercancías:

 

 

El proceso general de ejecución es el siguiente:

1. El servicio de productos básicos solicita la base de datos principal para escribir información de productos básicos (agregar productos básicos, modificar productos básicos, eliminar productos básicos)

2. La base de datos principal escribe la respuesta al servicio de productos básicos con éxito.

3. Solicitudes de servicios de productos básicos para leer información de productos básicos de la base de datos.

2.1.1. C - Consistencia

Coherencia significa que la operación de lectura después de la operación de escritura puede leer el estado de datos más reciente. Cuando los datos se distribuyen en varios nodos, los datos leídos de cualquier nodo son el estado más reciente.

En la figura anterior, la lectura y escritura de la información del producto debe cumplir los siguientes objetivos:

1. Si el servicio básico se escribe con éxito en la base de datos maestra, la nueva consulta de datos en la base de datos esclava también se realiza correctamente.

2. Si el servicio básico no se escribe en la base de datos maestra, la consulta de nuevos datos de la base de datos esclava también falla.

¿Cómo lograr la consistencia?

1. Después de escribir en la base de datos maestra, los datos deben sincronizarse con la base de datos esclava.

2. Después de escribir en la base de datos maestra, bloquee la base de datos esclava durante la sincronización con la base de datos esclava y libere el bloqueo después de que se complete la sincronización, para evitar que el cliente consulte los datos antiguos de la base de datos esclava durante el proceso de escribir nuevos datos en la base de datos esclava.

Las características de la consistencia del sistema distribuido:

1. Debido al proceso de sincronización de datos, habrá un cierto retraso en la respuesta de la operación de escritura.

2. Para garantizar la coherencia de los datos, los recursos se bloquearán temporalmente y los recursos bloqueados se liberarán después de que se complete la sincronización de datos.

3. Si falla el nodo que solicita la sincronización de datos, se devolverá un mensaje de error y no se devolverán los datos antiguos.

2.1.2. A - Disponibilidad

Disponibilidad significa que cualquier operación de transacción puede obtener un resultado de respuesta y no habrá tiempo de espera de respuesta ni error de respuesta.

En la figura anterior, leer la información del producto para conocer la disponibilidad es lograr los siguientes objetivos:

1. Reciba la solicitud de consulta de datos de la base de datos y responda inmediatamente al resultado de la consulta de datos.

2. No se permite el tiempo de espera de respuesta o el error de respuesta de la base de datos.

¿Cómo lograr la usabilidad?

1. Después de escribir en la base de datos maestra, los datos deben sincronizarse con la base de datos esclava.

2. Para garantizar la disponibilidad de la base de datos esclava, los recursos de la base de datos esclava no se pueden bloquear.

3. Incluso si los datos no se han sincronizado, los datos a consultar deben devolverse desde la base de datos, incluso si son datos antiguos.Si no hay datos antiguos, se puede devolver un mensaje predeterminado de acuerdo con el acuerdo, pero no se puede devolver un error o un tiempo de espera de respuesta.

Características de la disponibilidad del sistema distribuido:

1. Se responden todas las solicitudes y no habrá tiempo de espera de respuesta ni error de respuesta.

2.1.3. P - Tolerancia de partición

Por lo general, cada nodo de un sistema distribuido se implementa en una subred diferente, que es una partición de red. Es inevitable que ocurra una falla de comunicación entre los nodos debido a problemas de red, y los servicios aún se pueden proporcionar externamente en este momento, lo que se denomina tolerancia de partición. .

En la figura anterior, la lectura y escritura de la información del producto para cumplir con la tolerancia de partición es lograr los siguientes objetivos:

1. La falta de sincronización de datos de la base de datos maestra con la base de datos esclava no afecta las operaciones de lectura y escritura.

2. La falla de un nodo no afecta el servicio proporcionado por el otro nodo.

¿Cómo lograr la tolerancia a la partición?

1. Trate de usar operaciones asincrónicas en lugar de sincrónicas, como el uso de métodos asincrónicos para sincronizar datos de la base de datos maestra con los datos esclavos, de modo que se pueda lograr de manera efectiva un acoplamiento débil entre los nodos.

2. Agregue nodos de base de datos esclavos, uno de los cuales cuelga otros nodos esclavos para proporcionar servicios.

Características de la tolerancia de partición distribuida:

1. La tolerancia a la partición es la capacidad básica de un sistema distribuido

2.2 Combinación de PAC

1. ¿El ejemplo anterior de administración de productos tiene CAP al mismo tiempo?

En todos los escenarios de transacciones distribuidas, las tres características de CAP no estarán disponibles al mismo tiempo, porque C y A no pueden coexistir bajo la premisa de P.

Por ejemplo:

La siguiente cifra satisface P, lo que significa que se logra la tolerancia de partición:

El significado de tolerancia de partición en esta figura es:

1) La base de datos maestra sincroniza los datos con los datos esclavos a través de la red.Se puede considerar que la base de datos maestro-esclavo se despliega en diferentes particiones e interactúa a través de la red.

2) Cuando haya un problema con la red entre la base de datos maestra y la base de datos esclava, no afectará los servicios externos proporcionados por la base de datos maestra y la base de datos esclava.

3) La falla de un nodo no afecta el servicio proporcionado por el otro nodo.

Si desea implementar C, debe garantizar la consistencia de los datos. Para evitar que se consulten datos inconsistentes desde la base de datos durante la sincronización de datos, debe bloquear los datos de la base de datos esclava y desbloquearlos después de que se complete la sincronización. Si la sincronización falla , la base de datos esclava devolverá un mensaje de error o información de tiempo de espera.

Si desea implementar A, debe garantizar la disponibilidad de los datos y puede consultar los datos de los datos esclavos en cualquier momento, y no responderá al tiempo de espera ni devolverá un mensaje de error.

Mediante el análisis se encuentra que existe una contradicción entre C y A bajo la premisa de satisfacer P, así:

En el caso de una partición de red, los datos de la base de datos maestra no se pueden sincronizar con la base de datos esclava. Para garantizar que los datos vistos por el exterior sean consistentes, no se puede acceder a la base de datos esclava desde el exterior en este momento, y solo la base de datos maestra puede proporcionar servicios externos y la base de datos esclava pierde su disponibilidad.

En el caso de una partición de red, los datos de la biblioteca maestra no se pueden sincronizar con la biblioteca esclava. En este momento, los datos de las dos bibliotecas son inconsistentes. Si esto permite que ambas bibliotecas brinden servicios externos (disponibilidad), el acceso los datos serán inconsistentes.

Por lo tanto, CAP no puede satisfacerse al mismo tiempo.

2. ¿Cuáles son las combinaciones de CAP?

Por lo tanto, al procesar transacciones distribuidas en producción, es necesario determinar qué dos aspectos de CAP se satisfacen de acuerdo con los requisitos.

1）PA:

Abandone la coherencia en busca de la tolerancia y la disponibilidad de la partición. Esta es la elección de muchos diseños de sistemas distribuidos.

Por ejemplo:

La gestión de productos anterior puede realizar completamente AP, siempre que el usuario pueda aceptar que los datos consultados no están actualizados dentro de un cierto período de tiempo.

Por lo general, la realización de AP garantizará la consistencia final. La teoría BASE mencionada más adelante se extiende en base a AP. Algunos escenarios comerciales como: reembolso del pedido, el reembolso de hoy es exitoso, se acreditará la cuenta de mañana, siempre que el usuario pueda aceptar dentro de un cierto período de tiempo Eso es todo.

2）PC:

Al renunciar a la disponibilidad y buscar la consistencia y la tolerancia a la partición, nuestro cuidador del zoológico en realidad busca una consistencia sólida.

3）CA:

Abandonar la tolerancia a la partición, es decir, no particionar, independientemente del problema de la falla de la red o el bloqueo del nodo, puede lograr consistencia y disponibilidad.

Entonces el sistema no será un sistema distribuido estándar y nuestros datos relacionales más utilizados satisfarán a CA.

Para la gestión de productos básicos anterior, si se va a implementar CA, la estructura es la siguiente:

La sincronización de datos ya no se realiza entre la base de datos maestra y la base de datos esclava, la base de datos puede responder a cada solicitud de consulta y cada solicitud de consulta puede devolver los datos más recientes a través del nivel de aislamiento de transacciones.

2.3 Resumen

A través de lo anterior, hemos aprendido el conocimiento relevante de la teoría CAP.CAP es una teoría probada: un sistema distribuido solo puede satisfacer los tres requisitos de consistencia (Consistencia), disponibilidad (Disponibilidad) y tolerancia de partición (Tolerancia de partición) al mismo tiempo. Dos de los artículos. Se puede utilizar como nuestro estándar de consideración para el diseño de arquitectura y la selección de tecnología. Para la mayoría de los escenarios de aplicaciones de Internet a gran escala, hay muchos nodos e implementaciones dispersas, y el tamaño actual del clúster 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 (99.99. .%), Y para lograr un buen rendimiento de respuesta para mejorar la experiencia del usuario, generalmente se toman las siguientes decisiones: garantizar P y A, descartar C consistencia fuerte y garantizar la consistencia final

3. Teoría básica

3.1 Comprender la consistencia fuerte y la consistencia eventual

La teoría CAP nos dice que un sistema distribuido solo puede satisfacer como máximo dos de los tres ítems de consistencia (Consistencia), disponibilidad (Disponibilidad) y tolerancia de partición (Tolerancia de partición), entre los cuales hay muchos AP en aplicaciones prácticas, y AP es Abandone la consistencia para garantizar la disponibilidad y la tolerancia a la partición, pero en la producción real, se debe lograr la consistencia en muchos escenarios. Por ejemplo, en el ejemplo que dimos anteriormente, la base de datos maestra sincroniza los datos con la base de datos esclava. Incluso si no se requiere consistencia, el los datos deben sincronizarse eventualmente Éxito para garantizar la consistencia de los datos. Esta consistencia es diferente de la consistencia en CAP. La consistencia en CAP requiere que los datos de cada nodo sean consistentes en todo momento. Enfatiza una consistencia fuerte, pero la consistencia final es La Se permite que los datos de cada nodo sean inconsistentes por un período de tiempo, pero los datos de cada nodo deben ser consistentes después de un período de tiempo. Esto enfatiza la consistencia de los datos finales.

3.2.1 Introducción a la teoría de bases

BASE es un acrónimo de las tres frases Basicly Available (básicamente disponible), Soft state (estado suave) y Eventualmente consistente (consistencia final). La teoría BASE es una extensión del AP en el CAP. La disponibilidad se obtiene sacrificando una fuerte consistencia. Cuando ocurre una falla, algunas partes no están disponibles, pero se garantiza que la función principal estará disponible. Se permite que los datos sean inconsistentes para un período de tiempo, pero eventualmente alcanza un estado consistente. La transacción que satisface la teoría BASE se denomina "transacción flexible".

3.2.2 Básicamente disponible

Cuando un sistema distribuido falla, se le permite perder algunas de las funciones disponibles para garantizar que las funciones principales estén disponibles. Por ejemplo, hay un problema con el pago de la transacción en el sitio web de comercio electrónico, pero los productos aún se pueden navegar normalmente.

3.2.3 Estado blando

Dado que no se requiere una consistencia fuerte, BASE permite la existencia de estados intermedios (también llamados estados blandos) en el sistema.Este estado no afecta la disponibilidad del sistema, como los estados de "pago" y "sincronización de datos" del pedido. Después de que los datos finalmente sean consistentes, el estado cambia a un estado "correcto".

3.2.4 Consistencia eventual

La consistencia final significa que después de un período de tiempo, todos los datos del nodo alcanzarán la consistencia. Por ejemplo, el estado de "Pago" del pedido eventualmente cambiará a "Pago exitoso" o "Pago fallido", de modo que el estado del pedido sea consistente con el resultado real de la transacción, pero se requiere un cierto período de demora y espera.

4. Cinco soluciones comunes para transacciones distribuidas

1. Esquema 1: 2PC (compromiso de dos fases)

2. Solución 2: 3PC (compromiso trifásico)

3. Opción 3: TCC

4. Escenario 4: Noticias confiables

5. Opción 5: notificación de mejor esfuerzo

Los siguientes cinco programas se presentan a su vez.

5. Esquema 1: 2PC (presentación en dos fases)

5.1 ¿Qué es 2PC?

2PC es una confirmación de dos fases, que divide todo el proceso de transacción en dos fases, la fase de preparación y la fase de confirmación. 2 se refiere a las dos fases, P se refiere a la fase de preparación y C se refiere a la fase de confirmación.

Los 2 roles principales en 2PC:

1. coordinador de transacciones

2. participantes de la transacción

5.1.1 Fase de preparación

El coordinador de transacciones envía un mensaje de preparación a cada participante de la transacción, y cada participante ejecuta la transacción local localmente pero no confirma la transacción (los recursos de la operación de transacción pueden estar bloqueados en este momento), y luego devuelve un mensaje de sí o no a el coordinador

5.1.2 Fase de compromiso

En la fase de preparación, todos los participantes devuelven Sí. En este momento, el coordinador de la transacción enviará un mensaje de confirmación a cada participante de la transacción. Después de recibir el mensaje de confirmación, el participante realizará una operación de confirmación en la transacción local.

Si un participante devuelve un no durante la fase de preparación, o el participante responde en horas extras (como razones de la red, que causan una falla de comunicación entre el coordinador de transacciones y el participante de transacciones), el coordinador de transacciones enviará un mensaje de reversión a cada participante de transacciones en este momento. tiempo, después de que el participante reciba el mensaje de reversión, realizará una operación de reversión en la transacción local.

5.1.3 Algunas reglas en 2pc

1. Condición de compromiso de fase 2: todos los participantes en la fase 1 devuelven sí

2. Condición de reversión de fase 2, 2 casos: cuando cualquier participante en la fase 1 devuelve no, o cualquier participante en la fase 1 responde con tiempo de espera

3. Cuando la preparación del participante puede tener éxito, el envío de compromiso al participante también debe tener éxito, y el envío de reversión debe poder revertir

4. En 2PC, el coordinador de transacciones tiene un mecanismo de tiempo de espera, es decir, en la fase 1, el coordinador envía un mensaje al participante, pero no ha respondido, lo que genera un tiempo de espera. En este momento, se ejecuta directamente el retroceso de la segunda etapa; mientras que el coordinador no agota el tiempo de espera La máquina, por ejemplo, todos los participantes han terminado de ejecutar la fase 1, y luego el coordinador cuelga, en este momento, los participantes solo pueden esperar y esperar.

5.1.4 Problemas con 2PC

1. Una vez completada la ejecución de la etapa 1, la transacción local del participante se ha ejecutado pero no se ha enviado. En este momento, los recursos en la transacción local del participante están bloqueados. Si el coordinador cuelga en este momento, la transacción local del participante ser bloqueado Los recursos no se pueden liberar, pero afectan directamente la ejecución de otros negocios.

   Por ejemplo, si el participante 1 reduce el inventario del producto 1, se bloqueará el registro de inventario del producto 1. Si otras empresas también necesitan modificar este registro en este momento, se bloqueará directamente y no se podrá ejecutar.

2. 2PC tiene problemas de rendimiento: por ejemplo, hay 10 participantes en la transacción, el participante 1 bloqueará el recurso local en la fase 1 y luego esperará a que los otros 9 participantes completen la fase 1, y luego el participante 1 recibe el compromiso enviado por el coordinador de transacciones O después de la reversión, los recursos se liberarán y el participante 1 deberá esperar a 9 participantes, lo que resultará en demasiado tiempo para bloquear los recursos, lo que afectará la concurrencia del sistema.

3. El coordinador tiene un único punto de falla: cuando se completa la ejecución de la fase 1, el coordinador cuelga, en este momento los participantes están confundidos y solo pueden esperar, esto se puede solucionar con la alta disponibilidad del coordinador, esto es resuelto en la pregunta de 3pc mencionada más adelante.

4. El problema de la inconsistencia de la transacción: en la fase 2, algunos participantes recibieron la información de confirmación. En este momento, el coordinador cuelga o el problema de la red hace que otros coordinadores no reciban la solicitud de confirmación. Durante este proceso, los datos de varios coordinadores se Solución: el coordinador y los participantes deben estar altamente disponibles, el coordinador admite el reintento de 2PC y las dos etapas en 2PC deben admitir la idempotencia.

5.2 Transacciones XA

XA (Arquitectura extendida) se refiere a la especificación del procesamiento de transacciones distribuidas propuesto por la organización X/Open. XA es un protocolo de transacciones distribuidas propuesto por Tuxedo, por lo que las transacciones distribuidas también se denominan transacciones XA.

El protocolo XA define principalmente la interfaz entre el administrador de transacciones TM (Transaction Manager, coordinador) y el administrador de recursos RM (Resource Manager, participante).

Entre ellos, los administradores de recursos a menudo son implementados por bases de datos, como Oracle, DB2 y MySQL.Todas estas bases de datos comerciales implementan interfaces XA, y los administradores de transacciones, como programador global, son responsables del envío y reversión de varios recursos locales.

Las transacciones XA se implementan en función del protocolo Two-phase Commit (2PC), que puede garantizar la coherencia de los datos. Muchos sistemas de gestión de datos relacionales distribuidos utilizan este protocolo para completar la distribución. La fase 1 es la fase de preparación, es decir, todos los participantes están listos para ejecutar la transacción y bloquear los recursos necesarios. Cuando el participante esté Listo, informe al TM que está listo. La fase dos es la fase de presentación. Cuando TM confirma que todos los participantes están listos, envía el comando COMMIT a todos los participantes.

En pocas palabras: XA es una implementación de 2PC en datos.

Todos han usado mysql, proceso de transacción común:

start transaction; //打开事务
执行事务操作
commit|rollback; // 提交或者回滚事务

En la operación de transacción anterior, si la conexión actual no envía una operación de confirmación o reversión, la conexión se interrumpe o mysql se reinicia, la transacción anterior se revertirá automáticamente.

La sintaxis de xa en mysql:

XA {START|BEGIN} xid [JOIN|RESUME]   //开启XA事务，如果使用的是XA START而不是XA BEGIN，那么不支持[JOIN|RESUME]，xid是一个唯一值，表示事务分支标识符
XA END xid [SUSPEND [FOR MIGRATE]]   //结束一个XA事务，不支持[SUSPEND [FOR MIGRATE]]
XA PREPARE xid 准备提交
XA COMMIT xid [ONE PHASE] //提交，如果使用了ONE PHASE，则表示使用一阶段提交。两阶段提交协议中，如果只有一个RM参与，那么可以优化为一阶段提交
XA ROLLBACK xid  //回滚
XA RECOVER [CONVERT XID]  //列出所有处于PREPARE阶段的XA事务

como:

xa start 'xa-1';
执行事务操作;
xa prepare 'xa-1'; //阶段1，此时事务操作的资源被锁住，事务未提交
xa commit | rollback;//阶段2

La transacción xa es un poco diferente de la transacción normal. La transacción xa anterior tiene un logotipo xa-1. Después xa-1de la preparación, si la conexión se interrumpe o se reinicia mysql, la transacción aún está en preparela etapa. Después de reiniciar mysql o la persona que llama se vuelve a conectar a mysql, puede retenerlo. El ID de la transacción xa-1continúa enviándose xa commit |rollbackpara finalizar la transacción.

Puede crear varios dbs en mysql y luego probar la confirmación de dos fases a través del script xa anterior para tener una idea del proceso.

5.3 Puntos clave del diseño del coordinador de transacciones en XA

En XA, los participantes de la transacción, como algunos dbs comunes, han realizado la función de 2PC, pero el coordinador debe desarrollarse por sí mismo.Algunos puntos de diseño del coordinador:

1. Genere un registro de identificación de transacción XA único a nivel mundial y regístrelo

2. El coordinador de transacciones debe tener la función de reintentar Para la operación anormal en la etapa intermedia, la transacción se puede completar finalmente a través de reintentos continuos

3. El coordinador volverá a intentar la operación, por lo que es necesario asegurarse de que cada etapa en 2pc sea idempotente

5.4 Solución 2PC

1. Seata : Seata es un proyecto de código abierto Fescar iniciado por el equipo de middleware de Alibaba, y luego rebautizado como Seata.Es un marco de transacciones distribuidas de código abierto que admite 2PC.

2. atomikos+jta : jta es una especificación de interfaz para transacciones distribuidas en java. atomikos es una implementación de jta, que se implementa internamente por medio de XA. Si los participantes de la transacción autoprueban las transacciones XA, pueden usar este método para resolver, por ejemplo , los participantes son: mysql, oracle, sqlserver, puede usar este método; pero el rendimiento es un problema digno de consideración de todos.

3. Los desarrolladores se dan cuenta por sí mismos  : después de que todos entiendan el proceso de 2pc, pueden desarrollar uno por sí mismos y desafiarlo.

6. Esquema 2: 3PC (compromiso de tres fases)

6.1 Revisión 2PC

Por ejemplo, si A invita a B y C a jugar Glory of Kings juntos, el proceso de 2PC es el siguiente:

A es el coordinador, B y C son los participantes.

6.1.1 Fase 1 (fase de preparación)

(1), paso 1-1: A WeChat B

step1-1-1：A->B：有空么，我们约C一起王者荣耀
step1-1-2：B->A：有空
step1-1-3：A->B：那你现在就打开电脑，登录王者荣耀，你等着，我去通知C，然后开个房间
step1-1-4：B->A：已登录

(2), paso 1-2: A WeChat C

step1-2-1：A->C：有空么，我约了B一起王者荣耀
step1-2-2：C->A：有空
step1-2-3：A->C：那你现在就打开电脑，登录王者荣耀，你等着，我去开个房间
step1-2-4：C->A：已登录

6.1.2 Fase 2 (fase de confirmación)

En este momento, tanto B como C ya han iniciado sesión en King of Glory, y luego A inicia sesión en King of Glory y abre una habitación.

(1), paso 2-1: A WeChat B

step2-1-1：A->B：房间号是xxx，你可以进来了
step2-1-2：B->A：我的，我进来了

(2), paso 2-2: A WeChat C

step2-2-1：A->C：房间号是xxx，你可以进来了
step2-2-2：C->A：我的，我进来了

Entonces los tres comenzaron a divertirse.

6.1.3 Algunas excepciones de 2PC

(1) Situación 1: paso 1-2-4 agotado, lo que hace que A no pueda recibir el mensaje de que C ha iniciado sesión

En este momento, A no sabe lo que está pasando con C, pero el coordinador en 2PC tiene un mecanismo de tiempo de espera Si el coordinador envía un mensaje a los participantes y no obtiene una respuesta durante mucho tiempo, se tratará como un fracaso En este momento, A le dará a B y C envía un mensaje de retroceso para que tanto B como C retrocedan, es decir, cancelen el juego.

(2), Situación 2: Después del paso 1-1, el coordinador A cuelga

En este momento, B ya encendió la computadora y esperó allí, pero A y C todavía no se ven por ningún lado. Está bastante angustiado y no sabe cuánto tiempo tendrá que esperar. ¡Es tan difícil!

(3), Situación 3: Después de la fase 1, el coordinador A cuelga

En este momento, B y C han iniciado sesión en sus cuentas y han estado esperando durante más de diez minutos. Incluso si A no se ve por ninguna parte, solo pueden esperar y no hacer nada.

(4), Situación 4: Hay un problema en el paso 2-2-1, falla de red C

En este momento, C no puede recibir el mensaje enviado por A. Como resultado, tanto A como B han entrado en la habitación y falta C. El juego no puede comenzar normalmente y el resultado final no es consistente con el resultado esperado (es se espera que 3 personas jueguen juntas, en realidad solo hay 2 personas en la sala)

6.1.4 En general, 2PC tiene dos problemas principales

Preguntas para que los participantes esperen

Los participantes solo pueden actuar de acuerdo con las instrucciones del coordinador. Cuando no se reciben las instrucciones del coordinador, los participantes solo pueden sentarse y esperar. Como resultado, en la base de datos, los datos de la operación estarán bloqueados todo el tiempo, lo que provocará que otros operadores ser bloqueado

problema de inconsistencia de datos

En la fase de compromiso, si el coordinador o el participante cuelga, puede generar el problema de la inconsistencia de los datos finales.

6.2. 3PC

3PC resuelve principalmente el problema de los participantes que esperan en la fase de confirmación de 2PC En la fase de confirmación de 2PC, si el coordinador cuelga, los participantes no saben cómo salir. En 2PC, solo el coordinador tiene un mecanismo de tiempo de espera, mientras que en 3PC, el coordinador y los participantes han introducido un mecanismo de tiempo de espera En la fase de compromiso, si el participante no recibe el comando de compromiso después de un cierto período de tiempo, el participante automáticamente enviar para resolver el problema Resuelve el problema del recurso bloqueado durante mucho tiempo en 2PC.

En comparación con 2PC, 3PC tiene una etapa más, lo que equivale a dividir la etapa de preparación de 2PC en dos nuevamente, de modo que la presentación de tres etapas tiene CanCommit, PreCommity DoCommittres etapas.

6.2.1 Fase 1: Fase CanCommit

La etapa anterior de 2PC es que después de que se complete la ejecución de la transacción local, no se confirmará al final y esperará a que otros servicios completen la ejecución y devuelvan Sí, y el coordinador emitirá una confirmación antes de ejecutar realmente la confirmación. , y CanCommit aquí se refiere a intentar adquirir el bloqueo de la base de datos. Si es  posible  , simplemente devuelva Sí.

Esta etapa se divide principalmente en 2 pasos

Consulta de transacción: el coordinador envía una solicitud CanCommit al participante. Pregunte si se puede realizar una operación de compromiso de transacción. Luego comience a esperar una respuesta del compromiso.

Comentarios de respuesta: después de que el participante recibe la solicitud CanCommit, en circunstancias normales, si cree que la transacción se puede ejecutar sin problemas, devolverá una respuesta Sí y entrará en el estado listo. De lo contrario, responda No y luego la transacción finaliza y el participante no realiza ninguna operación en la tarea en este momento.

6.2.2 Fase 2: Fase de compromiso previo

En la fase uno, si todos los participantes devuelven Sí, entonces entrará en la fase de compromiso previo para el compromiso previo de la transacción. La etapa PreCommit aquí  es similar a la primera etapa anterior, excepto que tanto  el coordinador como los participantes han introducido un mecanismo de tiempo de espera (en 2PC, solo el coordinador puede tener tiempo de espera y los participantes no tienen mecanismo de tiempo de espera).

6.2.3 Fase 3: Fase DoCommit

Esto es similar a la segunda etapa de 2pc.

6.3 Proceso King of Glory 3PC

6.3.1 Proceso normal

(1), Fase 1 (fase CanCommit)

paso 1-1: A WeChat B

step1-1-1：A->B：有空么，我们约C一起王者荣耀
step1-1-2：B->A：有空

paso 1-2: Un WeChat C

step1-1-1：A->B：有空么，我们约B一起王者荣耀
step1-1-2：B->A：有空

(2), Fase 2 (fase PreCommit)

paso 2-1: A WeChat B

step2-1-1：A->B：你现在就打开电脑，登录王者荣耀，等我消息，如果10分钟没消息，你就自己开个房间玩吧（参与者超时机制）。
step2-1-2：B->A：已登录

paso 2-2: Un WeChat C

step2-2-1：A->C：那你现在就打开电脑，登录王者荣耀，等我消息，如果10分钟没消息，你就自己开个房间玩吧（参与者超时机制）。
step2-2-2：C->A：已登录

(3), Fase 3 (fase DoCommit)

En este momento, tanto B como C ya han iniciado sesión en King of Glory, y luego A inicia sesión en King of Glory y abre una habitación.

paso 3-1: A WeChat B

step3-1-1：A->B：房间号是xxx，你可以进来了
step3-1-2：B->A：我的，我进来了

paso 3-2: Un WeChat C

step3-2-1：A->C：房间号是xxx，你可以进来了
step3-2-2：C->A：我的，我进来了

Entonces los tres comenzaron a divertirse.

6.3.2 Varias situaciones de excepción

(1), excepción de etapa 1

No hay ninguna operación de transacción en este momento, por lo que si algo sale mal en esta etapa, la transacción se puede finalizar directamente.

(2), etapa 2, el participante cuelga

No importa si el participante cuelga, el coordinador notifica directamente a otros participantes que retrocedan.

(3), fase 2, el coordinador cuelga

El coordinador cuelga. Debido a que el participante ha introducido un mecanismo de tiempo de espera, el participante no esperará indefinidamente. Después de esperar un cierto período de tiempo, la transacción local se enviará automáticamente.

Si bien este mecanismo de tiempo de espera resuelve el problema de la espera infinita, no resuelve el problema de la consistencia. Por ejemplo, después del 3PC anterior step2-1：A微信B, el coordinador cuelga. En este momento, A ha iniciado sesión, pero C no ha recibido el mensaje de que A solicita iniciar sesión. Tiempo de espera Después de 10 minutos, A fue a abrir un juego solo para jugar y el resultado fue inconsistente con el resultado esperado.

6.4 Problemas con 3PC

Aunque resuelve el problema del bloqueo a largo plazo de los participantes en 2PC (problema de que los recursos no se pueden liberar durante mucho tiempo), no resuelve el problema de la consistencia.

¿Hay alguna forma de evitar estos problemas?

Sí, TCC, ahora veamos TCC.

7. Esquema 3: TCC

7.1 ¿Qué es TCC?

Varios roles en transacciones distribuidas

• TM: administrador de transacciones, que puede entenderse como el iniciador de transacciones distribuidas

• Transacción de sucursal: múltiples participantes en una transacción pueden entenderse como transacciones independientes.

TCC es la abreviatura de las tres palabras Probar, Confirmar y Cancelar TCC requiere que cada transacción de sucursal implemente tres operaciones: preprocesamiento Probar, confirmar Confirmar y deshacer Cancelar.

La operación Try realiza la verificación comercial y la reserva de recursos, Confirm realiza operaciones de confirmación comercial y Cancel implementa una operación opuesta a Try, es decir, una operación de reversión.

TM primero inicia la operación de prueba de todas las transacciones de la sucursal. Si la operación de prueba de cualquier transacción de la sucursal falla, TM iniciará la operación de cancelación de todas las transacciones de la sucursal. Si todas las operaciones de prueba tienen éxito, TM iniciará la operación de confirmación de todas las transacciones de la sucursal. Si la operación Confirmar/Cancelar falla, TM volverá a intentarlo.

7.1.1 Flujo normal

Fase de prueba: llama al método de prueba del participante a su vez, y todos regresan con éxito

Fase de confirmación: llama al método de confirmación del participante a su vez, y todos regresan con éxito

La transacción está completa.

7.1.2 Flujo de excepción

Fase de prueba: llame al método de prueba de los participantes por turno, los primeros dos participantes prueban métodos devuelven sí, y el participante 3 devuelve no

Fase de cancelación: ejecuta la operación de cancelación en los participantes exitosos Nota: el orden de los participantes en la fase de cancelación es inverso al de los participantes en la fase de prueba, es decir, se llama primero la cancelación del participante 2 y luego la cancelación del participante 1 se llama .

7.2 Caso del escenario TCC

7.2.1 Caso 1: Transferencia entre bibliotecas

Por ejemplo, el escenario es que A transfiere 100 yuanes a B y las cuentas de A y B están en diferentes servicios.

账户A
try：
 try幂等校验
 检查余额是否够100元
 A账户扣减100元
confirm：
 空
cancel：
 cancel幂等校验
 A账户增加可用余额100元

账户B
try：
 空
confirm：
 confirm幂等校验
 B账户增加100元
cancel：
 空

7.2.2 Caso 2: Retiro a Alipay

Por ejemplo, todos han jugado Douyin, y algunos amigos tienen ingresos en Douyin, y pueden retirar los ingresos a Alipay. Si retira 100 a Alipay

抖音(账户表：余额、冻结金额)
try：
 try幂等校验
 检查余额是否够100元
 抖音账户表余额-100，冻结金额+100
confirm：
 confirm幂等校验
 抖音账户冻结金额-100
cancel：
 cancel幂等校验
 抖音账户表余额+100，冻结金额-100

账户B
try：
 空
confirm：
 confirm幂等校验
 调用支付宝打款接口，打款100元（对于商户同一笔订单支付宝接口是支持幂等的）
cancel：
 空

7.3 Marco común de TCC

nombre del marco	dirección de github	número de estrellas
transacción tcc	https://github.com/changmingxie/tcc-transacción	4750
humildad	https://github.com/Dromara/hmily	2900
byteTCC	https://github.com/liuyangming/ByteTCC	2450
EasyTransaction	https://github.com/QNJR-GROUP/EasyTransaction	2100

7.4 Ideas de diseño de marco TCC de desarrollo propio

7.4.1 Roles involucrados (iniciador de la transacción, participante de la transacción, servicio TCC)

(1), iniciador de transacciones (TM)

• Iniciar una transacción distribuida: llame al servicio tcc para registrar una orden de transacción distribuida

• llamar a sucursal: llame a cada sucursal por turno

• Reporte de resultados: finalmente reporte los resultados de ejecución de todas las ramas de la transacción al servicio TCC

• Proporcionar interfaz de compensación: utilizado por el servicio TCC, el servicio tcc llamará a esta interfaz de compensación para realizar la operación de compensación

(2), participantes de la transacción

• Proporcione 3 métodos: probar, confirmar, cancelar

• Asegurar la idempotencia de 3 métodos

• Solo hay 3 códigos de estado de resultado devueltos por los 3 métodos (éxito, falla y procesamiento). El procesamiento es equivalente a un estado desconocido. Para aquellos cuyo estado es desconocido, se realizarán reintentos durante el proceso de compensación.

(3), servicio TCC

• es un servicio independiente

• Proporcione una interfaz de registro de orden de transacción distribuida: utilice [el iniciador de la transacción llama al servicio tcc para generar una orden de transacción distribuida (estado del pedido: 0: procesamiento, 1: procesamiento exitoso, 2: procesamiento fallido) para que el iniciador de la transacción obtenga una transacción distribuida pedido ID de pedido: TID]

• Proporcione una interfaz de informes de resultados de transacciones distribuidas: para que la use el iniciador de transacciones [El iniciador de transacciones informa el resultado de la ejecución de la transacción al servicio TCC durante la ejecución de la transacción]

• Proporcione una operación de compensación de transacción: inicie un trabajo para sondear el pedido cuyo estado es 1 en el pedido tcc, continúe llamando al iniciador de la transacción para compensar y, finalmente, después de múltiples compensaciones, el estado final de este pedido debe ser 1 (éxito) o 2 (fallo); de lo contrario, intervención manual para el procesamiento

7.4.2 Diagrama de tiempos

](img/5.jpg)

7.4.3 Puntos técnicos del marco TCC de desarrollo propio

(1) Dónde debe considerarse el marco

Los desarrolladores solo deben prestar atención al código de los tres métodos en la rama, y ​​el marco debe completar el resto.

(2), diseño de la tabla de órdenes de transacciones en el servicio tcc

• identificación: identificación del pedido

• bus_order_id: identificación del pedido comercial

• bus_order_type: tipo de empresa (bus_order_id y bus_order_type deben ser únicos)

• request_data: datos de solicitud comercial, almacenados en formato json, incluidos los datos de solicitud del lado comercial divertido

• estado: estado, 0: procesamiento, 100: procesamiento exitoso, 200: procesamiento fallido, el estado inicial es 0 y el estado final debe ser 100 o 200

(3), sobre el diseño idempotente de los tres métodos en la rama

Tomando Spring en Java como ejemplo, se puede realizar a través de un interceptor, que intercepta los tres métodos de la rama e implementa operaciones idempotentes en el interceptor.

Se puede realizar con una tabla [tabla de registro de ejecución del método de bifurcación: tid, bifurcación, método (intentar, confirmar, cancelar), estado (0: procesamiento; 100: éxito; 200: falla), request_json (parámetros de solicitud), response_json ( parámetro de respuesta)]

Acerca de los parámetros de la solicitud: se utiliza para registrar los parámetros completos de la solicitud del método completo, que contiene parámetros comerciales y se puede almacenar en formato json.

Parámetro de respuesta: el resultado de la ejecución del método de bifurcación, almacenado en formato json.

En el interceptor, use las dos condiciones de branch & method para consultar la tabla de registro de ejecución del método de branch.Si el estado del registro de consulta es 100 o 200, devuelva el response_json directamente.

(4), la fase de prueba es síncrona y las otras fases son asíncronas

Si la fase de prueba es exitosa, entonces la fase de confirmación debe ser exitosa al final. Si hay una falla en la fase de prueba, entonces se debe ejecutar la cancelación. Al final, todas las cancelaciones también deben ser exitosas; así que después de la se completa la fase de prueba, el resultado final ya se conoce. Como resultado, después de que se completa la fase de prueba, la confirmación o cancelación subsiguiente se puede ejecutar de manera asíncrona, mejorando el rendimiento general del sistema.

(5), informa de forma asíncrona los resultados de la ejecución de transacciones

El iniciador informa los resultados de ejecución de cada paso de todas las sucursales y los resultados de ejecución de la transacción final al servicio tcc, y el servicio tcc los coloca en el almacén, lo cual es conveniente para que los operadores vean los resultados de ejecución de transacciones y solucionen problemas.

(6) Sobre la compensación

Agregue un trabajo de compensación al servicio tcc, sondee periódicamente la tabla de pedidos distribuidos de tcc y extraiga los registros cuyo estado se está procesando. La tabla de pedidos request_data contiene parámetros de solicitud y use request_data para llamar a la interfaz de compensación proporcionada por el iniciador de la transacción para realizar operaciones de compensación Hasta que el estado del pedido sea definitivo (éxito o fracaso).

La compensación es en forma de atenuación, y correspondiente al mismo orden, se compensa en forma de atenuación de intervalo de tiempo, cada intervalo: 10s, 20s, 40s, 80s, 160s, 320s. . .

(7), intervención manual

Si el pedido distribuido de tcc ha estado en proceso durante mucho tiempo, después de muchas veces de compensación, no ha alcanzado el estado final. En este momento, puede haber problemas comerciales y se requiere una compensación manual. Para este par de registros de pedidos, se requiere un sistema de monitoreo para alarmar y recordarle al desarrollo que intervenga.

7.5 Resumen

Si compara el flujo de procesamiento de las transacciones de TCC con la confirmación de dos fases de 2PC, 2PC suele estar en el nivel de base de datos de bases de datos cruzadas, mientras que TCC está en el nivel de la aplicación, que es una implementación de 2PC en el nivel de la aplicación y debe implementarse. a través de la lógica de negocios. La ventaja de esta implementación de transacciones distribuidas es que permite que las aplicaciones definan la granularidad de las operaciones de datos, lo que permite reducir los conflictos de bloqueo y mejorar el rendimiento. La desventaja es que es muy intrusivo para la aplicación, y cada rama de la lógica empresarial necesita implementar las tres operaciones de probar, confirmar y cancelar, y la cantidad de código es relativamente grande.

8. Escenario 4: Noticias confiables

8.1 ¿Qué es la consistencia eventual de un mensaje confiable?

El esquema de consistencia eventual del mensaje confiable significa que cuando el iniciador de la transacción completa la transacción local y envía un mensaje, el participante de la transacción (consumidor del mensaje) debe poder recibir el mensaje y procesar la transacción con éxito. se envía al participante de la transacción La transacción final de ambas partes debe llegar a un consenso.

Hay 2 puntos clave aquí:

1. Después de que la transacción local del remitente del mensaje se ejecute con éxito, el mensaje se entregará con éxito

2. El consumidor del mensaje eventualmente podrá consumir este mensaje y, finalmente, la transacción distribuida finalmente llegará a un consenso.

8.2 Escenario empresarial: realizar un pedido para enviar puntos

Existe tal escenario en el comercio electrónico: después de ordenar el producto, los puntos deben enviarse al usuario.La tabla de pedidos y la tabla de puntos están en bases de datos diferentes, lo que implica transacciones distribuidas.

Abordamos esto con mensajes confiables:

1. Usamos mq para lograr la operación de envío de puntos después de que el pedido se haya realizado con éxito

2. Una vez que el pedido del producto se realiza correctamente, se envía un mensaje a mq y el sistema de puntos consume el mensaje para aumentar los puntos para el usuario.

Analicemos principalmente cómo implementar la operación de realizar un pedido de un producto y enviar un mensaje a mq. ¿Ventajas y desventajas de cada método?

8.3 Proceso de entrega de mensajes: Método 1

8.3.1 Proceso

• paso 1 : Abrir transacción local

• paso 2 : Generar una orden de compra

• paso 3 : Publique el mensaje en mq

• paso 4 : enviar transacciones locales

Esta forma es enviar el mensaje antes de que se confirme la transacción.

8.3.2 Posibles problemas

• Ocurrió una excepción en el paso 3 : resultó en la falla del paso 4, la falla en realizar un pedido del producto, lo que afecta directamente el negocio de realizar un pedido del producto.

• Se produjo una excepción en el paso 4 y los demás pasos se realizaron correctamente : el pedido del producto falló, el mensaje se entregó correctamente y se agregaron puntos al usuario

8.4 Proceso de entrega de mensajes: Método 2

A continuación, cambiemos la forma, enviaremos el mensaje después de la transacción.

8.4.1 Proceso

• paso 1 : Abrir transacción local

• paso 2 : Generar una orden de compra

• paso 3 : Enviar transacciones locales

• paso 4 : Publique el mensaje en mq

8.4.2 Posibles problemas

Ocurrió una excepción en el paso 4, y los otros pasos fueron exitosos : lo que resultó en un pedido exitoso de productos, falla en la entrega de mensajes y sin puntos agregados por el usuario

Las dos anteriores son prácticas más comunes, pero también las más propensas a errores.

8.5 Proceso de entrega de mensajes: Método 3

• paso 1 : Abrir transacción local

• paso 2 : Generar una orden de compra

• paso 3 : inserte un registro t_msg_record que necesita enviar un mensaje en la biblioteca local

• paso 3 : Enviar transacciones locales

• paso 5 : agregue un temporizador, sondee t_msg_record y publique los registros que se enviarán a mq

Este método utiliza transacciones de base de datos, negocios y registros de mensajes como una operación atómica.Después de que el negocio sea exitoso, el registro de mensajes debe existir. Se resuelven los problemas encontrados en las dos primeras formas. Si nuestro sistema de negocios es relativamente simple, podemos usar este método.

Para el caso de los microservicios, el método anterior no es muy bueno, cada servicio necesita las operaciones anteriores; tampoco es propicio para la expansión.

8.6 Proceso de entrega de mensajes: Método 4

Agregue un servicio de mensajes y una biblioteca de mensajes , que es responsable del almacenamiento de mensajes, el envío y la entrega de mensajes a mq.

• paso 1 : Abrir transacción local

• paso 2 : Generar una orden de compra

• paso 3 : inserte un registro en la biblioteca de transacciones actual: genere una identificación comercial única (bus_id), asocie bus_id con el pedido y guárdelo en la biblioteca donde se encuentra la transacción actual

• Paso 4 : llame al servicio de mensajes: lleve el bus_id y coloque el mensaje en el almacén primero. En este momento, el estado del mensaje está esperando para ser enviado y devuelva la identificación del mensaje (msg_id)

• paso 5 : enviar transacciones locales

• paso 6 : si todo lo anterior tiene éxito, llame al servicio de mensajes y entregue el mensaje a mq; si lo anterior falla, llame al servicio de mensajes para cancelar el envío del mensaje

Se puede considerar que el método anterior ha avanzado mucho, sigamos analizando los posibles problemas:

1. Se agrega un servicio de mensajes al sistema. La operación de pedido de productos básicos depende de este servicio, y el negocio depende en gran medida de este servicio. Cuando el servicio de mensajes no está disponible, todo el negocio no estará disponible.

2. Si el paso 6 falla, el mensaje estará en el estado de envío. En este momento, el lado comercial debe proporcionar una interfaz de verificación (a través de la consulta bus_id) para verificar si el negocio se ejecuta correctamente; el servicio de mensajes debe agregar un mensaje programado tarea, y para el mensaje que está en el estado de ser enviado Hacer el procesamiento de compensación, verificar si el negocio se procesa con éxito; así determinar si el mensaje se entrega o se cancela

3. El paso 4 se basa en el servicio de mensajes. Si el rendimiento del servicio de mensajes es deficiente, el tiempo de envío de transacciones del negocio actual se prolongará, se producirán interbloqueos fácilmente y se reducirá el rendimiento de la concurrencia . Por lo general, somos tabú para hacer el procesamiento de llamadas remotas en las transacciones. El rendimiento y el tiempo de las llamadas remotas a menudo son incontrolables, lo que hará que la transacción actual se convierta en una transacción grande, lo que provocará otras fallas.

8.7 Proceso de entrega de mensajes: Método 5

En los métodos anteriores, continuamos mejorando y apareció una mejor manera:

• Paso 1 : genere una identificación de mensaje comercial única a nivel mundial (bus_msg_id), llame al servicio de mensajes, lleve el bus_msg_id y coloque el mensaje en el almacén primero. En este momento, el estado del mensaje está pendiente de envío y devuelva la identificación del mensaje ( msg_id)

• paso 2 : Abrir transacción local

• paso3 : Generar una orden de compra

• paso 4 : inserte un registro en la biblioteca de transacciones actual (asocie el negocio en el paso 3 con bus_msg_id)

• paso 5 : enviar transacciones locales

• paso 6 : hay dos casos: si lo anterior tiene éxito, llame al servicio de mensajes y entregue el mensaje a mq; si hay una falla anterior, llame al servicio de mensajes para cancelar el envío del mensaje

Si el paso 6 falla, el mensaje estará en el estado de envío En este momento, la parte comercial debe proporcionar una interfaz de respuesta (a través de la consulta bus_msg_id) para verificar si el negocio se ejecutó con éxito;

El servicio de mensajes necesita agregar una nueva tarea programada para compensar los mensajes cuyo estado está pendiente de enviar, y verificar si el negocio se procesa correctamente; así determinar si el mensaje es entregado o cancelado.

En comparación con el método 5 y el método 4, uno de los mejores puntos es que la llamada al servicio de mensajes y la operación de aterrizaje del mensaje se realizan fuera de la transacción. Esta pequeña mejora es en realidad una muy buena optimización, que reduce el tiempo de ejecución del mensaje. transacción local. , para que se pueda aumentar la cantidad de simultaneidad. Ali tiene un middleware de mensajes RocketMQ que admite el método 5, y puede usarlo.

8.8 Algunas preguntas sobre el consumo de mensajes

¿Cómo solucionar el problema del consumo repetido?

El consumidor sondea para extraer mensajes del servidor mq y luego los consume.

El proceso de consumidores de mensajes que consumen mensajes

• paso 1 : extraer mensajes de mq

• paso 2 : Ejecutar negocios locales, como agregar puntos

• paso 3 : después del consumo, elimine el mensaje de mq

Cuando el paso 2 tiene éxito y el paso 3 falla, el mensaje se extraerá de mq nuevamente y habrá un problema de consumo repetido, por lo que debemos considerar la idempotencia del consumo. El resultado del consumo múltiple y un consumo del mismo mensaje debe ser Consistentemente, la idempotencia es otro tema, que será discutido en detalle la próxima vez.

9. Escenario 5: notificación de mejor esfuerzo

9.1 Caso recarga Alipay

Si tenemos nuestro propio sistema de comercio electrónico que permite a los usuarios usar Alipay para recargar, el proceso es el siguiente:

9.2 Proceso de pago del usuario (es un proceso síncrono)

1. El usuario inicia una solicitud de recarga en el navegador -> servicio de comercio electrónico

2. El servicio de comercio electrónico genera una orden de recarga, y el estado es 0: pago pendiente (0: pago pendiente, 100: pago exitoso, 200: pago fallido)

3. El servicio de comercio electrónico solicita a Alipay la información del pedido, genera un pedido de Alipay, ensambla la dirección de solicitud de pago de Alipay (información del pedido, la página return_url que se muestra al usuario después de que el pago se haya realizado correctamente y la dirección de notificación de pago asincrónico notificar_url), y devuelve la información ensamblada al usuario

4. El navegador del usuario salta a la página de pago de Alipay para confirmar el pago.

5. Alipay lleva el resultado del pago y devuelve la llamada return_url sincrónicamente, y return_url mostrará el resultado del pago al usuario

9.3. Alipay notifica al comerciante el resultado del pago de forma asíncrona

Una vez finalizado el proceso de pago del usuario, la orden de pago en Alipay ha sido pagada en este momento, pero el estado de la orden de recarga en el e-commerce sigue siendo 0 (pendiente de pago), en este momento Alipay notificará el resultado del pago para notificar_url de forma asincrónica. Durante el proceso de notificación, la notificación de Alipay puede fallar debido a problemas de red. En este momento, Alipay hará todo lo posible para notificar al comerciante el resultado a través de múltiples reintentos atenuantes. Este proceso es el tipo de notificación de mejor esfuerzo .

Después de recibir la notificación de Alipay, el comerciante procesa el pedido local de manera idempotente y luego informa a Alipay que el procesamiento se realizó correctamente, después de lo cual Alipay ya no enviará notificaciones.

9.4 ¿Qué son las notificaciones en descomposición?

Por ejemplo, Alipay intentará notificar hasta 100 veces y el intervalo entre cada notificación aumentará. Por ejemplo, después de la primera falla, la segunda notificación se realiza cada 10 s, y después de la segunda falla, la tercera notificación se realiza cada 30 s, y los intervalos se incrementan a su vez.

9.5 ¿Qué debo hacer si falla la notificación de Alipay?

Los comerciantes pueden tomar la iniciativa de llamar a la interfaz de consulta de Alipay para consultar el estado de pago del pedido.

9.6 ¿Por qué se requiere la notificación asíncrona?

¿No hay un return_url en el proceso de pago del usuario? Después de que Alipay pague con éxito, llamará a esta dirección sincrónicamente con el resultado del pago, de modo que el comerciante pueda procesar directamente el estado del pedido local en este return_url? Este método es posible, pero la red del usuario puede ser mala y la llamada a return_url falla.En este momento, el resultado del pago debe notificarse al comerciante mediante una notificación asincrónica de notificar_url.

9.7 ¿Para qué se utiliza el tipo de notificación de mejor esfuerzo?

En una transacción distribuida, si el resultado de la llamada no se puede conocer de inmediato, la parte llamada puede tardar mucho tiempo en procesar el negocio.Después de que se procesa el negocio de la parte llamada, el resultado se puede notificar a la persona que llama mediante una notificación de mejor esfuerzo.

9.8 La notificación de mejor esfuerzo debe tener un mecanismo de compensación

La parte llamada hará todo lo posible para notificar el resultado a la persona que llama. En casos extremos, existe la posibilidad de falla. En este momento, la parte llamada debe proporcionar una interfaz de consulta.

La persona que llama puede dirigirse activamente a la parte llamada para preguntar sobre el negocio cuyo resultado no se conoce desde hace mucho tiempo y luego procesarlo.

9.9 ¿Puedo tomar la iniciativa de verificar sin notificación?

Sí, la parte llamada proporcionará una interfaz de consulta y la persona que llama puede conocer el resultado consultando de manera proactiva, pero el método de notificación es más en tiempo real.

Después de que la persona que llama tenga éxito, la persona que llama será notificada de inmediato, pero la persona que llama adopta activamente el método de consulta, entonces, ¿cuándo consultar? Este grado es difícil de entender, por lo que la combinación de los dos es mejor.

10. Análisis Comparativo de Transacciones Distribuidas

Después de estudiar varias soluciones de transacciones distribuidas, aprendimos las ventajas y desventajas de varias soluciones:

La mayor crítica de 2PC es que es un protocolo de bloqueo. RM debe esperar la decisión de TM después de ejecutar la transacción de sucursal, y el servicio bloqueará y bloqueará los recursos en este momento. Debido a su mecanismo de bloqueo y su alta complejidad de tiempo en el peor de los casos, este diseño no puede adaptarse a las necesidades de expansión a medida que aumenta la cantidad de servicios involucrados en la transacción, y es difícil de usar para alta concurrencia y ciclo de vida largo de subtransacción ( transacciones de larga duración) servicios distribuidos.

Si compara el flujo de procesamiento de las transacciones de TCC con la confirmación de dos fases de 2PC, 2PC generalmente se encuentra en el nivel de base de datos en todas las bases de datos, mientras que TCC se procesa en el nivel de la aplicación y debe implementarse a través de la lógica comercial. La ventaja de esta implementación de transacciones distribuidas es que permite que las aplicaciones definan la granularidad de las operaciones de datos, lo que permite reducir los conflictos de bloqueo y mejorar el rendimiento . La desventaja es que es muy intrusivo para la aplicación y cada rama de la lógica de negocios necesita implementar tres operaciones: probar, confirmar y cancelar. Además, su implementación es relativamente difícil y se deben implementar diferentes estrategias de reversión de acuerdo con diferentes razones de falla, como el estado de la red y la falla del sistema. Escenarios de uso típicos: completo, iniciar sesión para enviar cupones, etc.

Las transacciones de consistencia eventual de mensajes confiables son adecuadas para escenarios con ciclos de ejecución largos y requisitos de tiempo real bajos. Después de la introducción del mecanismo de mensajes, la operación de transacción síncrona se convierte en una operación asíncrona basada en la ejecución de mensajes, lo que evita la influencia de las operaciones de bloqueo síncrono en transacciones distribuidas y realiza el desacoplamiento de los dos servicios. Escenarios de uso típicos: regístrese para obtener puntos, inicie sesión para obtener cupones, etc.

La notificación de mejor esfuerzo es uno de los requisitos más bajos en las transacciones distribuidas y es adecuada para algunas empresas con baja sensibilidad temporal de consistencia eventual; permite que la parte iniciadora maneje las fallas comerciales y las maneja activamente después de que la parte receptora recibe la notificación. independientemente del iniciador La forma en que la parte notificante maneja los resultados no afectará el procesamiento posterior de la parte notificante; la parte notificante iniciadora debe proporcionar una interfaz de ejecución de consultas para que la parte notificante receptora verifique los resultados. Escenarios de uso típicos: notificación bancaria, notificación de resultado de pago, etc.

	2PC	TCC	noticias confiables	notificación de mejor esfuerzo
consistencia	consistencia fuerte	eventualmente consistente	eventualmente consistente	eventualmente consistente
rendimiento	Bajo	medio	alto	alto
complejidad de implementación	fácil	Desastre	medio	fácil

11. Resumen

Cuando las condiciones lo permiten, hacemos todo lo posible para elegir una sola fuente de datos para las transacciones locales, ya que reduce la pérdida de rendimiento causada por la interacción de la red y evita varios problemas causados ​​por una coherencia de datos débil. Si un sistema utiliza transacciones distribuidas de manera frecuente e irrazonable, primero debe observarse desde la perspectiva del diseño general si la división del servicio es razonable, si es de alta cohesión y bajo acoplamiento. ¿La granularidad es demasiado pequeña? Las transacciones distribuidas siempre han sido un problema en la industria debido a la incertidumbre de la red, y estamos acostumbrados a comparar transacciones distribuidas con transacciones independientes ACID.

Ya sea XA en la capa de la base de datos, TCC en la capa de la aplicación, mensajes confiables, notificaciones de mejor esfuerzo, etc., ninguno de ellos resuelve perfectamente el problema de las transacciones distribuidas. Solo hacen concesiones en términos de rendimiento y consistencia. , y disponibilidad, y busque algunas compensaciones bajo preferencia.