Spring: método de implementación y alternativa de transacción distribuida por microservicio

Métodos y alternativas de implementación de transacciones distribuidas por microservicios

En los últimos dos días, estoy trabajando en una solución para transacciones distribuidas en la arquitectura de microservicios, y hago un pequeño resumen como nota. Si hay errores, ¡corríjame!

Aclaracion conceptual

• Mecanismo de compensación de transacciones : en cualquier operación de transacción a plazo en la cadena de transacciones, debe haber una transacción reversible que se ajuste completamente a la regla de reversión.
• Teoría CAP : CAP (Consistencia, Disponibilidad, Tolerancia de Partición), que elabora los tres aspectos principales de un sistema distribuido, que solo puede lograrse eligiendo dos al mismo tiempo. Sistemas CP comunes, sistemas AP.
• Idempotencia : En pocas palabras, las operaciones comerciales admiten reintentos sin efectos adversos Implementación común: agregue una identificación única al mensaje.
• BASE (Básicamente disponible, estado blando, eventualmente consistente): es un estándar teórico para la implementación de transacciones distribuidas.

Transacciones flexibles versus transacciones rígidas

Las transacciones rígidas se refieren a transacciones que siguen estrictamente el principio ACID, como las transacciones de bases de datos en un entorno independiente.

Las transacciones flexibles se refieren a las transacciones que siguen la teoría BASE, y generalmente se usan en un entorno distribuido. Los métodos de implementación comunes son: confirmación de dos fases (2PC), confirmación compensada de TCC, garantía asíncrona basada en mensajes y notificación de mejor esfuerzo.

En general, las transacciones rígidas se usan para transacciones locales, y las transacciones flexibles se usan para transacciones distribuidas.

Primero llegue a la conclusión, y luego introduzca varios métodos de implementación de transacciones distribuidas.

• Si los escenarios empresariales requieren una gran coherencia, intente evitar colocarlos en diferentes servicios, es decir, utilice las transacciones locales tanto como sea posible y evite las transacciones distribuidas con una gran coherencia.
• Si el escenario empresarial puede aceptar la coherencia final, lo mejor es utilizar una solución de coherencia final basada en mensajes (tipo de garantía asíncrona) para resolver.
• Si los escenarios empresariales requieren una gran coherencia y solo pueden implementar servicios distribuidos , es mejor utilizar la solución TCC en lugar de la solución 2PC.

Nota: Cada una de las siguientes soluciones tiene diferentes ocasiones aplicables y debe seleccionarse de acuerdo con el escenario comercial real.

1. Mejores prácticas

    Intente evitar colocar una transacción en diferentes servicios, es decir, intente usar transacciones locales, evite transacciones distribuidas con una fuerte consistencia, cada microservicio en teoría solo devuelve resultados, que es el mejor método. Por supuesto, no se pueden evitar las transacciones en diferentes microservicios, utilice el siguiente método.

Dos, presentación en dos fases (2PC)

Two Phase Commit (2PC), con una fuerte consistencia, es una implementación típica del sistema CP.

Presentación en dos fases, los estándares comunes son XA, JTA, etc. Por ejemplo, la base de datos Oracle admite XA.

La siguiente figura es un diagrama esquemático de la presentación en dos fases:

La primera mitad de la figura es una demostración del éxito de la presentación en dos fases, y la segunda mitad es una demostración del fracaso de la presentación en dos fases. Hay muchas explicaciones clásicas sobre la presentación en línea de dos fases , y no daré más detalles aquí. Puede consultar el enlace anterior.

Desventajas

• En la segunda fase de la confirmación de dos fases, el coordinador debe esperar a que todos los participantes emitan una solicitud de sí, o que un participante emita una solicitud de no antes de realizar la operación de confirmación o interrupción. Esto hará que múltiples recursos se bloqueen simultáneamente durante mucho tiempo, lo que resulta en el rendimiento El cuello de botella , si el participante tiene una operación larga, la pérdida de rendimiento será más obvia.
• La implementación es complicada, lo que no conduce a la expansión del sistema, y ​​no se recomienda.

3. Tipo compensatorio de TCC (Try-Confirm-Cancle)

TCC es una implementación de un sistema AP basado en transacciones compensatorias y tiene la máxima consistencia.

Lo siguiente utiliza la operación de pago cuando el cliente compra los bienes como un ejemplo para explicar:

• Intente:
  complete todas las comprobaciones comerciales (consistencia) y reserve los recursos comerciales necesarios (cuasi-aislamiento);
  en este ejemplo, es para confirmar que el saldo de la cuenta del cliente es suficiente para pagar (consistencia), bloquear la cuenta del cliente y la cuenta mercantil (cuasi Aislamiento).
• Confirmar:
  utilice los recursos comerciales reservados en la etapa Try para ejecutar el negocio (la operación comercial debe ser idempotente). Si la ejecución es anormal, se requiere un nuevo intento.
  Aquí, se realiza la deducción de la cuenta del cliente y la operación de débito de la cuenta comercial.
• Cancle:
  libere los recursos comerciales reservados en la fase de prueba, aquí es para liberar el bloqueo de la cuenta del cliente y la cuenta del comerciante;
  si alguna de las subempresas no puede realizar la operación con éxito en la fase de confirmación, hará que la respuesta al gerente de actividad comercial se agote, en este momento Para realizar transacciones compensatorias para otros negocios. Si la operación compensatoria también es anormal, debe ser reintentada. Si es imposible de ejecutar con éxito, el administrador de transacciones debe ser capaz de detectar la operación fallida y realizar el registro (para la compensación post-manual (Las operaciones de transacción o middleware se hacen cargo y realizan operaciones de transacción compensatorias más adelante).

Ventaja

En comparación con el método de presentación en dos etapas mencionado anteriormente, hay dos ventajas principales:

• TCC puede bloquear, comprometer y liberar por separado cada recurso en una transacción distribuida . Por ejemplo, suponga que hay dos operaciones AB, y si A toma poco tiempo, entonces A puede completar su propio intento de confirmación-cancelación más rápido Proceso, liberación de recursos No es necesario esperar a la operación B. Si se producen problemas después, se pueden realizar transacciones compensatorias adicionales.
• TCC está vinculado a cada subempresa (a excepción de la operación de reversión global en cancle), es decir, cada servicio puede ejecutarse "asíncronamente en paralelo" hasta cierto punto.

Asuntos que requieren atención

• El nodo del administrador de transacciones (coordinador) debe implementarse en un clúster de alta disponibilidad (HAC) con semántica de replicación síncrona.
• El administrador de transacciones (coordinador) también necesita usar un algoritmo mayoritario para evitar el problema del cerebro dividido del clúster.

Escena aplicable

• Consistencia estricta
• Corto tiempo de ejecución
• Altos requisitos en tiempo real

Ejemplos: sobres rojos, cobros y pagos comerciales

Cuarto, tipo de garantía asíncrona (transacción de mensaje + consistencia final)

Al cambiar una serie de operaciones de transacciones sincrónicas a operaciones asincrónicas basadas en mensajes , se evita el impacto de las operaciones de bloqueo sincrónico en las transacciones distribuidas.

Esta solución realmente se da cuenta del desacoplamiento de los dos servicios. La clave para el desacoplamiento es la mensajería asincrónica y las transacciones de compensación.

Aquí hay un ejemplo como explicación:

Los pasos son los siguientes:

1. El remitente MQ envía mensajes de transacciones remotas al servidor MQ;
2. El servidor MQ responde, indicando que el mensaje de transacción ha llegado con éxito al servidor MQ.
3. Remitente de MQ Confirmar transacción local.
4. Si la transacción local Commit tiene éxito, se notifica al servidor MQ para permitir que se consuma el mensaje de transacción correspondiente; si la transacción local falla, se notifica al servidor MQ que el mensaje de transacción correspondiente debe descartarse.
5. Si el remitente de MQ no proporciona comentarios al Servidor de MQ sobre el estado de ejecución de la transacción local, el Servidor de MQ debe verificar activamente el estado de la transacción al remitente de MQ para determinar si el mensaje de la transacción se puede consumir.
6. Cuando se sabe que la transacción local se ejecuta con éxito, MQ Server permite a los suscriptores de MQ consumir este mensaje de transacción.

Un punto adicional es que después de que el mensaje de la transacción se entregue al suscriptor de MQ, es posible que no se ejecute con éxito. El suscriptor de MQ debe brindar activamente comentarios de los consumidores (ack)

• Si el suscriptor de MQ ejecuta con éxito la transacción remota, se le da el reconocimiento exitoso al consumidor, entonces el servidor de MQ puede eliminar el mensaje de la transacción de manera segura;
• Si la ejecución falla, MQ Server debe volver a entregar el mensaje hasta que el consumo sea exitoso.

Asuntos que requieren atención

• El middleware de mensajes juega un papel importante en el sistema, y ​​todos los mensajes de transacción deben comunicarse a través de él, por lo que el middleware de mensajes también debe ser compatible con HAC para garantizar que los mensajes de transacción no se pierdan.
• Dependiendo de la implementación específica de la lógica de negocios, es posible que también deba agregar otros requisitos al middleware de mensajes, como la duplicación de mensajes, ningún desorden, etc.

Escena aplicable

• Largo ciclo de ejecución
• Los requisitos en tiempo real no son altos

Por ejemplo:

• Negocio de transferencias / remesas interbancarias (los dos servicios están en bancos diferentes)
• Negocio de devolución / reembolso
• Finanzas, negocio de estadísticas de facturación (primero enviado al mensaje middleware, luego contabilidad por lotes)

V. Tipo de notificación de mejor esfuerzo

Este es uno de los requisitos más bajos en las transacciones distribuidas, y también se puede implementar a través del middleware de mensajes. La diferencia con la operación de garantía asincrónica anterior es que después de que el servidor MQ entrega el mensaje al consumidor, después de que se permita el número máximo de reintentos Finalice la transacción normalmente .

Escena aplicable

Notificación de mensajes de resultados de transacciones, etc.

Resumen

Ya sea el administrador de transacciones (coordinador) en transacciones sincrónicas o el middleware de mensajes utilizado en transacciones asincrónicas, para lograr garantías de coherencia, debe utilizar las funciones altamente disponibles y altamente confiables proporcionadas por HAC con semántica de replicación sincrónica Todo esto es a costa del rendimiento y, sin duda, se convierte en uno de los cuellos de botella de rendimiento típicos en la arquitectura SOA.