Análisis del código fuente de la transacción tcc
Las transacciones distribuidas significan que los participantes de la transacción, los servidores que soportan la transacción, los servidores de recursos y los administradores de transacciones están ubicados en diferentes nodos en diferentes sistemas distribuidos. Lo anterior es la explicación de la Enciclopedia Baidu. En pocas palabras, una operación grande consta de diferentes operaciones pequeñas, que se distribuyen en diferentes servidores y pertenecen a diferentes aplicaciones. Las transacciones distribuidas deben garantizar que todas estas pequeñas operaciones tengan éxito o fracasen. En esencia, las transacciones distribuidas tienen como objetivo garantizar la coherencia de los datos en diferentes bases de datos.
2. Razones de las transacciones distribuidas.
2.1, Puntos y tablas de la base de datos
Cuando una sola tabla de base de datos genera más de 65.438+0.000 W de datos al año, entonces se deben considerar las subbases de datos y subtablas. Los principios específicos de las subbases de datos y las subtablas no se explicarán aquí, pero se analizarán en detalle más adelante. En pocas palabras, la base de datos original se convierte en varias bases de datos. En este momento, si una operación accede a la biblioteca 01 y a la biblioteca 02 al mismo tiempo y se garantiza la coherencia de los datos, se utilizarán transacciones distribuidas.
2.2. Aplicación de SOA
La denominada SOA son los servicios empresariales. Por ejemplo, una sola máquina originalmente admitía todo el sitio web de comercio electrónico, pero ahora se desmanteló todo el sitio web y se separaron el centro de pedidos, el centro de usuarios y el centro de inventario. Para el centro de pedidos, existe una base de datos especial para almacenar información de pedidos, el centro de usuarios también tiene una base de datos especial para almacenar información de usuarios y el centro de inventario también tiene una base de datos especial para almacenar información de inventario. En este momento, si desea operar pedidos e inventario al mismo tiempo, estarán involucradas la base de datos de pedidos y la base de datos de inventario. Para garantizar la coherencia de los datos, debe utilizar transacciones distribuidas.
Aunque las dos situaciones anteriores tienen diferentes apariencias, la esencia es la misma, ¡ambas porque hay más bases de datos para operar!
3. Características ácidas de las transacciones.
3.1, Número atómico (a)
La llamada atomicidad significa que todas las operaciones en toda la transacción se completan o no, y no hay un estado intermedio. Cuando se produce un error durante la ejecución de una transacción, todas las operaciones se revierten como si nunca se hubiera ejecutado toda la transacción.
3.2.Consistencia (c)
La ejecución de las transacciones debe garantizar la coherencia del sistema. Tomemos como ejemplo el cambio de carrera. A tiene 500 yuanes y B tiene 300 yuanes. Si A transfiere con éxito 50 yuanes a B en una transacción, no importa cuántas transacciones simultáneas ocurran, pase lo que pase, siempre que la transacción se ejecute con éxito, entonces la última cuenta A debe ser de 450 yuanes y la última cuenta B debe ser de 450 yuanes. ser 350 yuanes.
3.3. Aislamiento (1)
El llamado aislamiento significa que las transacciones no se afectarán entre sí y el estado intermedio de una transacción no será percibido por otras transacciones.
3.4. Persistencia (D)
La llamada persistencia significa que cuando se completa una sola transacción, los cambios realizados en los datos por la transacción se guardan completamente en la base de datos. incluso si hay un corte de energía o un tiempo de inactividad del sistema. Lo mismo ocurre con las máquinas.
4. Escenarios de aplicación de transacciones distribuidas
4.1, pago
El escenario más clásico es el pago. Un pago único significa deducir dinero de la cuenta del comprador y agregar dinero a la cuenta del vendedor. Estas operaciones deben realizarse dentro de una transacción y todas tienen éxito o todas fallan. Porque la cuenta del comprador pertenece al centro del comprador y corresponde a la base de datos del comprador, mientras que la cuenta del vendedor pertenece al centro del vendedor y corresponde a la base de datos del vendedor. Por lo tanto, se deben introducir transacciones distribuidas para operaciones en diferentes bases de datos.
4.2. Pedidos online
Los compradores que realizan pedidos en plataformas de comercio electrónico a menudo implican dos acciones, una es deducir el inventario y la otra es actualizar el estado del pedido. El inventario y los pedidos generalmente pertenecen a bases de datos diferentes, por lo que se requieren transacciones distribuidas para garantizar la coherencia de los datos.
5. Soluciones comunes de transacciones distribuidas
5.1. Confirmación de dos fases basada en el protocolo XA
XA es un protocolo de transacciones distribuidas propuesto por Tuxedo. XA se divide aproximadamente en dos partes: el administrador de transacciones y el administrador de recursos local. Entre ellos, el administrador de recursos local a menudo es implementado por la base de datos, como Oracle, DB2, etc., todos implementan la interfaz XA, y el administrador de transacciones sirve como programador global y es responsable del envío y la reversión de los recursos locales. El principio de XA para implementar transacciones distribuidas es el siguiente:
En términos generales, el protocolo XA es relativamente simple. Una vez que una base de datos comercial implementa el protocolo XA, el costo de usar transacciones distribuidas será relativamente bajo.
Sin embargo, XA también tiene un defecto fatal, es decir, el rendimiento no es ideal, especialmente cuando se coloca un solo enlace en una transacción, la concurrencia suele ser muy alta y XA no puede cumplir con escenarios de alta concurrencia. Actualmente, XA tiene buen soporte en bases de datos comerciales, pero aún no en bases de datos mysql. La implementación XA de mysql no registra registros en la fase de preparación y los datos en las bases de datos primaria y secundaria son inconsistentes debido al cambio de las bases de datos primaria y secundaria. Muchos nosql tampoco son compatibles con XA, lo que hace que los escenarios de aplicación de XA sean muy limitados.
5.2. Transacción de mensajes + coherencia final
La llamada transacción de mensajes es un envío de dos etapas basado en middleware de mensajes. Es esencialmente un uso especial del middleware de mensajes. Coloca las transacciones locales y el envío de mensajes en transacciones distribuidas para garantizar que las operaciones locales y el envío de mensajes tengan éxito o ambos fallen. El RocketMQ de código abierto admite esta función. Los principios específicos son los siguientes:
1. El sistema envía un mensaje de preparación al middleware de mensajes.
2. El middleware de mensajes guarda el mensaje preparado y regresa exitosamente.
3.a Ejecutar los asuntos locales.
4.a Enviar un mensaje de envío al middleware de mensajes.
Después de los cuatro pasos anteriores, se completa una transacción de mensaje. Para los cuatro pasos anteriores, cada paso puede producir errores, que se analizan uno por uno a continuación:
Si hay un error en el paso 1, toda la transacción fallará y la operación local de A no se ejecutará. Si ocurre un error en el paso 2, toda la transacción fallará y la operación local de A no se ejecutará. Si hay un error en el paso 3, es necesario revertir el mensaje de preparación. ¿Cómo retroceder? La respuesta es que el sistema A implementa una interfaz de devolución de llamada para el middleware de mensajes. El middleware de mensajes continuará ejecutando la interfaz de devolución de llamada para verificar si la ejecución de la transacción A es exitosa. Si falla, revierte el mensaje preparado. El paso 4 está mal. En este momento, la transacción local de A es exitosa. ¿El middleware de mensajes volverá a A? La respuesta es no. De hecho, a través de la interfaz de devolución de llamada, el middleware del mensaje puede verificar que A se haya ejecutado correctamente. En este momento, en realidad no es necesario que A envíe el mensaje. El middleware del mensaje puede enviar el mensaje por sí mismo, completando así el envío en dos fases de toda la transacción del mensaje según el middleware del mensaje. A menudo se utiliza en escenarios de alta concurrencia para dividir una transacción distribuida en una transacción de mensaje (operación local del sistema A + envío de mensajes) + operación local del sistema B. Entre ellas, la operación del sistema B está basada en mensajes. Siempre que la transacción del mensaje sea exitosa, la operación A debe ser exitosa y el mensaje debe enviarse. En este momento, B recibirá el mensaje y realizará operaciones locales. Si la operación local falla, el mensaje se volverá a emitir hasta que la operación B tenga éxito, realizando así una transacción distribuida disfrazada entre A y B. El principio es el siguiente:
Aunque el esquema anterior puede completar las operaciones de A y B, A y B no son estrictamente consistentes, pero en última instancia son consistentes. Sacrificamos la coherencia y el rendimiento mejoró enormemente. Por supuesto, este método de juego también es arriesgado. Si B no tiene éxito, se romperá la coherencia. Jugar o no depende de cuánto riesgo pueda soportar la empresa.
5.3. Modo de programación TCC
El denominado modo de programación TCC también es una variante del envío en dos fases. TCC proporciona un marco de programación que divide toda la lógica empresarial en tres partes: probar, confirmar y cancelar. Tomando como ejemplo los pedidos en línea, el inventario se deducirá durante la fase de prueba y el estado del pedido se actualizará durante la fase de confirmación. Si la actualización del pedido falla, entrará en la etapa de cancelación y restaurará el inventario. En resumen, TCC implementa artificialmente el envío en dos etapas a través del código. El código escrito en diferentes escenarios comerciales es diferente y la complejidad también es diferente. Por tanto, este patrón no se puede reutilizar muy bien.
6. Resumen
Las transacciones distribuidas son esencialmente transacciones que controlan uniformemente múltiples bases de datos. Según la intensidad del control, se pueden dividir en sin control, control parcial y control completo. Sin control significa que no se introducen transacciones distribuidas. El control parcial se refiere a varias variantes del compromiso de dos fases, incluida la transacción de mensajes + consistencia eventual y los modos TCC mencionados anteriormente, y el control total se refiere a la implementación completa del compromiso de dos fases. La ventaja del control parcial es una buena concurrencia y rendimiento, pero la desventaja es que la coherencia de los datos se debilita, mientras que el control total sacrifica el rendimiento y garantiza la coherencia. El uso específico depende en última instancia del escenario empresarial. Como técnico no podemos olvidar que la tecnología es para los negocios, no para la tecnología. La capacidad de seleccionar tecnologías para diferentes negocios también es muy importante.