隔离级别
读未提交 (RU) 可以读取正在修改的数据
读已提交 （RC) 可以读取修改后的数据，不可读取正在修改的数据
可重复读 （RR) 多次读取 前后都一致，别的事务插入修改的数据不会读到
串化 （SR)
事务并发带来隔离问题
1 脏读：事务A读取事务B正在更新的数据，然后B回滚操作，那么事务A读取到的数据是脏的。
2 不可重复： 事务A多次读取同一批数据，事务B在事务A多次读取过程中，对数据做了更新提交操作。
导致事务A前后读取数据不一致。
3 幻读：事务A修改数据，事务B插入一条件数据，事务A再读的时候发现还有一笔数据没有修改。
隔离级别与并发问题
读未提交 (RU) 可脏读，可幻读，不可重复读
读已提交 （RC) 不可， 可幻读，不可重复读
可重复读 （RR) 不可 ， 可幻读， 可重复读
串化 （SR) 不可 不可 可
¿Cómo resolver la base de datos independiente?
Para resolver el problema ACID de la base de datos independiente, varios proveedores de bases de datos utilizan básicamente transacción + bloqueo + MVCC para garantizar.
Atomicidad: transacción + modo de bloqueo para lograr
Coherencia: también es un asunto a resolver
Nivel de aislamiento: ORACLE realiza el nivel de aislamiento RC a través de UNDO + transacción + bloqueo, mientras evita la lectura fantasma y la lectura no repetible
¿Qué es una transacción? Una transacción es un concepto que garantiza la consistencia de los datos antes y después de la modificación. 100 filas de datos no se pueden modificar. 50 filas se modifican correctamente y las otras 50 filas no se modifican.
Tampoco puede causar inconsistencias en la lógica de negocios antes y después de los datos. Por ejemplo, la cuenta A dedujo 50 exitosamente y la cuenta B aumentó en 50 falló.
Por lo tanto, se puede ver en lo anterior que una transacción consta de una declaración única y una declaración múltiple.
De forma predeterminada, una sola declaración inicia automáticamente la transacción y varias declaraciones deben abrirse manualmente
Utilice el siguiente comando para empaquetar varias declaraciones juntas.
iniciar la transicion
cometer;
A través de la solicitud de transacción, la base de datos modificará las filas modificadas por la declaración juntas o las modificará juntas y fallará.
¿Qué pasa si hay un éxito parcial y un fracaso parcial? Revertir la modificación correctamente.
Por lo tanto, el requisito de atomicidad se cumple a través de la transacción.
Transacción distribuida (ACID)
Luego, en una base de datos distribuida, nuestras transacciones o declaraciones modificadas se emiten a los siguientes 4 o más fragmentos.
Base de datos independiente independiente para cada fragmento.
Si se emite un fragmento, no está mal, puede hacer un uso completo del mecanismo inherente de la siguiente base de datos para lograr la atomicidad
¿Qué pasa si hay varias transacciones fragmentadas a continuación?
Por ejemplo, cuando se emite una sola declaración de modificación a 4 fragmentos, el valor predeterminado es dividir una transacción grande en 4 subtransacciones.
Envíe las 4 subtransacciones a la siguiente base de datos para su ejecución.
Entonces, lo mismo es cierto para el caso en el que parte de las filas de la base de datos independiente se modifica correctamente y parte de la modificación no se realiza correctamente.
Por ejemplo, dos fragmentos se modifican correctamente y los otros dos fragmentos no se modifican.
La razón del error puede ser que la base de datos fragmentada se cuelgue, esperando un bloqueo, y la subtransacción se mata cuando se encuentra con un interbloqueo.
Luego registre la ejecución de cada transacción en diferentes fragmentos en la capa superior, y marque OK si la ejecución es exitosa, de lo contrario será FALLO
GTID, SQL_ID, SHADING01, SHARDING02, SHAGDING03, SHADING04
00X1 S02, OK, OK FALLO FALLO
La modificación parcial es exitosa y los fragmentos OK se revierten,
Además, se debe establecer un TIEM_OUT para la transacción emitida. Después del tiempo de espera, la ejecución se considera fallida y se emite el comando ROLLBACK para el éxito.
Para transacciones de múltiples sentencias, agregamos un SQL_ID, que requiere que todo el SQL de esta transacción se ejecute en todos los nodos de fragmentos para que estén bien, y cualquier FAILE debe revertirse.
consistencia
No debería ser un problema en modo distribuido, porque cada consulta se envía a la base de datos después de que se lee usando el MVCC de la base de datos.
Cuando se encuentra un registro de bloqueo de transacción, los datos antiguos también se leerán en MVCC UNDO.
También encontrará este tipo de problemas. Por ejemplo, dos fragmentos se leen en el tiempo T1 y los datos de los dos siguientes fragmentos se leen en el tiempo T2, y los datos de estos dos fragmentos se han modificado y enviado.
Debido a que el tiempo de envío a los siguientes dos fragmentos es diferente, los datos de los cuatro fragmentos son inconsistentes antes y después.
El diseño de ZTE DB es crear un GTID arriba, y cada tabla a continuación tiene una columna oculta GTID, y cada consulta también obtiene el GTID y luego lo compara con el GTID de la fila.
Si los datos se actualizan, la lectura falla. Sin utilizar el mecanismo MVCC, la escritura bloqueaba la lectura.
De esta forma, es necesario modificar el código fuente de MYSQL PG, mejorar la interfaz, mejorar la consulta de reversión en función del valor GTID y la lectura de la instantánea MVCC.
La misma lectura repetida y lectura fantasma es difícil de lograr en un entorno distribuido, porque el siguiente mecanismo MVCC de la base de datos (MYSQL, PG, ORACLE) no se puede utilizar
Por lo tanto, es necesario modificar el núcleo de MYSQL, agregar una interfaz MVCC distribuida, por encima del middleware del nodo informático, y emitir transacciones o declaraciones de consulta a través de esta interfaz.
Cada declaración de transacción y consulta lleva un indicador de tiempo como GTID o SCN. La siguiente base de datos agrega una columna para cada fila de datos para almacenar GTID (SCN, TIMESTAMP).
La declaración de la interfaz distribuida determina si leer la instantánea de acuerdo con el GTID oculto. En lugar de una interfaz distribuida, utilice el ID de transacción MYSQL original o el SCN de ORACLE.