Propiedades ACID de transacciones de bases de datos, problemas de concurrencia de bases de datos y cuatro niveles de aislamiento

Propiedades ACID de transacciones de bases de datos, problemas de concurrencia de bases de datos y cuatro niveles de aislamiento

Transacción de base de datos

Una transacción de base de datos es un conjunto de unidades de operación lógica que transforman los datos de un estado a otro.

Un conjunto de unidades de operación lógica; una o más operaciones DML

Principio de procesamiento de transacciones

Asegúrese de que todas las transacciones se ejecuten como una unidad de trabajo, incluso si hay una falla, esta forma de ejecución no se puede cambiar.
Cuando una transacción realiza múltiples operaciones, todas las transacciones se confirman y luego se almacenan permanentemente; o todas las modificaciones se descartan y la transacción completa se revierte al estado original.

Una vez que se envían los datos, no se pueden revertir

Esas acciones darán como resultado el envío automático

Una vez que se ejecuta la operación DDL, enviará automáticamente el
DML. De forma predeterminada, una vez ejecutado, se enviará automáticamente.
Puede cancelar el compromiso automático de DML configurando autocommit = false.
De forma predeterminada, los datos se enviarán automáticamente cuando la conexión está cerrada.

Atributos ACID

La transacción debe satisfacer cuatro atributos, a saber, atomicidad, consistencia, aislamiento y durabilidad, es decir, los cuatro atributos de ACID.

Atomicidad

Una transacción es un todo indivisible, para asegurar el objetivo general de la transacción, la transacción debe ser atómica, es decir, cuando se modifican los datos, o se ejecutan todos o no se ejecuta ninguno. Es decir, no se permite que la transacción se complete parcialmente, evitando errores ocasionados por realizar solo una parte de estas operaciones.

consistencia

Antes y después de que se ejecute una transacción, los datos de la base de datos deben ser consistentes. El estado de coherencia de la base de datos debe cumplir con las restricciones especificadas por el bloqueo de modo, por lo que una vez que la transacción se ejecuta por completo, la base de datos todavía está en un estado coherente.

Por ejemplo: transferencia bancaria, la suma de las dos cuentas antes y después de la transferencia no debe modificarse.

Aislamiento

Las modificaciones realizadas por empresas concurrentes deben aislarse de las modificaciones realizadas por otras empresas concurrentes. El estado de los datos cuando la transacción ve la base de datos es el estado antes de que otra transacción concurrente la modifique, o el estado después de que otra transacción la modifique. La transacción no ve los datos en el estado intermedio.

Por ejemplo: para cualquier par de transacciones T1 y T2, para T1, T2 finaliza antes de que comience T1 o comienza la ejecución después de que finaliza T1.

Resistencia

También conocido como permanente, una vez completada la transacción, el DBMS (Database Management System) garantiza que la modificación de los datos en la base de datos es permanente, cuando el sistema o medio falla, la modificación también se mantiene permanentemente. La durabilidad generalmente está garantizada mediante la copia de seguridad y la recuperación de la base de datos.

  • Nota Estrictamente hablando, los atributos de transacción de la base de datos están garantizados por el sistema de gestión de la base de datos Durante el funcionamiento de toda la aplicación, la aplicación no necesita considerar la implementación ACID de la base de datos.

En circunstancias normales, la transacción se termina ejecutando una instrucción COMMIT (compromiso) o ROLLBACK (rollback). Cuando se ejecuta la instrucción COMMIT, todos los cambios realizados en la base de datos desde el inicio de la transacción se vuelven permanentes, es decir, se escriben en el disco, y cuando se ejecuta la instrucción ROLLBACK, todos los cambios realizados en la base de datos desde el inicio de la transacción será Deshacer, y el contenido de la base de datos se devuelve al estado en el que se encontraba antes de que comenzara la transacción. En cualquier caso, cuando se completa la transacción, se puede garantizar que regresará a un estado consistente.

Problemas de simultaneidad de la base de datos

Si no hay bloqueo y varios usuarios acceden a una base de datos al mismo tiempo, pueden surgir problemas cuando sus transacciones utilizan los mismos datos al mismo tiempo. Las inconsistencias de datos causadas por operaciones simultáneas incluyen: actualizaciones de datos perdidas, lectura de datos "sucios" (lecturas sucias) y lecturas no repetibles.

Actualización perdida

  • Ambas transacciones actualizan una fila de datos al mismo tiempo, y la actualización de los datos por una transacción sobrescribe la actualización de los datos por la otra transacción. Esto se debe a que el sistema no realiza ninguna operación de bloqueo, por lo que la concurrencia no está aislada.

Lectura sucia

  • Una transacción lee el resultado de la operación de datos no confirmados de otra transacción. Esto es bastante peligroso, porque es probable que todas las operaciones se reviertan.

No repetible

  • Lecturas no repetibles: una transacción lee la misma fila de datos dos veces, pero obtiene resultados diferentes.

Incluyendo las siguientes situaciones:

  • Lectura ficticia: después de que la transacción T1 lee ciertos datos, la transacción T2 los modifica, y cuando la transacción T1 vuelve a leer los datos, obtiene un valor diferente al de la vez anterior.
  • Lectura fantasma: la transacción realiza dos consultas durante la operación, y el resultado de la segunda consulta contiene datos que no aparecieron en la primera consulta o carecen de los datos que aparecieron en la primera consulta. Esto se debe a que otra transacción inserta datos durante las dos consultas.

Cuatro niveles de aislamiento de transacciones de bases de datos

Hay 4 niveles de aislamiento para las transacciones de la base de datos, de menor a mayor, son Lectura no confirmada, Lectura confirmada, Lectura repetible y Serializable. Estos cuatro niveles pueden resolver los problemas de lectura sucia, lectura no repetible y lectura fantasma uno por uno .
Los diferentes niveles de aislamiento manejan las transacciones de manera diferente.

  • Lectura no comprometida: gestiona solo las actualizaciones perdidas. Si una transacción ha comenzado a escribir datos, otras transacciones no pueden escribir al mismo tiempo, pero otras transacciones pueden leer esta fila de datos. Se puede lograr mediante "bloqueo de escritura exclusivo".
  • Leer datos confirmados (lectura confirmada): ocuparse de las actualizaciones perdidas y las lecturas sucias. La transacción que lee los datos permite que otras transacciones continúen accediendo a los datos de la fila modificada, pero la transacción de escritura no confirmada prohibirá que otras transacciones accedan a la fila modificada. Puede realizarse mediante "bloqueo de lectura compartido instantáneo" y "bloqueo de escritura exclusivo".
  • Lectura repetible (lectura repetible): lidiar con la actualización perdida, la lectura sucia y la lectura no repetible. Una transacción que lee datos prohibirá una transacción de escritura, pero se permite una transacción de lectura y una transacción de escritura prohíbe cualquier otra transacción. Puede realizarse mediante "bloqueo de lectura compartido" y "bloqueo de escritura exclusivo".
  • Serialización (serializable): proporciona un estricto aislamiento de transacciones. Requiere la pérdida de la ejecución de la serialización, las transacciones solo se pueden ejecutar una tras otra y no se pueden ejecutar al mismo tiempo. La serialización de transacciones no se puede lograr solo a través de "bloqueos de nivel de fila", y se deben usar otros mecanismos para garantizar que la transacción que acaba de realizar la operación de consulta no acceda a los datos recién insertados.

Cuanto mayor sea el nivel de aislamiento, más se podrá garantizar la integridad y la unidad de los datos, pero mayor será el impacto en el rendimiento simultáneo. Para la mayoría de las aplicaciones, primero puede considerar establecer el nivel de aislamiento del sistema de base de datos en Lectura confirmada. Puede evitar lecturas sucias y tiene un buen rendimiento de concurrencia. Aunque puede causar problemas de concurrencia, como lecturas no repetibles, lecturas fantasma y el segundo tipo de actualización perdida, la aplicación puede usar bloqueos pesimistas o bloqueos optimistas para controlar las ocasiones individuales en las que pueden ocurrir tales problemas.

  • Oracle admite dos niveles de aislamiento de transacciones: READ COMMITED, SERIALIZABLE. El nivel de aislamiento de transacciones predeterminado de Oracle es: READ COMMITED
  • Mysql admite 4 niveles de aislamiento de transacciones. El nivel de aislamiento de transacciones predeterminado de Mysql es: REPEATABLE READ

Configuración del nivel de aislamiento de transacciones

//查看当前事物级别:
SELECT @@tx_isolation;
//设置mysql的隔离级别:
//set session transaction isolation level 设置事务隔离级别

//设置read uncommitted级别:
set session transaction isolation level read uncommitted;

//设置read committed级别:
set session transaction isolation level read committed;

//设置repeatable read级别:
set session transaction isolation level repeatable read;

//设置serializable级别:
set session transaction isolation level serializable;

Código Java para obtener y establecer el nivel de aislamiento (la conexión a continuación es el objeto Conexión, la implementación específica no se organizará)

//获取数据库事务隔离级别
int transactionIsolation = conn.getTransactionIsolation();
//设置数据库事务隔离级别;事务隔离级别:TRANSACTION_READ_COMMITTED
conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);

Supongo que te gusta

Origin blog.csdn.net/qq_46388795/article/details/114452454
Recomendado
Clasificación