Introducción a escenarios empresariales.
Orden de sistema único
En el sistema de comercio electrónico único, el usuario realiza un pedido con éxito, porque toda la operación de pedido se completa con el mismo método, y la tabla correspondiente al producto y la tabla correspondiente al pedido están en la misma base de datos, de acuerdo con la atomicidad de la base de datos (Atomicity) , Consistencia, Aislamiento o Durabilidad. Una vez que el servicio de pedido es exitoso, el inventario se deduce y los datos para generar la operación de pedido serán efectivos al mismo tiempo. El proceso es el siguiente:
Orden de sistema distribuido
En un sistema distribuido, el proceso de pedido se microservicios, y el proceso de pedido se divide en servicios de pedido y servicios de productos básicos. En este momento, la base de datos también se descompone y se divide en bases de datos de pedidos y bases de datos de productos correspondientes. Si se reemplaza directamente con el microservicio correspondiente de acuerdo con el método en la misma transacción en el proceso anterior, el diagrama de flujo es el siguiente:
Cuando se utilizan solicitudes RPC o HTTP para llamar al servicio de bienes y al servicio de pedidos en el servicio de pedidos, los datos de los bienes pueden ser inconsistentes con los datos de la base de datos de pedidos debido a un tiempo de inactividad anormal de la red o del servidor . Puede haber un servicio de pedidos. Debido a la reversión de datos anormal, no se generan datos en la base de datos de pedidos cuando se llaman los bienes, y el procesamiento del servicio de bienes es exitoso. La deducción de inventario en la base de datos de bienes es exitosa. Un ejemplo de la razón de la anormalidad de la red o el tiempo de inactividad del servidor es el siguiente:
Transacción distribuida
Presentación de base de datos en dos fases
¿Cómo resolver el problema de los datos inconsistentes después de dividirlos en microservicios como se indicó anteriormente? En este momento, es necesario introducir transacciones distribuidas. Si la deducción de inventario y la generación de pedidos tienen efecto en el sistema distribuido al mismo tiempo, se puede lograr a través del método de presentación en dos etapas de la base de datos.De acuerdo con la teoría CAP (para más detalles, consulte la comprensión profunda de la teoría CAP y los escenarios aplicables ) 2PC pertenece al modo CP .
Los estudiantes que entienden las transacciones distribuidas de la base de datos deben saber que el 2PC admitido por la base de datos también se llama Transacciones XA. Entre ellos, XA es un acuerdo de presentación en dos fases, el acuerdo se divide en las siguientes dos etapas:
- La primera etapa: el coordinador de transacciones requiere que cada base de datos involucrada en la transacción precomprometa (precomprometa) esta operación y refleje si se puede comprometer.
- La segunda etapa: el coordinador de transacciones requiere que cada base de datos envíe datos.
Entre ellos, si alguna base de datos veta este envío, todos los datos de operación de la base de datos se revertirán. Este método tendrá un serio impacto en el rendimiento y también tiene las siguientes desventajas:
- Problema de bloqueo sincrónico! Durante la ejecución, todos los nodos participantes están bloqueando transacciones. Cuando los participantes ocupan recursos públicos, el acceso a los recursos públicos por parte de otros nodos de terceros también se bloquea.
- Único punto de falla! Debido a la importancia del coordinador, una vez que el coordinador falle, los participantes continuarán bloqueando. Especialmente en la segunda etapa, cuando el coordinador falla, todos los participantes todavía están en el estado de bloquear los recursos de la transacción y no pueden continuar completando las operaciones de la transacción.
- ¡Los datos son inconsistentes! En el proceso de envío de dos fases, cuando el coordinador envió una solicitud de confirmación a los participantes, se produjo una anomalía en la red o tiempo de inactividad del servidor , lo que resultaría en el éxito del envío parcial de datos y el fracaso del envío parcial, lo que provocaría una inconsistencia de los datos.
Mensaje middleware + HttpClient para implementar transacciones distribuidas
En los sistemas distribuidos, la disponibilidad del sistema generalmente se presta más atención. En base a esto, las personas han propuesto la teoría BASE, que se utiliza para ampliar aún más el teorema CAP. La teoría BASE se refiere a:
- Básicamente disponible
- Estado suave
- Eventualmente consistente
La teoría BASE es el resultado de una compensación entre consistencia y disponibilidad en CAP. La idea central de la teoría es: no podemos lograr una consistencia fuerte, pero cada aplicación puede usar métodos apropiados para lograr que el sistema alcance sus características comerciales. Consistencia eventual . En el proyecto, Kafka + HttpClient se utilizó para implementar transacciones distribuidas basadas en la teoría BASE. La idea de implementación es la siguiente:
- El iniciador de llamadas de servicio envía la información http del servicio llamado a través de mensajes Kafka , y la información de servicio de éxito y falla del iniciador de llamadas de servicio de devolución de llamada . En este momento, el estado del objeto comercial del originador de la llamada de servicio utiliza el estado suave , por ejemplo, el estado del pedido está en el pedido.
- Cree un consumidor que reenvíe el middleware del mensaje de solicitud http para solicitar la solicitud http del servicio llamado. Después de que el servicio llamado se ejecuta con éxito, determina el servicio de devolución de llamada para llamar al servicio exitoso o al servicio fallido del iniciador de acuerdo con el estado devuelto por la solicitud HTTP, de modo que el estado del objeto del servicio del iniciador del servicio pueda alcanzar la consistencia final , por ejemplo, el pedido es exitoso o el pedido falla .
- Para garantizar que el mensaje se consume, es necesario utilizar una estrategia de transmisión síncrona al enviar el mensaje. Al consumir información de solicitud http, después de que el mensaje necesite confirmar el consumo, envíe manualmente el desplazamiento de la partición para asegurarse de que el mensaje se debe consumir. En este momento, el servicio de solicitud http del destinatario de la llamada y los servicios de éxito y falla del iniciador del servicio deben satisfacer el diseño idempotente .
Tome el siguiente servicio único como ejemplo, el diagrama de flujo es el siguiente:
El resto de los métodos de implementación pueden referirse al chat sobre transacciones distribuidas y luego hablar sobre la solución
