Colección | Por primera vez, alguien dijo "transacciones distribuidas" tan simples y claras
No sé si alguna vez te has encontrado con una situación así. Fuiste a una pequeña tienda a comprar algo y pagaste por ello, pero debido a que el dueño de la tienda había manejado algunas otras cosas, se olvidó de que tú pagaste y te pidió que pagaras de nuevo.
Autor: caffe latte Fuente: coffee latte micro-channel public number | 2018-08-14 09:28
Favoritos
Compártelo
O cuando compro en línea, ya he descontado dinero, pero me dice que no hay transacción. Esta serie de situaciones son causadas por ninguna transacción. Esto ilustra algo de la importancia de los asuntos de la vida.
Una vez que tienes un negocio, vas a una pequeña tienda a comprar algo, y eso significa pagarlo y entregarlo. Con la transacción, compras en línea y la deducción generará una transacción de pedido.
La definición específica de la transacción.
La transacción proporciona un mecanismo para incorporar todas las operaciones involucradas en una actividad en una unidad de ejecución indivisible. Todas las operaciones que componen una transacción solo se pueden enviar cuando todas las operaciones se pueden ejecutar normalmente. Siempre que una operación falle, Provoca la reversión de toda la transacción.
En pocas palabras, las transacciones proporcionan un mecanismo de "no hacer nada o hacer todo (todo o nada)".
Transacción local de base de datos
ÁCIDO
Cuando se trata de transacciones de bases de datos, tengo que decir, las cuatro características principales de las transacciones de bases de datos ACID:
R: Atomicidad, todas las operaciones en una transacción se completan o no se completan en absoluto, y no terminarán en un enlace intermedio.
Si ocurre un error durante la ejecución de la transacción, se revertirá (Rollback) al estado anterior al inicio de la transacción, como si la transacción nunca se hubiera ejecutado.
Al igual que cuando compra algo, debe pagar y recibir los productos juntos, o reembolsará el dinero si no se envía.
C: Consistencia: la consistencia de una transacción significa que la base de datos debe estar en un estado consistente antes y después de la ejecución de una transacción.
Si la transacción se completa con éxito, todos los cambios en el sistema se aplicarán correctamente y el sistema estará en un estado válido.
Si hay un error en la transacción, todos los cambios en el sistema se revertirán automáticamente y el sistema regresa al estado original.
I: Aislamiento (Aislamiento) significa que en un entorno concurrente, cuando diferentes transacciones manipulan los mismos datos al mismo tiempo, cada transacción tiene su propio espacio de datos completo.
Las modificaciones realizadas por empresas concurrentes deben aislarse de las modificaciones realizadas por otras empresas concurrentes. Cuando la transacción ve la actualización de datos, el estado de los datos es el estado antes de que otra transacción los modifique, o el estado después de que otra transacción los modifique. La transacción no verá los datos en el estado intermedio.
Por ejemplo, el asunto de comprar cosas no afecta a otras personas.
D: Durabilidad, lo que significa que siempre que la transacción finalice correctamente, las actualizaciones que realiza en la base de datos deben guardarse.
Incluso si ocurre un bloqueo del sistema, después de reiniciar el sistema de la base de datos, la base de datos se puede restaurar al estado en el que la transacción finalizó correctamente.
Por ejemplo, cuando compra algo, debe registrarlo en el libro mayor, incluso si el jefe lo olvida, está bien documentado.
Principio de implementación de InnoDB
InnoDB es un motor de almacenamiento de MySQL. La mayoría de la gente está familiarizada con MySQL. Aquí hay una breve introducción a algunos principios básicos de la implementación de transacciones de bases de datos.
En los asuntos locales, los servicios y recursos pueden considerarse como uno en el paquete de asuntos, como se muestra a continuación:
Nuestros asuntos locales son administrados por el administrador de recursos:
El ACID de la transacción está garantizado por registros y bloqueos de InnoDB. El aislamiento de transacciones se logra a través del mecanismo de bloqueo de la base de datos, la durabilidad se logra a través de Redo Log (rehacer log) y la atomicidad y consistencia se logran a través de Undo Log.
El principio de Undo Log es muy simple: para cumplir con la atomicidad de las transacciones, antes de operar cualquier dato, primero haga una copia de seguridad de los datos en un lugar (este lugar donde se almacena la copia de seguridad de los datos se llama Undo Log). Luego modifique los datos.
Si se produce un error o el usuario ejecuta una declaración de reversión, el sistema puede utilizar la copia de seguridad en el registro de deshacer para restaurar los datos al estado anterior al inicio de la transacción.
A diferencia de Undo Log, Redo Log registra una copia de seguridad de los datos nuevos. Antes de que se confirme la transacción, solo es necesario conservar el registro de rehacer y no es necesario conservar los datos.
Cuando el sistema falla, aunque los datos no se conservan, el registro de rehacer se ha conservado. El sistema puede restaurar todos los datos al estado *** de acuerdo con el contenido de Redo Log. Los estudiantes que estén interesados en el proceso de implementación específico pueden buscar extensiones por sí mismos.
Transacción distribuida
Que es transacción distribuida
Transacción distribuida significa que los participantes de la transacción, el servidor que soporta la transacción, el servidor de recursos y el administrador de transacciones están ubicados en diferentes nodos de diferentes sistemas distribuidos.
En pocas palabras, una gran operación consta de diferentes pequeñas operaciones. Estas pequeñas operaciones se distribuyen en diferentes servidores y pertenecen a diferentes aplicaciones. Las transacciones distribuidas deben garantizar que estas pequeñas operaciones tengan éxito o fracasen.
Básicamente, las transacciones distribuidas deben garantizar la coherencia de los datos en diferentes bases de datos.
Razones para transacciones distribuidas
De los asuntos locales anteriores, podemos dividirnos en dos partes:
- El servicio genera múltiples nodos
- El recurso genera múltiples nodos
Dar servicio a múltiples nodos
Con el rápido desarrollo de Internet, los modelos de arquitectura de servicios como los microservicios y SOA se están utilizando a gran escala.
Por ejemplo, dentro de una empresa, los activos del usuario pueden dividirse en varias partes, como saldo, puntos, cupones, etc.
En la empresa, es posible que la función de puntos sea mantenida por un equipo de microservicio y los cupones por otro equipo.
En este caso, no hay garantía de que el cupón se pueda deducir correctamente después de deducir los puntos.
Recurso de múltiples nodos
Del mismo modo, Internet se está desarrollando demasiado rápido, por lo general, los datos instalados en MySQL deben dividirse en bases de datos y tablas.
Para un negocio de transferencias de Alipay, si transfieres dinero a un amigo, es posible que tu base de datos esté en Beijing y el dinero de tu amigo esté en Shanghai, por lo que aún no podemos garantizar que puedan tener éxito al mismo tiempo.
La base de las transacciones distribuidas
Desde el punto de vista anterior, las transacciones distribuidas han surgido con el rápido desarrollo de Internet, lo cual es inevitable.
Dijimos antes que las cuatro características ACID de la base de datos ya no pueden satisfacer nuestras transacciones distribuidas En este momento, algunos nuevos peces gordos proponen algunas nuevas teorías.
GORRA
El teorema CAP también se denomina teorema de Brewer. Para los arquitectos que diseñan sistemas distribuidos (no solo transacciones distribuidas), CAP es su teoría introductoria.
C (coherencia): para un cliente específico, una operación de lectura puede devolver una *** operación de escritura.
Para los datos distribuidos en diferentes nodos, si los datos se actualizan en un nodo, si los datos de este *** se pueden leer en otros nodos, se llama consistencia fuerte. Si hay un nodo Si no se lee, es una inconsistencia distribuida.
A (Disponibilidad): los nodos no defectuosos devuelven una respuesta razonable en un tiempo razonable (no una respuesta de error y tiempo de espera). Las dos claves para la usabilidad son un tiempo razonable y una respuesta razonable.
Un tiempo razonable significa que la solicitud no puede bloquearse y debe devolverse en un tiempo razonable. Una respuesta razonable significa que el sistema debe devolver claramente el resultado y el resultado es correcto. La corrección aquí significa que, por ejemplo, debe devolver 50 en lugar de 40.
P (tolerancia a fallos de partición): cuando se produce una partición de red, el sistema puede seguir funcionando. Por ejemplo, aquí hay varias máquinas en el clúster y una máquina tiene un problema de red, pero el clúster aún puede funcionar normalmente.
Cualquiera que esté familiarizado con CAP sabe que los tres no se pueden compartir. Si está interesado, puede buscar la prueba de CAP. En un sistema distribuido, la red no puede ser 100% confiable. El particionamiento es en realidad un fenómeno inevitable.
Si elegimos CA y renunciamos a P, entonces para garantizar la coherencia cuando se produce una partición, la solicitud debe rechazarse en este momento, pero A no lo permite, por lo que es teóricamente imposible elegir una arquitectura de CA para un sistema distribuido y solo puede elegir CP O arquitectura AP.
Para CP, renunciando a la disponibilidad y buscando consistencia y tolerancia a fallas de partición, nuestro ZooKeeper es en realidad la búsqueda de una consistencia sólida.
Para AP, renunciar a la consistencia (la consistencia mencionada aquí es una fuerte consistencia) y buscar la tolerancia a fallas de partición y la disponibilidad es la elección de diseño de muchos sistemas distribuidos La siguiente BASE también se extiende según AP.
Por cierto, la teoría CAP ignora el retraso de la red, es decir, cuando se envía la transacción, no hay retraso en la replicación del nodo A al nodo B, pero en realidad esto es obviamente imposible, por lo que siempre habrá una cierta cantidad de inconsistencia de tiempo.
Al mismo tiempo, elegir dos en CAP, por ejemplo, si elige CP, no le dice que renuncie a A. Debido a que la probabilidad de que aparezca P es demasiado pequeña, aún debe garantizar CA la mayor parte del tiempo.
Incluso si aparece la partición, debe prepararse para la siguiente A, por ejemplo, a través de algunos medios de registro, se restauran otras máquinas para su uso.
BASE
BASE es una abreviatura de las tres frases Básicamente disponible, Estado suave y Eventualmente consistente, y es una extensión de AP en CAP.
Básicamente disponible: cuando un sistema distribuido falla, se permite perder parte de las funciones disponibles para garantizar que las funciones principales estén disponibles.
Estado suave: permite un estado intermedio en el sistema, este estado no afecta la disponibilidad del sistema, se refiere a la inconsistencia en el CAP.
Consistencia final: la consistencia final significa que después de un período de tiempo, todos los datos de los nodos alcanzarán la consistencia.
BASE resuelve la teoría de que no hay retardo de red en CAP y utiliza el estado suave y la consistencia final en BASE para garantizar la consistencia tras el retardo.
BASE es lo opuesto a ACID. Es completamente diferente del modelo de consistencia fuerte de ACID. En cambio, gana disponibilidad sacrificando consistencia fuerte y permite que los datos sean inconsistentes durante un período de tiempo, pero eventualmente alcanzan un estado consistente.
Solución de transacciones distribuidas
Con la base teórica anterior, aquí está la introducción de varias soluciones de transacciones distribuidas comunes.
¿Realmente quieres transacciones distribuidas?
Antes de hablar sobre el plan, primero debe dejar en claro si realmente necesita transacciones distribuidas.
Mencioné dos razones para las transacciones distribuidas, una de las cuales se debe a demasiados microservicios. He visto demasiados equipos que mantienen algunos microservicios por una persona, y demasiados equipos sobre-diseñan y cansan a todos.
Demasiados microservicios darán lugar a transacciones distribuidas. En este momento, no le recomendaré que adopte ninguno de los siguientes esquemas. En su lugar, agregue los microservicios que requieren transacciones en un solo servidor y use las transacciones locales de la base de datos.
Porque no importa qué tipo de esquema aumentará la complejidad de su sistema, el costo es demasiado alto. No introduzca costos y complejidad innecesarios solo por la búsqueda de ciertos diseños.
Si está seguro de que necesita introducir transacciones distribuidas, puede mirar los siguientes escenarios comunes.
2 piezas
Hablando de 2PC, tengo que hablar de transacciones XA en transacciones distribuidas de bases de datos.
Hay dos etapas en el protocolo XA:
- El administrador de transacciones requiere que cada base de datos involucrada en la transacción confirme previamente esta operación y refleje si puede confirmarse.
- El coordinador de transacciones requiere que cada base de datos confirme datos o revierta datos.
ventaja:
- Trate de asegurar la fuerte consistencia de los datos, y el costo de implementación es bajo. Tiene su propia implementación en las principales bases de datos. MySQL es compatible desde 5.5.
Desventajas:
- Problema de un solo punto: El papel del administrador de transacciones en todo el proceso es muy crítico. Si se cae, por ejemplo, la fase *** se ha completado y el administrador de transacciones baja cuando la segunda fase está a punto de confirmarse. Se bloqueará para siempre, lo que provocará que la base de datos quede inutilizable.
- Bloqueo sincrónico: después de estar listo, el recurso en el administrador de recursos se ha bloqueado hasta que se completa el envío y se libera el recurso.
- Inconsistencia de datos: aunque el protocolo de confirmación de dos fases está diseñado para una fuerte coherencia de los datos distribuidos, todavía existe la posibilidad de que exista una incoherencia de datos.
Por ejemplo, en la segunda etapa, suponga que el coordinador emitió una notificación de transacción Commit, pero debido a problemas de red, la notificación solo fue recibida por algunos participantes y se realizó la operación Commit, y el resto de participantes fueron bloqueados porque no recibieron la notificación. Estado, en este momento ha ocurrido una inconsistencia de datos.
En general, el protocolo XA es relativamente simple y de bajo costo, pero su problema de punto único y su incapacidad para soportar alta concurrencia (debido al bloqueo de sincronización) siguen siendo sus debilidades.
TCC
El concepto de TCC (Try-Confirm-Cancel) fue propuesto por primera vez por Pat Helland en un artículo titulado "La vida más allá de las transacciones distribuidas: la opinión de un apóstata" publicado en 2007.
En comparación con el XA descrito anteriormente, el mecanismo de transacción de TCC resuelve las siguientes deficiencias:
- Se resuelve el punto único del coordinador, y esta actividad empresarial es iniciada y completada por la parte empresarial principal. El gerente de actividad empresarial también se ha vuelto multipunto, introduciendo clústeres.
- Bloqueo síncrono: introduzca el tiempo de espera, compense después del tiempo de espera y no bloqueará todo el recurso, no transformará el recurso en una forma lógica empresarial y reducirá la granularidad.
- Consistencia de los datos, después de tener un mecanismo de compensación, el gerente de actividad empresarial controla la consistencia.
Explicación de TCC:
- Fase de prueba: intente ejecutar, complete todas las comprobaciones comerciales (coherencia) y reserve los recursos comerciales necesarios (cuasi aislamiento).
- Fase Confirmar: Confirmar la ejecución real del negocio, sin ninguna inspección comercial, utilizar solo los recursos comerciales reservados en la fase Probar, y la operación Confirmar satisface la idempotencia. Se requiere un diseño idempotente y se requiere un reintento después de que Confirmar falla.
- Fase de cancelación: cancela la ejecución, libera los recursos comerciales reservados en la fase de prueba y la operación de cancelación satisface la idempotencia. El esquema de manejo de excepciones de la fase Cancelar es básicamente el mismo que el de la fase Confirmar.
Para dar un ejemplo simple: si compras una botella de agua por 100 yuanes, la etapa de prueba: debes verificar con tu billetera si es suficiente para 100 yuanes y bloquear los 100. El agua es la misma.
Si uno falla, cancele (libere los 100 yuanes y la botella de agua) Si Cancelar falla, vuelva a intentar Cancelar sin importar la falla, por lo que debe permanecer idempotente.
Si todo tiene éxito, proceda a Confirmar para confirmar que se han deducido los 100 yuanes y que se ha vendido la botella de agua. Si la Confirmación falla, no importa lo que falle, volverá a intentarlo (se basará en el registro de actividad para volver a intentarlo).
Algunos adecuados para TCC:
- Fuerte aislamiento, estrictos requisitos de coherencia para negocios activos.
- Empresas con menor tiempo de ejecución.
Referencia de implementación: https://github.com/liuyangming/ByteTCC/.
Tabla de mensajes locales
La propuesta de tabla de mensajes local fue propuesta originalmente por eBay, la propuesta completa de eBay https://queue.acm.org/detail.cfm?id=1394128.
El núcleo de esta solución es ejecutar de forma asincrónica tareas que requieren procesamiento distribuido a través de registros de mensajes. El registro de mensajes se puede almacenar en un texto local, una base de datos o una cola de mensajes, y luego se puede iniciar el reintento de forma automática o manual a través de reglas comerciales.
Los reintentos manuales se usan más comúnmente en escenarios de pago y el sistema de conciliación se usa para lidiar con problemas posteriores al evento.
El núcleo de la cola de mensajes local es transformar grandes transacciones en pequeñas transacciones. Tomemos el ejemplo de comprar una botella de agua con 100 yuanes.
1. Cuando deduce dinero, debe agregar una nueva tabla de mensajes local en el servidor donde deduce dinero, debe escribir su dinero deducido y el inventario de agua deducida en la tabla de mensajes local y ponerlo en la misma transacción ( Confíe en las transacciones locales de la base de datos para garantizar la coherencia).
2. En este momento, hay una tarea cronometrada para sondear la tabla de transacciones local, lanzar el mensaje no enviado al servidor de inventario de productos básicos y pedirle que reste el inventario de agua. Después de llegar al servidor de productos básicos, primero debe escribirse en el servidor. A continuación, se deduce la tabla de transacciones. Una vez que la deducción se realiza correctamente, se actualiza el estado de la tabla de transacciones.
3. El servidor de productos básicos escanea la tabla de mensajes a través de tareas cronometradas o informa directamente al servidor de deducción, y el servidor de deducción actualiza el estado en la tabla de mensajes local.
4. Para algunas situaciones anormales, escanee periódicamente los mensajes procesados sin éxito y vuelva a enviarlos. Una vez que el servidor de productos básicos recibe el mensaje, primero juzga si es un duplicado.
Si se ha recibido, juzgue si ejecutarlo. Si se ejecuta de inmediato, se notificará la transacción; si no se ha ejecutado, la empresa debe volver a ejecutarla para garantizar la idempotencia, es decir, no habrá botella de agua adicional.
La cola de mensajes local es la teoría BASE y es el modelo consistente final, adecuado para situaciones donde la consistencia no es alta. Hay que prestar atención a la idempotencia de los reintentos al implementar este modelo.
Transacción MQ
Las transacciones distribuidas se implementan en RocketMQ, que en realidad es una encapsulación de la tabla de mensajes local, y la tabla de mensajes local se mueve dentro de MQ.
Aquí hay una breve introducción a las transacciones MQ. Si desea obtener más información al respecto, puede consultar: https://www.jianshu.com/p/453c6e7ff81c.
El proceso básico es el siguiente:
- *** Mensaje preparado, obtendrá la dirección del mensaje.
- La segunda fase ejecuta los asuntos locales.
- La tercera etapa utiliza la dirección obtenida en la etapa *** para acceder al mensaje y modificar el estado. El destinatario del mensaje puede utilizar el mensaje.
Si el mensaje de confirmación falla, RocketMQ Broker proporciona un mensaje de que el estado del escaneo regular no se ha actualizado.
Si un mensaje no es confirmado, enviará un mensaje al remitente del mensaje para determinar si debe enviarlo. En RocketMQ, se envía al remitente en forma de Listener para su procesamiento.
Si el consumo se agota, debe volver a intentarlo todo el tiempo y el receptor del mensaje debe ser idempotente. Si el consumo del mensaje falla, debe procesarse manualmente en este momento, porque la probabilidad es baja, si diseña este complicado proceso para un tiempo de probabilidad tan pequeño, la ganancia no vale la pena.
Asuntos de la saga
Saga es un concepto mencionado en una base de datos ética hace 30 años. La idea central es dividir una transacción larga en varias transacciones cortas locales, que son coordinadas por el coordinador de transacciones de Saga. Si finaliza normalmente, se completará normalmente. Si un paso falla, la operación de compensación se llamará una vez en el orden inverso.
Composición de la Saga: Cada Saga se compone de una serie de subtransacciones Ti, y cada Ti tiene una acción de compensación correspondiente Ci. La acción de compensación se usa para deshacer el resultado causado por Ti. Cada T aquí es una transacción local.
Como puede ver, en comparación con TCC, Saga no tiene una acción de "prueba reservada" y su Ti se envía directamente a la biblioteca.
Hay dos secuencias de ejecución de Saga:
- T1, T2, T3, ..., Tn。
- T1, T2, ..., Tj, Cj, ..., C2, C1, donde 0 <j <n.
Saga define dos estrategias de recuperación:
- Recuperación hacia atrás, es decir, la segunda orden de ejecución mencionada anteriormente, donde j es la subtransacción en la que ocurrió el error. El efecto de este enfoque es cancelar todas las subtransaciones anteriores exitosas, de modo que se cancela el resultado de ejecución de toda la Saga.
- Recuperación hacia adelante, adecuada para escenarios que deben tener éxito, la secuencia de ejecución es similar a esta: T1, T2, ..., Tj (falla), Tj (reintento), ..., Tn, donde j es un error Subtransacción. En este caso no se necesita Ci.
Cabe señalar aquí que el aislamiento no se puede garantizar en el modo Saga, porque no hay recursos bloqueados, otras transacciones aún pueden cubrir o afectar la transacción actual.
Tomemos el ejemplo de comprar una botella de agua por 100 yuanes. Aquí está la definición:
- T1 = deducción de 100 yuanes, T2 = agregar una botella de agua al usuario, T3 = reducir el inventario de una botella de agua.
- C1 = agregar 100 yuanes, C2 = restar una botella de agua para el usuario, C3 = agregar una botella de agua al inventario.
Realizamos T1, T2 y T3 a la vez. Si ocurre un problema, realice la operación inversa de C donde ocurrió el problema.
El problema de aislamiento mencionado anteriormente ocurrirá si necesita realizar una reversión en este momento cuando la ejecución alcanza T3, pero el usuario ya ha bebido el agua (otra transacción), encontrará que no puede reducir al usuario en uno durante la reversión. Botella de agua.
Este es el problema de no aislamiento entre transacciones. Se puede ver que el impacto del modo Saga sin aislamiento sigue siendo grande. Puede consultar la solución de Huawei: comenzando desde el nivel empresarial, agregue un mecanismo de sesión y bloqueo para garantizar la serialización de los recursos operativos.
También es posible aislar esta parte de los recursos a nivel empresarial congelando los fondos por adelantado. *** puede obtener actualizaciones de *** leyendo el estado actual a tiempo durante las operaciones comerciales. (Ejemplo específico: puede consultar el peine de servicio de Huawei)
***
Nuevamente, si no necesita transacciones distribuidas, no es necesario. Si tiene que usarlo, combine su propio análisis comercial para ver cuál es más adecuado para su negocio, ya sea que le interese una coherencia sólida o una coherencia final.
*** Después de resumir algunas preguntas, puede bajar para encontrar las respuestas del artículo:
- ¿Es la CA de ACID y CAP la misma?
- ¿Cuáles son las ventajas y desventajas de las soluciones comunes para transacciones distribuidas? ¿Para qué escenario es adecuado?
- ¿Por qué aparece la transacción distribuida? ¿Qué puntos débiles se utilizan para resolver?