1-1 ¿Qué es una transacción distribuida?
Con el rápido desarrollo de Internet, los sistemas de software han cambiado de aplicaciones monolíticas originales a aplicaciones distribuidas. El siguiente diagrama describe la evolución de las aplicaciones monolíticas a microservicios:
los sistemas distribuidos dividirán un sistema de aplicaciones en múltiples aplicaciones desplegables independientemente. Servicios, por lo que se requiere la cooperación remota entre servicios y servicios para completar las operaciones de transacción. En este entorno de sistema distribuido, los servicios remotos entre diferentes servicios a través de la red para completar transacciones se denominan transacciones distribuidas, como el registro de usuarios para enviar transacciones de crédito, La creación de transacciones de inventario de reducción de pedidos, transacciones de transferencia bancaria, etc. son todas transacciones distribuidas.
Sabemos que las transacciones locales dependen de las características de transacción proporcionadas por la propia base de datos, por lo que la siguiente lógica puede controlar las transacciones locales:
begin transaction；
//1.本地数据库操作：张三减少金额
//2.本地数据库操作：李四增加金额
commit transation;
Pero en un entorno distribuido, se convertirá en lo siguiente:
begin transaction；
//1.本地数据库操作：张三减少金额
//2.远程调用：让李四增加金额
commit transation;
Se puede imaginar que cuando la llamada remota hizo que Li Si aumentara la cantidad con éxito, la llamada remota no regresó debido a problemas de red. En este momento, el envío de la transacción local falló y la operación de reducción de la cantidad de Zhang San fue revertida. En este momento, los datos de Zhang San y Li Si son Inconsistente
Por lo tanto, según la arquitectura distribuida, no se pueden usar las transacciones tradicionales de la base de datos. Las cuentas de Zhang San y Li Si no están en una base de datos o incluso en un sistema de aplicación. La transacción de transferencia debe llamarse de forma remota, lo que causará la distribución debido a problemas de red. Problemas de transacción.
1-2 escenarios generados por transacciones distribuidas
1. Un escenario típico es una arquitectura de microservicio.Los microservicios completan las operaciones de transacción a través de llamadas remotas. Por ejemplo: ordenar microservicios y microservicios de inventario, solicitar microservicios solicitar microservicios de inventario menos inventario al realizar pedidos. En resumen: los procesos de JVM cruzada generan transacciones distribuidas.
2. Sistema monolítico que accede a múltiples instancias de bases de datos Cuando un sistema monolítico necesita acceder a múltiples bases de datos (instancias), se producirán transacciones distribuidas. Por ejemplo, la información del usuario y la información del pedido se almacenan en dos instancias de MySQL, y el sistema de administración del usuario elimina la información del usuario. Debe eliminar la información del usuario y la información del pedido del usuario por separado. Debido a que los datos se distribuyen en diferentes instancias de datos, debe operar a través de diferentes enlaces de bases de datos. Los datos, las transacciones distribuidas se producen en este momento. En resumen: generar transacciones distribuidas en instancias de bases de datos.
3. Múltiples servicios que acceden a la misma instancia de la base de datos, tales como: microservicios de pedidos y microservicios de inventario generarán transacciones distribuidas incluso si acceden a la misma base de datos, la razón es que a través del proceso JVM, los dos microservicios mantienen diferentes enlaces de base de datos para operaciones de base de datos En este momento, se producen transacciones distribuidas.
1-3 Teoría básica de la transacción distribuida CAP
El sistema distribuido se denomina distribuido porque los nodos que proporcionan servicios se distribuyen en diferentes máquinas e interactúan entre sí a través de la red. El sistema completo no se puede dejar sin servicio debido a un pequeño problema de red. Los factores de red se han convertido en uno de los criterios para las transacciones distribuidas. Por lo tanto, las transacciones distribuidas necesitan más apoyo teórico. A continuación, primero aprendamos sobre la teoría CAP de las transacciones distribuidas.
CAP es la abreviatura de Consistencia, Disponibilidad, Tolerancia de partición, que significa consistencia, disponibilidad y tolerancia de partición.
A continuación explicamos por separado: para facilitar la comprensión de la teoría CAP, combinamos algunos escenarios de negocios en el sistema de comercio electrónico para comprender CAP.
La siguiente figura es el proceso de ejecución de la gestión de información de productos:
El proceso de ejecución general es el siguiente:
1. El servicio de productos básicos solicita a la base de datos principal que escriba la información de los productos (agregar productos, modificar productos, eliminar productos)
2. La base de datos principal escribe con éxito la respuesta al servicio de productos.
3. La solicitud del servicio de productos básicos lee la información del producto de la base de datos.
C - Consistencia
La coherencia significa que la operación de lectura después de la operación de escritura puede leer el último estado de datos. Cuando los datos se distribuyen en varios nodos, los datos leídos de cualquier nodo son el último estado.
En la figura anterior, la coherencia de la lectura y escritura de información de productos básicos es lograr los siguientes objetivos:
1. Si el servicio de productos básicos se escribe correctamente en la base de datos maestra, la consulta a la base de datos esclava para obtener nuevos datos también es exitosa.
2. Si la escritura del servicio básico falla en la base de datos maestra, también falla la consulta a la base de datos esclava para obtener nuevos datos.
¿Cómo lograr consistencia?
1. Después de escribir en la base de datos maestra, los datos deben sincronizarse con la base de datos esclava.
2. Después de escribir en la base de datos maestra, la base de datos esclava debe bloquearse durante la sincronización con la base de datos esclava, y el bloqueo debe liberarse después de que se complete la sincronización, para evitar consultar en la base de datos esclava los datos antiguos después de que los nuevos datos se escriban con éxito.
Las características de la coherencia del sistema distribuido:
1. Debido al proceso de sincronización de datos, habrá un cierto retraso en la respuesta de la operación de escritura.
2. Para garantizar la coherencia de los datos, los recursos se bloquearán temporalmente y los recursos bloqueados se liberarán después de que se complete la sincronización de datos.
3. Si el nodo que solicita la sincronización de datos falla, se devolverá un mensaje de error y no se devolverán los datos antiguos.
A - Disponibilidad
La disponibilidad significa que cualquier operación de transacción puede obtener el resultado de la respuesta, y no habrá tiempo de espera de respuesta ni error de respuesta.
En la figura anterior, la legibilidad de la información de los productos básicos para cumplir con la disponibilidad es lograr los siguientes objetivos:
1. La solicitud de consulta de datos recibida de la base de datos puede responder de inmediato a los resultados de la consulta de datos.
2. El tiempo de espera de respuesta o error de respuesta no está permitido desde la base de datos.
¿Cómo lograr la usabilidad?
1. Después de escribir en la base de datos maestra, los datos deben sincronizarse con la base de datos esclava.
2. Dado que se debe garantizar la disponibilidad de la base de datos secundaria, los recursos en la base de datos secundaria no se pueden bloquear.
3. Incluso si los datos no se han sincronizado, los datos a consultar deben ser devueltos desde la base de datos, incluso los datos antiguos. Si no hay datos antiguos, puede devolver un mensaje predeterminado de acuerdo con la convención, pero no puede devolver un error o la respuesta agota el tiempo de espera.
Características de la disponibilidad del sistema distribuido:
1. Todas las solicitudes son respondidas y no habrá tiempo de espera de respuesta ni error de respuesta.
P - Tolerancia de partición
En general, cada nodo del sistema distribuido se implementa en una subred diferente. Esta es la partición de la red. Es inevitable que la comunicación entre los nodos falle debido a problemas de red. En este momento, el servicio aún se puede proporcionar externamente. Sexo
En la figura anterior, la lectura y escritura de información de productos para cumplir con la tolerancia de partición es lograr los siguientes objetivos:
1. La falla en la sincronización de datos de la base de datos maestra a la base de datos esclava no afecta las operaciones de lectura y escritura.
2. Si uno de los nodos cuelga, no afectará el servicio provisto por el otro nodo.
¿Cómo lograr la tolerancia de partición?
1. Intente utilizar una operación asincrónica en lugar de síncrona, por ejemplo, use el modo asíncrono para sincronizar datos de la base de datos maestra a los datos esclavos, de modo que los nodos puedan lograr un acoplamiento flexible.
2. Agregue nodos esclavos, uno de los cuales se cuelga de los demás para proporcionar servicios.
Las características de la tolerancia de partición distribuida:
1. La tolerancia de partición es la capacidad básica del sistema distribuido.
1-4 combinación CAP
En todos los escenarios de transacciones distribuidas, las tres características de CAP no se proporcionarán al mismo tiempo, porque C y A no pueden coexistir bajo la premisa de tener P.
1) AP:
Renunciar a la coherencia y buscar tolerancia y disponibilidad de partición. Esta es una opción cuando se diseñan muchos sistemas distribuidos. Nuestro Eruka realmente busca alta disponibilidad.
2) CP:
Renunciar a la usabilidad y buscar consistencia y tolerancia a fallas de partición. Nuestro cuidador del zoológico en realidad está buscando una consistencia fuerte. Por ejemplo, transferencia entre bancos. Una solicitud de transferencia debe esperar a que ambos bancos completen toda la transacción.
3) CA:
Renunciar a la tolerancia de partición, es decir, no particionar, no considerar el problema de la falla de la red o el bloqueo del nodo, puede lograr consistencia y disponibilidad. Entonces el sistema no será un sistema distribuido estándar, y nuestros datos relacionales más comúnmente utilizados cumplen con CA.
1-1 ¿Qué es una transacción distribuida?
Con el rápido desarrollo de Internet, los sistemas de software han cambiado de aplicaciones monolíticas originales a aplicaciones distribuidas. El siguiente diagrama describe la evolución de las aplicaciones monolíticas a microservicios:
los sistemas distribuidos dividirán un sistema de aplicaciones en múltiples aplicaciones desplegables independientemente. Servicios, por lo que se requiere la cooperación remota entre servicios y servicios para completar las operaciones de transacción. En este entorno de sistema distribuido, los servicios remotos entre diferentes servicios a través de la red para completar transacciones se denominan transacciones distribuidas, como el registro de usuarios para enviar transacciones de crédito, La creación de transacciones de inventario de reducción de pedidos, transacciones de transferencia bancaria, etc. son todas transacciones distribuidas.
Sabemos que las transacciones locales dependen de las características de transacción proporcionadas por la propia base de datos, por lo que la siguiente lógica puede controlar las transacciones locales:
begin transaction；
//1.本地数据库操作：张三减少金额
//2.本地数据库操作：李四增加金额
commit transation;
Pero en un entorno distribuido, se convertirá en lo siguiente:
begin transaction；
//1.本地数据库操作：张三减少金额
//2.远程调用：让李四增加金额
commit transation;
Se puede imaginar que cuando la llamada remota hizo que Li Si aumentara la cantidad con éxito, la llamada remota no regresó debido a problemas de red. En este momento, el envío de la transacción local falló y la operación de reducción de la cantidad de Zhang San fue revertida. En este momento, los datos de Zhang San y Li Si son Inconsistente
Por lo tanto, según la arquitectura distribuida, no se pueden usar las transacciones tradicionales de la base de datos. Las cuentas de Zhang San y Li Si no están en una base de datos o incluso en un sistema de aplicación. La transacción de transferencia debe llamarse de forma remota, lo que causará la distribución debido a problemas de red. Problemas de transacción.
1-2 escenarios generados por transacciones distribuidas
1. Un escenario típico es una arquitectura de microservicio.Los microservicios completan las operaciones de transacción a través de llamadas remotas. Por ejemplo: ordenar microservicios y microservicios de inventario, solicitar microservicios solicitar microservicios de inventario menos inventario al realizar pedidos. En resumen: los procesos de JVM cruzada generan transacciones distribuidas.
2. Sistema monolítico que accede a múltiples instancias de bases de datos Cuando un sistema monolítico necesita acceder a múltiples bases de datos (instancias), se producirán transacciones distribuidas. Por ejemplo, la información del usuario y la información del pedido se almacenan en dos instancias de MySQL, y el sistema de administración del usuario elimina la información del usuario. Debe eliminar la información del usuario y la información del pedido del usuario por separado. Debido a que los datos se distribuyen en diferentes instancias de datos, debe operar a través de diferentes enlaces de bases de datos. Los datos, las transacciones distribuidas se producen en este momento. En resumen: generar transacciones distribuidas en instancias de bases de datos.
3. Múltiples servicios que acceden a la misma instancia de la base de datos, tales como: microservicios de pedidos y microservicios de inventario generarán transacciones distribuidas incluso si acceden a la misma base de datos, la razón es que a través del proceso JVM, los dos microservicios mantienen diferentes enlaces de base de datos para operaciones de base de datos En este momento, se producen transacciones distribuidas.
1-3 Teoría básica de la transacción distribuida CAP
El sistema distribuido se denomina distribuido porque los nodos que proporcionan servicios se distribuyen en diferentes máquinas e interactúan entre sí a través de la red. El sistema completo no se puede dejar sin servicio debido a un pequeño problema de red. Los factores de red se han convertido en uno de los criterios para las transacciones distribuidas. Por lo tanto, las transacciones distribuidas necesitan más apoyo teórico. A continuación, primero aprendamos sobre la teoría CAP de las transacciones distribuidas.
CAP es la abreviatura de Consistencia, Disponibilidad, Tolerancia de partición, que significa consistencia, disponibilidad y tolerancia de partición.
A continuación explicamos por separado: para facilitar la comprensión de la teoría CAP, combinamos algunos escenarios de negocios en el sistema de comercio electrónico para comprender CAP.
La siguiente figura es el proceso de ejecución de la gestión de información de productos:
El proceso de ejecución general es el siguiente:
1. El servicio de productos básicos solicita a la base de datos principal que escriba la información de los productos (agregar productos, modificar productos, eliminar productos)
2. La base de datos principal escribe con éxito la respuesta al servicio de productos.
3. La solicitud del servicio de productos básicos lee la información del producto de la base de datos.
C - Consistencia
La coherencia significa que la operación de lectura después de la operación de escritura puede leer el último estado de datos. Cuando los datos se distribuyen en varios nodos, los datos leídos de cualquier nodo son el último estado.
En la figura anterior, la coherencia de la lectura y escritura de información de productos básicos es lograr los siguientes objetivos:
1. Si el servicio de productos básicos se escribe correctamente en la base de datos maestra, la consulta a la base de datos esclava para obtener nuevos datos también es exitosa.
2. Si la escritura del servicio básico falla en la base de datos maestra, también falla la consulta a la base de datos esclava para obtener nuevos datos.
¿Cómo lograr consistencia?
1. Después de escribir en la base de datos maestra, los datos deben sincronizarse con la base de datos esclava.
2. Después de escribir en la base de datos maestra, la base de datos esclava debe bloquearse durante la sincronización con la base de datos esclava, y el bloqueo debe liberarse después de que se complete la sincronización, para evitar consultar en la base de datos esclava los datos antiguos después de que los nuevos datos se escriban con éxito.
Las características de la coherencia del sistema distribuido:
1. Debido al proceso de sincronización de datos, habrá un cierto retraso en la respuesta de la operación de escritura.
2. Para garantizar la coherencia de los datos, los recursos se bloquearán temporalmente y los recursos bloqueados se liberarán después de que se complete la sincronización de datos.
3. Si el nodo que solicita la sincronización de datos falla, se devolverá un mensaje de error y no se devolverán los datos antiguos.
A - Disponibilidad
La disponibilidad significa que cualquier operación de transacción puede obtener el resultado de la respuesta, y no habrá tiempo de espera de respuesta ni error de respuesta.
En la figura anterior, la legibilidad de la información de los productos básicos para cumplir con la disponibilidad es lograr los siguientes objetivos:
1. La solicitud de consulta de datos recibida de la base de datos puede responder de inmediato a los resultados de la consulta de datos.
2. El tiempo de espera de respuesta o error de respuesta no está permitido desde la base de datos.
¿Cómo lograr la usabilidad?
1. Después de escribir en la base de datos maestra, los datos deben sincronizarse con la base de datos esclava.
2. Dado que se debe garantizar la disponibilidad de la base de datos secundaria, los recursos en la base de datos secundaria no se pueden bloquear.
3. Incluso si los datos no se han sincronizado, los datos a consultar deben ser devueltos desde la base de datos, incluso los datos antiguos. Si no hay datos antiguos, puede devolver un mensaje predeterminado de acuerdo con la convención, pero no puede devolver un error o la respuesta agota el tiempo de espera.
Características de la disponibilidad del sistema distribuido:
1. Todas las solicitudes son respondidas y no habrá tiempo de espera de respuesta ni error de respuesta.
P - Tolerancia de partición
En general, cada nodo del sistema distribuido se implementa en una subred diferente. Esta es la partición de la red. Es inevitable que la comunicación entre los nodos falle debido a problemas de red. En este momento, el servicio aún se puede proporcionar externamente. Sexo
En la figura anterior, la lectura y escritura de información de productos para cumplir con la tolerancia de partición es lograr los siguientes objetivos:
1. La falla en la sincronización de datos de la base de datos maestra a la base de datos esclava no afecta las operaciones de lectura y escritura.
2. Si uno de los nodos cuelga, no afectará el servicio provisto por el otro nodo.
¿Cómo lograr la tolerancia de partición?
1. Intente utilizar una operación asincrónica en lugar de síncrona, por ejemplo, use el modo asíncrono para sincronizar datos de la base de datos maestra a los datos esclavos, de modo que los nodos puedan lograr un acoplamiento flexible.
2. Agregue nodos esclavos, uno de los cuales se cuelga de los demás para proporcionar servicios.
Las características de la tolerancia de partición distribuida:
1. La tolerancia de partición es la capacidad básica del sistema distribuido.
1-4 combinación CAP
En todos los escenarios de transacciones distribuidas, las tres características de CAP no se proporcionarán al mismo tiempo, porque C y A no pueden coexistir bajo la premisa de tener P.
1) AP:
Renunciar a la coherencia y buscar tolerancia y disponibilidad de partición. Esta es una opción cuando se diseñan muchos sistemas distribuidos. Nuestro Eruka realmente busca alta disponibilidad.
2) CP:
Renunciar a la usabilidad y buscar consistencia y tolerancia a fallas de partición. Nuestro cuidador del zoológico en realidad está buscando una consistencia fuerte. Por ejemplo, transferencia entre bancos. Una solicitud de transferencia debe esperar a que ambos bancos completen toda la transacción.
3) CA:
Renunciar a la tolerancia de partición, es decir, no particionar, no considerar el problema de la falla de la red o el bloqueo del nodo, puede lograr consistencia y disponibilidad. Entonces el sistema no será un sistema distribuido estándar, y nuestros datos relacionales más comúnmente utilizados cumplen con CA.
