私聊互关，也可在评论区评论一下deshacer registro y rehacer registro
En el sistema de base de datos, hay archivos para almacenar datos y archivos para almacenar registros. El registro también tiene un búfer de registro en caché en la memoria y un archivo de registro de archivo de disco. Hay dos tipos de archivos de registro en MySQL que están relacionados con las transacciones: registros de deshacer y registros de rehacer.
deshacer registro
Las transacciones de la base de datos son atómicas y , si la transacción falla, los datos deben revertirse.
La atomicidad se puede lograr utilizando el registro de deshacer. El principio de Undo Log es muy simple: para satisfacer la atomicidad de las transacciones, antes de operar cualquier dato, primero haga una copia de seguridad de los datos en Undo Log. Luego modifique los datos. Si hay un error o el usuario ejecuta la declaración ROLLBACK, el sistema puede usar la copia de seguridad en el registro de deshacer para restaurar los datos al estado anterior al inicio de la transacción. Antes de que la base de datos escriba datos en el disco, primero almacena en caché los datos en la memoria y luego los escribe en el disco cuando se confirma la transacción. Proceso simplificado para lograr transacciones atómicas y duraderas con Undo Log:
假设有A、B两个数据，值分别为1,2。 A. 事务开始. B. 记录A=1到undo log. C. 修改A=3. D. 记录B=2到undo log. E. 修改B=4. F. 将undo log写到磁盘。 G. 将数据写到磁盘。 H. 事务提交
如何保证持久性？
事务提交前，会把修改数据到磁盘前，也就是说只要事务提交了，数据肯定持久化
如何保证原子性？
每次对数据库修改，都会把修改前数据记录在undo log，那么需要回滚时，可以读取undo log，恢复数据。
若系统在G和H之间崩溃
此时事务并未提交，需要回滚。而undo log已经被持久化，可以根据undo log来恢复数据
若系统在G之前崩溃
此时数据并未持久化到硬盘，依然保持在事务之前的状态Defecto: escribir datos y deshacer registro en el disco antes de confirmar cada transacción, lo que provocará una gran cantidad de E/S en el disco, por lo que el rendimiento es muy bajo.
Si puede almacenar datos en caché durante un período de tiempo, puede reducir IO y mejorar el rendimiento. Pero esto hará perder la durabilidad de la transacción. Por lo tanto, se introduce otro mecanismo para lograr la persistencia, a saber, Redo Log .
A diferencia del registro de deshacer, el registro de rehacer registra una copia de seguridad de los datos nuevos . Antes de que se confirme la transacción, siempre que se conserve el registro de rehacer, no es necesario conservar los datos, lo que reduce la cantidad de E/S.
假设有A、B两个数据，值分别为1,2
A. 事务开始. B. 记录A=1到undo log buffer. C. 修改A=3. D. 记录A=3到redo log buffer. E. 记录B=2到undo log buffer. F. 修改B=4. G. 记录B=4到redo log buffer. H. 将undo log写入磁盘 I. 将redo log写入磁盘 J. 事务提交
- 如何保证原子性？
如果在事务提交前故障，通过undo log日志恢复数据。如果undo log都还没写入，那么数据就尚未持久化，无需回滚
- 如何保证持久化？
大家会发现，这里并没有出现数据的持久化。因为数据已经写入redo log，而redo log持久化到了硬盘，因此只要到了步骤`I`以后，事务是可以提交的。
- 内存中的数据库数据何时持久化到磁盘？
因为redo log已经持久化，因此数据库数据写入磁盘与否影响不大，不过为了避免出现脏数据（内存中与磁盘不一致），事务提交后也会将内存数据刷入磁盘（也可以按照固设定的频率刷新内存数据到磁盘中）。
- redo log何时写入磁盘
redo log会在事务提交之前，或者redo log buffer满了的时候写入磁盘
为什么要使用redo log
- 数据库数据写入是随机IO，性能很差
- redo log在初始化时会开辟一段连续的空间，写入是顺序IO，性能很好
- 实际上undo log并不是直接写入磁盘，而是先写入到redo log buffer中，当redo log持久化时，undo log就同时持久化到硬盘了，因此事务提交前，只需要对redo log持久化即可
-redo log中记录的数据，有可能包含尚未提交事务，如果此时数据库崩溃，那么如何完成数据恢复？
数据恢复有两种策略：
恢复时，只重做已经提交了的事务
恢复时，重做所有事务包括未提交的事务和回滚了的事务。然后通过Undo Log回滚那些未提交的事务
Inodb引擎采用的是第二种方案，因此undo log要在 redo log前持久化transacción distribuida
Una vez que la base de datos se divide horizontalmente y el servicio se divide verticalmente, una operación comercial generalmente abarca múltiples bases de datos y servicios para completarse. En un entorno de red distribuida, no podemos garantizar que todos los servicios y bases de datos estén 100% disponibles.Algunos servicios y bases de datos se ejecutarán con éxito, mientras que otros fallarán. Cuando algunas operaciones comerciales tienen éxito y otras fallan, los datos comerciales serán inconsistentes.
Por ejemplo, la tabla de pagos y la tabla de inventario están en bases de datos diferentes, y el usuario no puede deducir el monto al comprar, y la tabla de pagos se revierte, pero debido a que la tabla de inventario no está en la misma base de datos que la tabla de productos, no se producirá la reversión.
Ideas para resolver transacciones distribuidas
El teorema CAP y la teoría BASE pueden referirse a artículos anteriores
Solución 1: enviar por etapas
En 1994, la organización X/Open (ahora Open Group) definió el modelo DTP para el procesamiento de transacciones distribuidas. El modelo incluye los siguientes roles:
Aplicación (AP): Nuestro Microservicio
Administrador de transacciones ( TM ): Administrador de transacciones globales
Resource Manager (RM): normalmente una base de datos
Communication Resource Manager (CRM): es el middleware de comunicación entre TM y RM
En este modelo, una transacción distribuida (transacción global) se puede dividir en muchas transacciones locales, ejecutándose en diferentes AP y RM. ACID para cada transacción local está bien implementado, pero la transacción global debe garantizar que todas las transacciones locales contenidas en ella puedan tener éxito al mismo tiempo, y si una transacción local falla, todas las demás transacciones deben revertirse. Pero el problema es que en el proceso de procesamiento de transacciones locales, no se conoce el estado de ejecución de otras transacciones. Por lo tanto, es necesario notificar cada transacción local a través del CRM para sincronizar el estado de ejecución de la transacción.
compromiso de dos fases
Etapa 1: etapa de preparación, cada transacción local completa la preparación de la transacción local
Etapa 2: etapa de ejecución, cada transacción local se compromete o revierte según el resultado de ejecución de la etapa anterior
Este proceso requiere un coordinador (coordinador), así como participantes de la transacción (votante)
Fase de votación : el grupo de coordinación pregunta a cada participante de la transacción si la transacción se puede ejecutar. Cada participante de la transacción ejecuta la transacción, escribe los registros de rehacer y deshacer, y luego retroalimenta la información sobre la ejecución exitosa de la transacción ( agree), y devuelve desacuerdo si falla
Fase de confirmación : el grupo de coordinación determina que cada participante puede ejecutar la transacción ( agree), por lo que emite una commitinstrucción a cada participante de la transacción, y cada participante de la transacción confirma la transacción; de lo contrario, retrocede.
defecto:
Problema de punto único de falla: si el grupo de coordinación cuelga, no podrá determinar si se compromete o retrocede a continuación
Problema de bloqueo: en la fase de preparación y la fase de compromiso, cada participante de la transacción bloqueará los recursos locales y esperará los resultados de ejecución de otras transacciones. El tiempo de bloqueo es largo y el tiempo de bloqueo de recursos es demasiado largo, por lo que la eficiencia de ejecución es relativamente baja. .
Solución 2: modo TCC
Es esencialmente una forma de compensación. El proceso de operación de transacción incluye tres métodos,
Prueba: detección y reserva de recursos;
Confirmar: se envía la operación comercial ejecutada; si Try tiene éxito, Confirm debe tener éxito;
Cancelar: Se liberan los recursos reservados.
Hay dos etapas de ejecución:
Fase de preparación (try): detección y reserva de recursos;
Etapa de ejecución (confirmar/cancelar): De acuerdo con el resultado del paso anterior, determine el siguiente método de ejecución. Si todos los participantes de la transacción en el paso anterior tuvieron éxito, ejecute confirmar aquí. De lo contrario, ejecute cancelar
probar, confirmar, cancelar son transacciones independientes, no se ven afectadas por otros participantes y no bloquearán la espera de otros
Por ejemplo: supongamos que el saldo original de la cuenta A es 100, y el saldo debe deducirse 30 yuanes.
Desventajas : es necesario escribir código manualmente para implementar probar, confirmar y cancelar, y hay muchas intrusiones de código, lo que aumenta la complejidad del desarrollo. Al mismo tiempo, si la acción de cancelación falla, los recursos no se pueden liberar y se debe introducir un mecanismo de reintento, y el reintento puede conducir a una ejecución repetida, y también se debe considerar el problema idempotente durante el reintento.
Solución 3: use MQ
El iniciador de la transacción A ejecuta la transacción local y envía la información de la transacción para que se ejecute al participante de la transacción B a través de MQ, y el participante de la transacción B ejecuta la transacción local después de recibir el mensaje. Usando la confiabilidad del mensaje de mq, el participante de la transacción B debe asegurarse de que el mensaje pueda consumirse eventualmente. Si falla, debe volver a intentarlo varias veces.
Desventajas: según la confiabilidad de MQ, el iniciador del mensaje puede retroceder, pero el participante del mensaje no puede provocar la reversión de la transacción, y la puntualidad de la transacción es deficiente, dependiendo de si el mensaje MQ se envía de manera oportuna.
Solución cuatro: modo AT
Similar al modo TCC, se divide en dos etapas, pero no necesita escribir el código de la segunda etapa usted mismo, que lo implementa Seata.
En la primera etapa, Seata interceptará el "SQL comercial", primero analizará la semántica SQL, encontrará los datos comerciales que se actualizarán en " ", 业务 SQLlos guardará como " before image" antes de que se actualicen los datos comerciales y luego ejecutará " 业务 SQL" para actualizar los datos comerciales Después de actualizar los datos, guárdelos como " after image", y finalmente adquiera el bloqueo de fila global y confirme la transacción. Todas las operaciones anteriores se completan dentro de una transacción de base de datos, lo que garantiza la atomicidad de las operaciones de una etapa.
before imageLa suma aquí es after imagesimilar a los registros de deshacer y rehacer de la base de datos, pero en realidad se simula con la base de datos.
Si se envía la segunda etapa, porque " 业务 SQL" se envió a la base de datos en la primera etapa, el marco de Seata solo necesita eliminar los datos de la instantánea y los bloqueos de fila guardados en la primera etapa para completar la limpieza de datos.
Si la segunda etapa es una reversión, Seata necesita revertir el " 业务 SQL" que se ejecutó en la primera etapa para restaurar los datos comerciales. El método de reversión consiste en utilizar " before image" para restaurar los datos comerciales.