Teoría distribuida
Características ACID de las transacciones de la base de datos.
Las características de la transacción de la base de datos incluyen atomicidad (Atomicity), consistencia (Consistencia), aislamiento o independencia (Aislamiento) y durabilidad (Durabilily). Se toma como ejemplo el siguiente pedido: en el sistema de comercio electrónico único, se llama al servicio de pedidos y se completa toda la operación del servicio en la misma transacción. Después de que el pedido se realiza con éxito, la deducción de inventario y la generación de pedidos entrarán en vigencia al mismo tiempo, y los datos se escribirán en la base de datos de inventario y la base de datos de pedidos. El proceso es el siguiente:
En un sistema distribuido, si el servicio de pedido solo está microservicio, el servicio de pedido se dividirá en API de servicio de pedido de llamada y API de servicio básico. Después de que se dividen los microservicios, la API del servicio de pedidos corresponde a una base de datos de pedidos independiente, y la API del servicio de productos corresponde a una base de datos de productos independientes. Si solo sigue el proceso en el servicio único y simplemente reemplaza el método local original con la API de microservicio, el diagrama de flujo es el siguiente:
En el servicio de pedidos, use la solicitud RPC o HTTP para llamar a la API del servicio de mercancías y a la API del servicio de pedidos, de forma similar a como el cliente llama al servidor. En este momento, si se producen los siguientes dos problemas:
- La red es anormal , el cliente llama a la llamada de servicio del servidor con éxito, pero debido a la anormalidad de la red, el cliente muestra que la llamada falló.
- El servidor está inactivo , el cliente llama a la llamada de servicio del servidor con éxito, pero el servidor está inactivo, el cliente muestra que la llamada falló.
El diagrama de flujo es el siguiente:
Porque, por las dos razones anteriores, el estado de los datos del producto y los datos del pedido serán inconsistentes, como sigue:
- El servicio de pedidos se revierte porque la red es anormal o el servidor está inactivo. La reversión de datos de pedidos no genera datos en la base de datos de pedidos, y la llamada al servicio de bienes es exitosa, y la deducción de inventario en la base de datos de bienes es exitosa.
- La llamada de servicio de pedido fue exitosa, los datos de pedido generados se escribieron en la base de datos de pedidos y el servicio de mercancía no se pudo llamar debido a anomalías en la red o tiempo de inactividad del servidor, y el inventario en la base de datos de mercancías no cambió.
Presentación en dos etapas de la teoría CAP y la base de datos (2PC)
¿Cómo resolver el problema del estado de datos inconsistente después de dividir directamente en microservicios? En este momento, es necesario introducir transacciones distribuidas. En primer lugar, pensaré en implementar transacciones distribuidas a través de la confirmación de dos fases (2PC) de la base de datos, que pertenece al plan de implementación a nivel de base de datos. De acuerdo con la teoría CAP (para más detalles, consulte la comprensión profunda de la teoría CAP y los escenarios aplicables ), 2PC pertenece al modo CP .
Los estudiantes que entienden los asuntos distribuidos de la base de datos deben saber que el 2PC compatible con la base de datos también se llama Transacciones XA. Entre ellos, XA es un acuerdo de presentación en dos fases, el acuerdo se divide en las siguientes dos etapas:
- La primera etapa: el coordinador de transacciones requiere que cada base de datos involucrada en la transacción precomprometa (precomprometa) esta operación y refleje si se puede comprometer.
- La segunda etapa: el coordinador de transacciones requiere que cada base de datos envíe datos.
Entre ellos, si alguna base de datos veta este envío, todos los datos de operación de la base de datos se revertirán. Este método tendrá un serio impacto en el rendimiento y también tiene las siguientes desventajas:
- Problema de bloqueo sincrónico! Durante la ejecución, todos los nodos participantes están bloqueando transacciones. Cuando los participantes ocupan recursos públicos, el acceso a los recursos públicos por parte de otros nodos de terceros también se bloquea.
- Único punto de falla! Debido a la importancia del coordinador, una vez que el coordinador falle, los participantes continuarán bloqueando. Especialmente en la segunda etapa, cuando el coordinador falla, todos los participantes todavía están en el estado de bloquear los recursos de la transacción y no pueden continuar completando las operaciones de la transacción.
- ¡Los datos son inconsistentes! En el proceso de envío de dos fases, cuando el coordinador envió una solicitud de confirmación a los participantes, se produjo una anomalía en la red o tiempo de inactividad del servidor , lo que resultaría en el éxito del envío parcial de datos y el fracaso del envío parcial, lo que provocaría una inconsistencia de los datos.
Transacción en modo TCC
Debido al modo 2PC, la disponibilidad no es alta, y el rendimiento es muy pobre, y también pertenece a un largo proceso de transacción. El comienzo del modo TCC es un poco similar a 2PC. TCC es esencialmente una forma de compensación. Divide el proceso de transacción en dos etapas de Try, Confirm / Cancel, y los tres pasos de Try, Confirm y Cancel son los siguientes:
- La fase de prueba es principalmente para la detección y reserva de recursos del sistema empresarial.
- La fase de Confirmación es principalmente para confirmar y enviar el sistema empresarial, luego de que la fase de Prueba se ejecute con éxito, se ejecuta la fase de Confirmación.
-
La fase de cancelación es principalmente para errores de ejecución de negocio. Después de que falla la fase de prueba, se utiliza para cancelar el negocio ejecutado en la fase de prueba y liberar los recursos reservados.
Además, el modo TCC, en comparación con el modo 2PC, tiene una granularidad más pequeña de control de transacciones. En los tres pasos de Probar, Confirmar y Cancelar, cuando los servicios se llaman entre sí, las transacciones entre servicios se controlan individualmente. Tome tcc-transaction (el ejemplo de código específico puede referirse a la guía de uso de transacciones tcc 1.2.x ) como un ejemplo para introducir el modo TCC específicamente.
flujo de ejecución de transacciones tcc
En tcc-transacción, el concepto de transacción de transacción se define a nivel comercial, cuando se ejecutan las dos etapas de probar y confirmar / cancelar, diferentes API de servicio controlan sus propias transacciones. Y, en función del atributo de propagación REQUERIDO de la transacción de la base de datos (es decir, si existe una transacción activa, se ejecuta en una transacción anidada. Si no hay una transacción activa, se ejecuta de acuerdo con el atributo NESTED. Utiliza una transacción separada, esta transacción tiene Múltiples puntos de rescate que pueden revertirse), la misma transacción se usa cuando se ejecutan las dos fases. El diagrama de flujo de ejecución es el siguiente:
procesamiento idempotente de transacciones tcc
Durante la ejecución de la lógica en Probar y confirmar / cancelar, se pueden generar algunas excepciones comerciales integradas, como la excepción de tiempo de espera SocketTimeoutException, la excepción de bloqueo optimista OptimisticLockException y algunas otras excepciones comerciales personalizadas. En este momento, siempre que estas dos fases se vuelvan a intentar varias veces, puede ser exitoso. Por lo tanto, el código comercial en estas dos etapas debe satisfacer el procesamiento idempotente.
