Recientemente aprendí sobre las características de la consistencia de datos bajo microservicios, y resumí los diversos métodos de implementación actuales para garantizar la consistencia de datos bajo microservicios de la siguiente manera para referencia futura. Este artículo está destinado a darle una introducción general a la implementación de la consistencia de datos basada en microservicios. No se ha desarrollado en profundidad. El método de implementación específico también continúa aprendiendo. Si hay errores, puede hacer ladrillos.
Aplicación tradicional de gestión de transacciones
Antes de introducir la consistencia de datos en microservicios para transacciones locales , introduzca brevemente los antecedentes de la transacción. Las aplicaciones independientes tradicionales usan un RDBMS como fuente de datos. La aplicación inicia la transacción, realiza CRUD, confirma o revierte la transacción, todo ocurre en la transacción local y el administrador de recursos (RM) proporciona directamente el soporte de la transacción. La coherencia de los datos está garantizada en una transacción local.
Compromiso de
dos fases de transacciones distribuidas (2PC)
Cuando la aplicación se expande gradualmente, una aplicación utiliza múltiples fuentes de datos. En este momento, las transacciones locales ya no pueden cumplir con los requisitos de consistencia de datos. Debido al acceso simultáneo de múltiples fuentes de datos, las transacciones deben administrarse a través de múltiples fuentes de datos, y las transacciones distribuidas surgen en el momento histórico. El más popular de estos es el commit de dos fases (2PC), donde las transacciones distribuidas son administradas por el administrador de transacciones (TM).
La presentación en dos fases se divide en una fase de preparación y una fase de presentación.
Compromiso en dos fases
En dos fases -rollback
sin embargo no puede cometer problemas de coherencia de datos de garantía, y han síncronos problemas de bloqueo, por lo que su versión optimizada de cometer trifásico (3PC) fue inventado a cabo en dos fases.
Presentación trifásica (3PC)
Envío trifásico
Sin embargo, 3PC solo puede garantizar la consistencia de los datos en la mayoría de los casos.
Gestión de transacciones bajo microservicios.
Entonces, ¿la transacción distribuida 2PC o 3PC es adecuada para la gestión de transacciones bajo microservicios? La respuesta es no, por tres razones:
-
Debido a que no hay acceso directo a datos entre microservicios, los microservicios generalmente se llaman entre sí a través de RPC (Dubbo) o Http API (Spring Cloud), por lo que ya no es posible usar TM para administrar uniformemente el RM de microservicios.
-
Los tipos de fuentes de datos utilizados por diferentes microservicios pueden ser completamente diferentes. Si los microservicios usan una base de datos como NoSQL que no admite transacciones, no hay forma de hablar sobre transacciones.
-
Incluso si las fuentes de datos utilizadas por los microservicios son compatibles con todas las transacciones, si se utiliza una transacción grande para administrar las transacciones de muchos microservicios, el tiempo que se mantiene esta transacción grande será de varios órdenes de magnitud más que la transacción local. Tales transacciones a largo plazo y transacciones entre servicios generarán muchos bloqueos e indisponibilidad de datos, lo que afectará seriamente el rendimiento del sistema.
Se puede ver que la transacción distribuida tradicional ya no puede cumplir con los requisitos de administración de transacciones bajo la arquitectura de microservicios. Entonces, dado que es imposible satisfacer las transacciones ACID tradicionales, la gestión de transacciones bajo microservicios debe seguir una nueva teoría BASE de reglas.
La teoría BASE fue propuesta por el arquitecto de eBay Dan Pritchett. La teoría BASE es una extensión de la teoría CAP. La idea central es que incluso si no se puede lograr una fuerte consistencia, la aplicación debería ser capaz de lograr la consistencia final de una manera adecuada. BASE se refiere a Básicamente disponible, estado blando y consistencia eventual.
-
Disponibilidad básica: se refiere al hecho de que el sistema distribuido puede perder parte de su disponibilidad cuando ocurre una falla, lo que significa que el núcleo está disponible.
-
Estado suave: permite que el sistema tenga un estado intermedio, y el estado intermedio no afectará la disponibilidad general del sistema. Generalmente, hay al menos tres copias de un dato en el almacenamiento distribuido, y la demora en permitir la sincronización de copias entre diferentes nodos es la encarnación del estado blando.
-
Consistencia final: la consistencia final significa que todas las copias de datos en el sistema eventualmente alcanzarán un estado consistente después de un cierto período de tiempo. La consistencia débil es lo opuesto a la consistencia fuerte, y la consistencia final es un caso especial de consistencia débil.
La coherencia final en BASE es el requisito fundamental para la gestión de transacciones bajo microservicios.Ambas gestiones de transacciones basadas en microservicios no pueden lograr una gran coherencia, pero deben garantizar la mayor coherencia. Entonces, ¿qué métodos pueden garantizar la coherencia final de la gestión de transacciones bajo microservicios? Según el principio de implementación, hay dos tipos principales, tipo de notificación de evento y tipo de compensación, de los cuales el tipo de notificación de evento se puede dividir en modo de notificación de evento confiable y los mejores esfuerzos El modo de notificación y el tipo de compensación se pueden dividir en modo TCC y modo de compensación comercial. Estos cuatro modos pueden lograr la consistencia final de los datos bajo microservicios.
Formas de lograr consistencia de datos bajo microservicios
Modo de notificación de evento confiable El concepto de diseño del modo de notificación de
evento
confiable de evento síncrono es relativamente fácil de entender, es decir, el servicio maestro pasa los resultados al servicio esclavo a través del evento (a menudo una cola de mensajes), y el servicio esclavo consume después de recibir el mensaje y completa el negocio. , Para lograr consistencia de mensaje entre el servicio maestro y el servicio esclavo. Lo primero y más fácil en lo que se puede pensar es en la notificación de eventos de sincronización. El procesamiento comercial y el envío de mensajes se ejecutan sincrónicamente. Para la lógica de implementación, consulte el diagrama de códigos y tiempos a continuación.
-
public void trans() { -
try { -
// 1. 操作数据库 -
bool result = dao.update(data);// 操作数据库失败，会抛出异常 -
// 2. 如果数据库操作成功则发送消息 -
if(result){ -
mq.send(data);// 如果方法执行失败，会抛出异常 -
} -
} catch (Exception e) { -
roolback();// 如果发生异常，就回滚 -
} -
}
La lógica anterior parece perfecta: si la operación de la base de datos falla, saldrá sin enviar un mensaje; si el mensaje no se envía, la base de datos se revertirá; si la operación de la base de datos es exitosa y el mensaje se envía con éxito, el negocio será exitoso y el mensaje se enviará a los consumidores posteriores. Luego, después de una cuidadosa consideración, en realidad hay dos deficiencias en la notificación de mensajes síncronos.
Bajo la arquitectura de microservicios, puede haber problemas de E / S de red o problemas de tiempo de inactividad del servidor. Si estos problemas aparecen en el paso 7 del diagrama de tiempo, el servicio principal (problema de red) no puede ser notificado normalmente después de que se entrega el mensaje, o el envío no puede continuar. Transacción (tiempo de inactividad), el servicio maestro pensará que la entrega del mensaje falla y revertirá el negocio del servicio maestro, pero en realidad el mensaje ha sido consumido por el servicio esclavo, entonces hará que el servicio maestro y los datos del servicio esclavo sean inconsistentes. La escena específica se puede ver en los siguientes dos diagramas de tiempo.
El servicio de eventos (en este caso, el servicio de mensajes) está demasiado unido a la empresa. Si el servicio de mensajes no está disponible, la empresa no está disponible. El servicio de eventos debe desacoplarse de la empresa y ejecutarse de forma independiente y asíncrona, o intentar enviar un mensaje primero después de que se ejecute la empresa. Si el mensaje no se envía, se degradará a asíncrono.
Servicio de evento
local de evento asíncrono :
para resolver el problema del evento síncrono descrito en el evento síncrono anterior, se ha desarrollado el modelo de notificación de evento asíncrono. Tanto el servicio comercial como el servicio de evento están desacoplados, y el evento se realiza de forma asíncrona. Un servicio de evento separado asegura la confiabilidad del evento. Publicar
Servicio de eventos locales de notificación asíncrona de eventos
Cuando se ejecuta el negocio, el evento se escribe en la tabla de eventos local en la misma transacción local y el evento se entrega al mismo tiempo. Si el evento se entrega con éxito, el evento se elimina de la tabla de eventos. Si la entrega falla, el servicio de eventos se utiliza para procesar de manera periódica y uniforme los eventos de entrega fallidos, y la nueva entrega se realiza hasta que el evento se entregue correctamente y el evento se elimine de la tabla de eventos. Este método garantiza la efectividad de la entrega del evento en la mayor medida posible, y cuando falla la primera entrega, el servicio de eventos asíncronos también se puede utilizar para garantizar que el evento se entregue al menos una vez.
Sin embargo, este método de usar servicios de eventos locales para garantizar notificaciones de eventos confiables también tiene sus defectos, es decir, el negocio todavía está acoplado al servicio de eventos (cuando se realiza la primera entrega síncrona), y más seriamente, las transacciones locales requieren Responsable de la operación de tablas de eventos adicionales, lo que ejerce presión sobre la base de datos. En escenarios de alta concurrencia, debido a que cada operación comercial generará una operación de tabla de eventos correspondiente, el rendimiento disponible de la base de datos se reduce a la mitad, lo que sin duda es imposible. Aceptado Es por esta razón que el modelo confiable de notificación de eventos ha desarrollado aún más: los servicios de eventos externos aparecen a los ojos de las personas.
Servicio de eventos externos: el
servicio de eventos externos lleva el servicio de eventos local un paso más allá y separa el servicio de eventos del servicio comercial principal. El servicio comercial principal no tiene una fuerte dependencia del servicio de eventos.
Notificación asíncrona de eventos: el servicio
comercial del servicio de eventos externo envía eventos al servicio de eventos antes del envío. El servicio de eventos solo registra eventos y no los envía. El servicio comercial notifica al servicio de eventos después del envío o reversión, y el servicio de eventos envía eventos o elimina eventos. No se preocupe por el tiempo de inactividad del sistema empresarial después del envío o reinversión y no pueda enviar eventos de confirmación al servicio de eventos, porque el servicio de eventos obtendrá periódicamente todos los eventos no enviados y consultará al sistema empresarial para decidir si envía o elimina el evento en función de la devolución del sistema empresarial Eventos
Aunque los eventos externos pueden desacoplar el sistema empresarial y el sistema de eventos, también aportan una carga de trabajo adicional: el servicio de eventos externos tiene el doble de la sobrecarga de comunicación de la red (antes del envío, después del envío / reversión) en comparación con el servicio de eventos local. Al mismo tiempo, el sistema empresarial también debe proporcionar una interfaz de consulta separada para que el sistema de eventos determine el estado de los eventos no enviados.
Notas sobre el modo de notificación de eventos confiable:
Hay dos puntos a tener en cuenta en el modo de eventos confiables: 1. El envío correcto de eventos, 2. El consumo repetido de eventos.
El servicio de mensajes asíncronos puede garantizar el envío correcto de eventos. Sin embargo, es probable que los eventos se envíen repetidamente. Luego, el consumidor debe asegurarse de que el mismo evento no se consumirá repetidamente. En resumen, es para garantizar la idempotencia del consumo de eventos.
Si el evento en sí es un evento de estado idempotente, como la notificación del estado del pedido (pedido, pago, envío, etc.), debe determinar el orden del evento. Generalmente se juzga por la marca de tiempo. Después de consumir el nuevo mensaje, el mensaje antiguo se descarta y no se consume cuando se recibe el mensaje anterior. Si no puede proporcionar una marca de tiempo global, debería considerar usar un número de serie uniforme a nivel mundial.
Para los eventos que no tienen idempotencia, generalmente son eventos de comportamiento de acción, como la deducción 100, el depósito 200, debe persistir el ID del evento y el resultado del evento, consultar el ID del evento antes de consumir el evento y devolver directamente el resultado de la ejecución si se ha consumido ; Si es un mensaje nuevo, ejecútelo y almacene el resultado de la ejecución.
Modo de notificación de mejor esfuerzo
En comparación con el modo de notificación de eventos confiable, el modo de notificación de mejor esfuerzo es mucho más fácil de entender. La característica del tipo de notificación de mejor esfuerzo es que después de enviar la transacción, el servicio comercial envía un número limitado de mensajes (estableciendo el número máximo de mensajes), como el envío de tres mensajes. Por lo tanto, puede conducir a la pérdida de mensajes. Al mismo tiempo, la parte comercial principal necesita proporcionar una interfaz de consulta al servicio comercial esclavo para recuperar los mensajes perdidos. El tipo de notificación de mejor esfuerzo tiene poca garantía de puntualidad (es decir, puede producirse un estado blando durante mucho tiempo), por lo que no se puede utilizar el sistema con altos requisitos de puntualidad para la coherencia de los datos. Este modelo se usa generalmente en diferentes servicios de plataforma comercial o notificaciones para servicios comerciales de terceros, como notificaciones bancarias, notificaciones comerciales, etc., y no se ampliará aquí.
Modo de compensación comercial
A continuación, se introducen dos modos de compensación: la mayor diferencia entre el modo de compensación y el modo de notificación de eventos es que el servicio ascendente del modo de compensación depende del resultado operativo del servicio descendente, mientras que el servicio ascendente del modo de notificación de eventos no depende del resultado operativo del servicio descendente. . Primero, introduzca el modo de compensación comercial. El modo de compensación comercial es un modo de compensación pura. Su concepto de diseño es que el negocio se envía normalmente cuando se lo llama. Cuando un servicio falla, todos los servicios ascendentes de los que depende realizan operaciones de compensación comercial. Por ejemplo, Xiaoming comenzó desde Hangzhou y se fue de viaje de negocios a Nueva York, EE.UU .. Ahora necesita reservar un boleto de tren de Hangzhou a Shanghai y un boleto de avión de Shanghai a Nueva York. Si Xiaoming compró con éxito un boleto de tren y descubrió que el boleto de avión se había agotado, entonces en lugar de quedarse en Shanghai por otro día, Xiaoming podría cancelar el boleto de tren a Shanghai y elegir volar a Beijing y luego transferirlo a Nueva York, por lo que Xiaoming canceló Boleto de tren a Shanghai. En este ejemplo, comprar un boleto de tren de Hangzhou a Shanghai es el servicio a, y comprar un boleto de Shanghai a Nueva York es el servicio B. El modelo de compensación comercial es compensar el servicio a cuando falla el servicio b. En el ejemplo, es cancelar Hangzhou a Boleto de tren de Shanghai.
El modelo de compensación requiere que cada servicio proporcione una excusa para la compensación, y esta compensación es generalmente una compensación incompleta. Incluso si se realiza la operación de compensación, el registro de boleto de tren cancelado todavía está en la base de datos y puede ser rastreado (generalmente cree El campo de estado de "se cancela" como una marca), después de todo, los datos en línea que se han enviado generalmente no se pueden eliminar físicamente.
La mayor desventaja del modo de compensación comercial es que el estado blando lleva mucho tiempo, la puntualidad de la consistencia de los datos es muy baja y los servicios múltiples a menudo pueden estar en datos inconsistentes.
TCC / Try Confirm Cancel mode El modo
TCC es un modo de compensación comercial optimizado. Se puede compensar por completo. No deja un registro de compensación después de la compensación, como si nada hubiera pasado. Al mismo tiempo, el tiempo de estado suave de TCC es muy corto porque el TCC es un modelo de dos etapas. Solo cuando la primera etapa (prueba) de todos los servicios es exitosa, se realiza la operación de confirmación de la segunda etapa, de lo contrario Realice la operación de compensación (Cancelar), pero en la fase de prueba, no habrá procesamiento comercial real.
Modo TCC
El proceso específico del modo TCC consta de dos etapas:
-
Pruebe, el servicio comercial completa todos los controles comerciales y reserva los recursos comerciales necesarios
-
Si Try tiene éxito en todos los servicios, realice la operación Confirmar, la operación Confirmar no realiza ninguna verificación comercial (porque se realizó en la prueba), solo use los recursos comerciales reservados en la fase de Prueba para el procesamiento comercial; de lo contrario, Cancelar operación, Cancelar La operación libera los recursos comerciales reservados en la fase de prueba.
Puede ser vago decirlo. Permítanme dar un ejemplo específico: Xiaoming Online transfiere RMB 100 del Banco de Comerciantes de China al Banco de Guangfa. Esta operación puede verse como dos servicios: el servicio a transfiere 100 yuanes desde la cuenta del Banco de Comerciantes de China de Xiaoming, y el servicio b transfiere 100 yuanes desde la cuenta del Banco Guangfa de Xiaoming.
Servicio a (Xiaoming transfirió 100 yuanes del China Merchants Bank):
intente: actualizar cmb_account set balance = balance-100, freeze = freeze + 100 donde acc_id = 1 y balance> 100;
confirme: actualice cmb_account set freeze = freeze-100 donde acc_id = 1;
cancelar: actualizar cmb_account set balance = balance + 100, freeze = freeze-100 donde acc_id = 1;
servicio b (Xiaoming transfiere 100 yuan al Guangfa Bank):
intente: actualizar cgb_account set freeze = freeze + 100 donde acc_id = 1 ;
confirmar: actualizar cgb_account set balance = balance + 100, freeze = freeze-100 donde acc_id = 1;
cancelar: actualizar cgb_account set freeze = freeze-100 donde acc_id = 1;
descripción específica: en
la fase de prueba de a, el servicio ha hecho dos cosas Cosas: 1. Verificación comercial, aquí es para verificar si el dinero en la cuenta de Xiaoming es más de 100 yuanes, 2. Reserve recursos y transfiera 100 yuanes del saldo a los fondos congelados.
En la fase de confirmación de a, aquí no se realiza ninguna verificación comercial, porque la fase de prueba ya se realizó y porque la transferencia se realizó con éxito, se deducirán los fondos congelados.
En la fase de cancelación de a, se liberan los recursos reservados, ambos fondos congelados de 100 yuanes, y se restauran al saldo.
Se lleva a cabo la fase de prueba de b, se reservan recursos y se congelan 100 yuanes.
En la fase de confirmación de b, los recursos reservados en la fase de prueba se utilizan para transferir 100 yuanes de fondos congelados al saldo.
En la fase de cancelación de b, se liberan los recursos reservados en la fase de prueba y se restan 100 yuanes de los fondos congelados.
Como se puede ver en el simple ejemplo anterior, el modelo TCC es más complejo que el modelo de compensación comercial pura, por lo que cada servicio necesita implementar dos interfaces, Cofirm y Cancel, en la implementación. La siguiente tabla
resume
estos cuatro modos de uso común:
| Tipo | El nombre | Consistencia de datos en tiempo real | Costo de desarrollo | Si el servicio ascendente depende del resultado del servicio descendente |
|---|---|---|---|---|
| Notificación | Mejor esfuerzo | Bajo | Bajo | No dependiente |
| Notificación | Evento confiable | Alta | Alta | No dependiente |
| Tipo de compensación | Compensación empresarial | Bajo | Bajo | Depende de |
| Tipo de compensación | TCC | Alta | Alta | Depende de |
Enlace original: https://www.jianshu.com/p/b264a196b177