1. ¿Cuáles son las cuatro características de una transacción?
- Atomicidad (o indivisibilidad)
- Consistencia
- Aislamiento
- Durabilidad
A continuación, analizaremos los conceptos específicos de las cuatro funciones principales y sus principios de implementación subyacentes:
Antes de describir las cuatro funciones principales específicas, agreguemos un poco de conocimiento previo:
1. Arquitectura lógica y motor de almacenamiento
Como se muestra arriba, podemos dividir la arquitectura lógica del servidor mysql en tres capas:
① La primera capa: responsable de la conexión del cliente y autenticación de autorización , etc.
②La segunda capa: capa de servidor: responsable de analizar, optimizar y almacenar en caché las declaraciones de consulta, implementar y almacenar funciones integradas, etc.
③La tercera capa: motor de almacenamiento: responsable de almacenar y leer datos en la base de datos , la capa del servidor mysql no administra transacciones y las transacciones son implementadas por motores de almacenamiento. Entre ellos, los motores de almacenamiento que admiten transacciones incluyen innoDB y NDB Cluster, entre los cuales innoDB es ampliamente utilizado.
Presentaremos las cuatro características en detalle:
1. atomicidad
1. Definición
La atomicidad significa que una transacción es una unidad de trabajo indivisible, y las operaciones en ella se realizan o no se realizan; si una instrucción SQL en la transacción no se ejecuta, la instrucción ejecutada también debe revertirse y la base de datos vuelve a la frente al estado de la transacción.
2. Principio de implementación: redolog
Antes de hablar en detalle sobre el registro de redolog, expliquemos los registros de transacciones que existen en mysql: hay muchos tipos de registros de transacciones en mysql: incluidos los registros binarios, los registros de errores y los registros de consultas. Además, innoDB también proporciona dos registros: undolog (registro de reversión) y redolog (registro de rehacer), donde undolog es una garantía importante para la atomicidad y consistencia de los datos, y redolog se utiliza para garantizar la persistencia de las transacciones sexuales.
UNDOLOG
Undolog es una garantía importante para la atomicidad de las transacciones. Undolog puede hacer que todas las sentencias SQL que se han ejecutado con éxito en una transacción retrocedan. El flujo de trabajo específico es el siguiente: cuando una transacción modifica datos en la base de datos, innoDB generará un registro UNDO específico, una vez la ejecución de la transacción falla o se activa la operación de reversión, la información en el redolog se puede usar para restaurar el valor antes de la modificación de la base de datos.
Undolog es un registro lógico. Cuando se activa la reversión o falla la ejecución de la transacción, innoDB realizará operaciones en la dirección opuesta en la base de datos de acuerdo con la información registrada en undolog. Por ejemplo: la operación anterior fue una declaración de inserción y la declaración de eliminación es llamado en este momento; si la declaración de actualización ejecutada antes ejecutará la declaración de actualización en la dirección opuesta.
2. Persistencia
1. Definición
Persistencia significa que una vez que se confirma una transacción, sus cambios en la base de datos deben ser permanentes. Otras operaciones o fallas posteriores no deberían tener ningún efecto sobre él.
2. Principio de implementación
redolog
Antes de hablar sobre la persistencia de transacciones, primero hablemos sobre los antecedentes de la existencia de redolog y la necesidad de su existencia:
Las operaciones de lectura y escritura en la base de datos son operaciones sobre los datos en la base de datos, es decir, se requieren operaciones de IO en la base de datos, pero el IO frecuente a la base de datos es muy ineficiente, por esta razón, innoDB proporciona una capa de caché. (BufferPool), que almacena El mapeo de algunas páginas en la base de datos se utiliza como un búfer para los datos de la base de datos: cuando necesitamos leer datos de la base de datos, primero buscamos en el BufferPool, pero no podemos encontrarlo en el BufferPool. En este momento, obtenemos los datos de la base de datos y luego los transferimos. Se colocan en BufferPool, y escribir datos en la base de datos también es escribir primero los datos en BufferPool y luego actualizarlos periódicamente en el disco (este proceso es llamado cepillado sucio).
Sin embargo, si bien brinda comodidad, también existen ciertos riesgos y desventajas.Si la base de datos falla repentinamente en un momento determinado y todavía hay datos en el BufferPool en ese momento o los datos modificados no se descargan en el disco, inevitablemente conducirá a la pérdida de datos. Tampoco hay garantía de persistencia de datos. Para resolver este problema, surgieron los registros de redolog. Redolog también es un inicio de sesión en innoDB. Su principio de implementación es el siguiente: antes de que los datos se escriban en BufferPool o antes de que se modifiquen los datos en BufferPool, la operación se registrará primero en redolog. Cuando se confirme la transacción, se usará fsync. La interfaz actualiza el redolog, y si la base de datos se cae, la base de datos leerá la información en el redolog y restaurará los datos en la base de datos. El registro de rehacer usa WAL (registro de escritura anticipada, registro de escritura anticipada). Todos los datos se escribirán en el registro de redo antes de escribirse en BufferPool o modificar datos en BufferPool, lo que garantiza que los datos no se perderán debido al tiempo de inactividad de mysql. Esto asegura la persistencia de los datos.
Entonces, dado que redolog también escribe datos en la base de datos cuando se envían, ¿por qué es más eficiente que escribir en la base de datos a través de BufferPool?
Principalmente por los siguientes dos aspectos:
1. Redolog es E/S secuencial, mientras que BufferPool es E/S aleatoria. La ubicación para la lectura y escritura de datos se genera aleatoriamente y la velocidad es más lenta que la E/S secuencial.
2. La forma en que BufferPool escribe datos se basa en una página de datos. Generalmente, el tamaño de página de mysql es de 16 kb, y una vez que se modifican los datos en una página, es necesario reescribir y escribir toda la información de la página , y redolog es realmente efectivo. Escritura: solo se escriben los datos recién agregados o modificados, y las E/S no válidas se reducen considerablemente .
3. Aislamiento
1. Definición:
El aislamiento es para estudiar la interacción entre transacciones. El aislamiento significa que las operaciones dentro de la transacción están aisladas de otras transacciones. En un entorno concurrente, cada transacción no interfiere entre sí. El aislamiento estricto corresponde al nivel de aislamiento de la transacción. Serializable (serializable ) , pero la serialización rara vez se usa en aplicaciones prácticas debido a consideraciones de rendimiento.
2. Principio de implementación
La búsqueda del aislamiento es que las transacciones simultáneas no se afecten entre sí, y las consideraciones más importantes en nuestras operaciones diarias son las operaciones de lectura y escritura: 1. El impacto de una operación de escritura
en otra operación de escritura: a través del mecanismo de bloqueo resolver
2. El impacto de una operación de escritura en otra operación de lectura: resuelto por el mecanismo MVCC
1. Mecanismo de bloqueo: en los requisitos de la operación de escritura, solo se permite que una transacción escriba en la misma parte de los datos al mismo tiempo. El principio de implementación del mecanismo de bloqueo implementado por innoDB se puede entender de la siguiente manera: antes de que la transacción escriba los datos, primero debe obtener el recurso de bloqueo, y luego los datos se pueden escribir en este momento. Otras transacciones que deseen adquirir el recurso de bloqueo deben esperar a que la transacción actual revierta la transacción o libere el bloqueo después de enviar la escritura operación.
Bloqueos de fila y bloqueos de tabla: según la granularidad de los bloqueos, los bloqueos se pueden dividir en bloqueos de fila, bloqueos de tabla y bloqueos intermedios. Los bloqueos de tabla bloquean toda la tabla cuando una transacción opera con datos. El rendimiento de concurrencia es deficiente y el el bloqueo de fila solo bloquea los datos operados cuando la transacción opera los datos, y el rendimiento de concurrencia es bueno, pero teniendo en cuenta que la creación, inspección y destrucción del bloqueo necesitan consumir recursos, por lo que, en términos generales, el bloqueo de tabla es mejor que el de fila lock Puede ahorrar algunos recursos, pero teniendo en cuenta los requisitos comerciales y de rendimiento, generalmente se usan bloqueos de fila, pero diferentes motores de almacenamiento en sql admiten bloqueos de tabla y bloqueos de fila de manera diferente. Para innoDB, admite bloqueos de fila y bloqueos de tabla.
En cuanto al aislamiento de las transacciones y los problemas que pueden surgir de los diferentes aislamientos, te recomiendo que leas otro artículo mío, por lo que no lo repetiré aquí:
Comprensión profunda del aislamiento de transacciones
2. Mecanismo MVCC: el nivel de aislamiento predeterminado en el nivel de aislamiento de SQL es lectura repetible (Lectura repetida). En términos generales, RR no puede resolver el problema de lectura fantasma, pero RR implementado por innoDB puede evitar el problema de lectura fantasma. RR Para Para resolver problemas como lecturas sucias, lecturas no repetibles y lecturas fantasma, se usa MVCC: el nombre completo de MVCC es Control de concurrencia de múltiples versiones, que es un protocolo de control de concurrencia de múltiples versiones. MVCC tiene las siguientes características: Al mismo tiempo, los datos leídos por diferentes transacciones pueden ser diferentes (los datos en diferentes versiones son diferentes), como se muestra en la siguiente figura, que puede reflejar mejor esta característica: en el momento T5, la transacción A y transacción C Se pueden leer diferentes versiones de datos.
La mayor ventaja de MVCC es que no necesita agregar bloqueos de lectura, por lo que no hay conflicto entre lectura y escritura. El MVCC implementado por innoDB puede permitir la coexistencia de múltiples versiones. La realización de sus funciones se basa principalmente en las siguientes tecnologías y estructuras de datos: 1. Columnas ocultas:
base de datos Cada pieza de datos tiene una columna oculta, y la columna oculta tiene una identificación que apunta a la transacción de datos de esta fila y un puntero para deshacer el registro
2. Cadena de versión basada en deshacer registro: hay un puntero para deshacer registro en la columna oculta de cada dato, y cada puntero de deshacer registro también apuntará a una versión anterior de deshacer registro, formando así una cadena de versión de deshacer registro
3. ReadView: al ocultar la columna y la cadena de versión, los datos se pueden restaurar a la versión anterior, pero la versión específica que se restaurará debe determinarse mediante el ReadView específico. El llamado ReadView significa que la transacción (transacción A) toma una instantánea de todo el sistema de transacciones (trx_sys) en un momento determinado, y cuando la operación de lectura se realiza más tarde, la identificación de la transacción de lectura se comparará con trx_sys para determinar el lectura deseada Si los datos obtenidos son válidos para este ReadView, es decir, si son válidos para la transacción A.
El contenido principal de trx_sys y las reglas para juzgar la visibilidad son los siguientes:
low_limit_id: Indica el próximo id que el sistema debe asignar a la transacción en el ReadView generado, si el id de la transacción es mayor o igual al low_limit_id, no será visible para el ReadView.
up_limit_id: Indica la transacción que estaba activa en el sistema cuando se generó ReadView.Si el id de la transacción activa es menor que up_limit_id, será visible para ReadView
rw_trx_ids: indica la lista de id de transacciones activas en el sistema cuando se genera ReadView. Si la id de los datos de consulta está entre low_limit_id y up_limit_id, debe verificar si la transacción está en rw_trx_ids. Si es así, significa que la transacción está sigue activo cuando se genera ReadView, ReadView no es visible. Si no, significa que la transacción se ha confirmado cuando se genera ReadView, por lo que los datos son visibles para ReadView.
3. ¿MVCC es como una canción para evitar problemas como lecturas sucias, lecturas no repetibles y lecturas fantasma?
3.1 Lectura sucia:
Cuando la transacción A lea el saldo de zhangsan en T3, se generará un ReadView. Dado que la transacción B todavía está activa sin comprometerse en este momento, su ID de transacción debe estar en rw_trx_ids de ReadView. Por lo tanto, de acuerdo con las reglas introducidas anteriormente, el la modificación de la transacción B es ReadView no es visible. A continuación, la transacción A consulta los datos de la versión anterior según el registro de deshacer señalado por el puntero y obtiene que el saldo de zhangsan es 100. De esta forma, la transacción A evita lecturas sucias.
3.2 Lectura no repetible
Antes de que la transacción A lea el saldo de zhangsan en T2, se generará un ReadView. En este momento, la transacción B se analiza en dos situaciones. Una es que, como se muestra en la figura, la transacción ha comenzado pero no se ha confirmado. En este momento, su identificación de transacción está en rw_trx_ids de ReadView; la otra es que la transacción B aún no ha comenzado. En este momento, su transacción El id es mayor o igual que el low_limit_id de ReadView. En cualquier caso, de acuerdo con las reglas presentadas anteriormente, la modificación de la transacción B no es visible para ReadView.
Cuando la transacción A lea el saldo de zhangsan nuevamente en T5, juzgará la visibilidad de los datos de acuerdo con el ReadView generado en T2, de modo que se pueda juzgar que la modificación de la transacción B no es visible; por lo tanto, la transacción A consulta el deshacer registro señalado por el puntero Para la primera versión de los datos, el saldo de zhangsan es 100, evitando así lecturas no repetibles.
3.3 Lectura fantasma
El mecanismo de MVCC para evitar lecturas fantasma es muy similar a evitar lecturas no repetibles.
Antes de que la transacción A lea el saldo del usuario de 0<id<5 en el momento T2, se generará ReadView. En este momento, la transacción B se analiza en dos situaciones. Una es que, como se muestra en la figura, la transacción ha comenzado pero no se ha confirmado. En este momento, su identificación de transacción está en rw_trx_ids de ReadView; la otra es que la transacción B aún no ha comenzado. En este momento, su transacción El id es mayor o igual que el low_limit_id de ReadView. En cualquier caso, de acuerdo con las reglas presentadas anteriormente, la modificación de la transacción B no es visible para ReadView.
Cuando la transacción A vuelve a leer el saldo del usuario de 0<id<5 en el momento T5, juzgará la visibilidad de los datos de acuerdo con el ReadView generado en el momento T2, de modo que se pueda juzgar que la modificación de la transacción B no es visible . Por lo tanto, para los datos recién insertados lisi (id=2), la transacción A consulta los datos de la versión anterior de acuerdo con el registro de deshacer señalado por su puntero y encuentra que los datos no existen, evitando así la lectura fantasma.
La lectura bloqueada bloqueará los datos consultados (bloqueo compartido o bloqueo exclusivo) al realizar la consulta. Debido a las características del bloqueo, cuando una transacción bloquea y lee los datos, otras transacciones no pueden escribir los datos, por lo que se pueden evitar las lecturas sucias y las lecturas no repetibles. Para evitar la lectura fantasma, debe pasar el bloqueo de la siguiente tecla. El bloqueo de tecla siguiente es un tipo de bloqueo de fila, que es equivalente al bloqueo de registro ( bloqueo de registro ) + bloqueo de espacio ( bloqueo de espacio ) ; su característica es que no solo bloquea el registro en sí ( la función de bloqueo de registro ) , sino también bloquea un rango ( función de ) . Por lo tanto, las lecturas bloqueadas también pueden evitar lecturas sucias, lecturas no repetibles y lecturas fantasma para garantizar el aislamiento.
4. Consistencia
1. Concepto: Consistencia significa que después de la ejecución de la transacción, las restricciones de integridad de la base de datos no se rompen y el estado de los datos antes y después de la ejecución de la transacción es legal.
2. Realización: la coherencia es el objetivo final de la base de datos. La atomicidad, el aislamiento y la persistencia existen para satisfacer la coherencia. Excepto en el nivel de la base de datos para garantizar la coherencia de los datos, la consecución de la coherencia está en la capa de la aplicación. También se garantiza.
Medidas para lograr la consistencia:
1. Use atomicidad, persistencia y aislamiento para asegurar la consistencia.Si estas tres características no se pueden garantizar, no se puede garantizar la consistencia.
2. La base de datos en sí ofrece garantías, por ejemplo, no está permitido insertar información de cadena en los datos de plástico, y la longitud de la cadena no puede exceder la longitud máxima de la columna.
3. Garantía a nivel de aplicación, por ejemplo, si la operación de transferencia sólo descuenta el saldo del transmitente sin incrementar el saldo del receptor, por más perfecta que sea la base de datos, no se puede garantizar la consistencia del estado
5. Resumen:
- Atomicidad: la declaración se ejecuta por completo o no se ejecuta en absoluto, que es la característica principal de la transacción. La transacción en sí está definida por la atomicidad; la implementación se basa principalmente en el registro de deshacer
- Persistencia: garantiza que los datos no se perderán debido al tiempo de inactividad y otras razones después de que se confirme la transacción; la implementación se basa principalmente en el registro de rehacer
- Aislamiento: asegúrese de que la ejecución de la transacción no se vea afectada por otras transacciones tanto como sea posible; el nivel de aislamiento predeterminado de InnoDB es RR, y la implementación de RR se basa principalmente en el mecanismo de bloqueo (incluido el bloqueo de la siguiente tecla), MVCC (incluido el bloqueo oculto). columnas de datos y versiones basadas en cadena de registro de deshacer, vista de lectura)
- Consistencia: el fin último que persiguen las transacciones, la realización de la consistencia requiere tanto la garantía a nivel de base de datos como la garantía a nivel de aplicación