Antes hablado de conocimientos teóricos sobre las transacciones distribuidas 2pc, 3pc, TCC, la dirección del blog:
1, las transacciones distribuidas (1) --- principio 2PC y 3PC
2, transacciones distribuidas (2) --- principio TCC
Esto habla conocimientos teóricos sobre RocketMQ lograr una transacción distribuida, el próximo proyecto será un ejemplo para instanciar RocketMQ implemento transacciones distribuidas a través de SpringCloud.
En primer lugar, dar a la escena una transacción distribuida
列子: Supongamos que A a B Interruptor de 100 dólares , mientras que no están en el mismo servicio.
目标: Is A menos de 100 dólares, B más 100 dólares.
La situación actual puede ser, hay cuatro:
1）就是A账户减100 （成功），B账户加100 （成功）
2）就是A账户减100（失败），B账户加100 （失败）
3）就是A账户减100（成功），B账户加100 （失败）
4）就是A账户减100 （失败），B账户加100 （成功）
Aquí el primer y segundo caso es asegurar la consistencia de la transacción, pero tercero y cuarto no se garantiza la consistencia de los asuntos.
Así es como nos fijamos en RocketMQ para asegurar la consistencia de la transacción.
Dos, RocketMQ poner en práctica el principio de transacciones distribuidas
RocketMQ también soporta transacciones distribuidas antes sin embargo, pero no se abrió hasta RocketMQ 4.3 fue oficialmente abierta.
1, el concepto básico
最终一致性
RocketMQ consistencia eventual es una transacción distribuida , que garantiza la consistencia eventual es el mensaje, no tan fuerte como la misma transacción distribuida 2pc, 3pc, TCC, en cuanto a qué es lo último en asuntos de consistencia en detalle más adelante instrucciones.
Half Message(半消息)
medios de consumo de los consumidores sean temporalmente noticias . Productor mensaje ha sido enviado con éxito al final del corredor, pero este mensaje está marcado como 暂不能投递un estado, en el mensaje en este estado se refiere a los mensajes y medio. necesidad Productor
El mensaje 二次确认después, el fin del Consumidor para consumirlo.
消息回查
Parpadea debido a segmentos de la red, el reinicio productor de la aplicación y otros factores. Productor no ha llevado a la final de la mitad del mensaje (mensajes semi) fueron la confirmación secundaria . Este es el servidor Brock explora periódicamente 长期处于半消息的消息, lo hará
Pregunta sobre el estado final (final del Productor mensaje Confirmar o la restauración no actualizada ), el mensaje es el cheque de vuelta mensaje .
2, proceso de interacción transacción distribuida
Ali entiende esta tabla oficial, podemos entender el principio de la transacción distribuida RocketMQ.
Vamos a mostrar que bajo la imagen de arriba
1、A服务先发送个Half Message给Brock端，消息中携带 B服务 即将要+100元的信息。
2、当A服务知道Half Message发送成功后，那么开始第3步执行本地事务。
3、执行本地事务(会有三种情况1、执行成功。2、执行失败。3、网络等原因导致没有响应)
4.1)、如果本地事务成功，那么Product像Brock服务器发送Commit,这样B服务就可以消费该message。
4.2)、如果本地事务失败，那么Product像Brock服务器发送Rollback,那么就会直接删除上面这条半消息。
4.3)、如果因为网络等原因迟迟没有返回失败还是成功，那么会执行RocketMQ的回调接口,来进行事务的回查。
Puede ser aprendido desde el proceso anterior 只有A服务本地事务执行成功 ，B服务才能消费该message.
Entonces reflexionemos un par de preguntas?
为什么要先发送Half Message(半消息)
Creo que hay dos principales
1）可以先确认 Brock服务器是否正常 ，如果半消息都发送失败了 那说明Brock挂了。
2）可以通过半消息来回查事务，如果半消息发送成功后一直没有被二次确认，那么就会回查事务状态。
什么情况会回查
También hay dos casos
1）执行本地事务的时候，由于突然网络等原因一直没有返回执行事务的结果(commit或者rollback)导致最终返回UNKNOW，那么就会回查。
2) 本地事务执行成功后，返回Commit进行消息二次确认的时候的服务挂了，在重启服务那么这个时候在brock端
它还是个Half Message(半消息)，这也会回查。
Especial atención : Si marca la espalda, por lo que asegúrese de ver la ejecución de la transacción actual, mirada a la necesidad de volver a administrar los asuntos locales.
Imagínese si el segundo caso se produce debido a comprobar de nuevo si primero no comprueba la ejecución de la transacción actual, pero ejecutar directamente una transacción, entonces es equivalente a la implementación exitosa de los dos asuntos locales.
为什么说MQ是最终一致性事务
Por la imagen de arriba, podemos ver que, en el ejemplo anterior los asuntos inconsistentes ambos casos, nunca suceden
A账户减100 （失败），B账户加100 （成功）
Debido : Si un servicios de transacciones locales han fallado, y que los servicios B nunca van a hacer nada, porque el mensaje probablemente nunca alcanzó los servicios B.
A continuación, la A representa menos 100 (éxito), contabilidad B más 100 (fallo) no serían posibles.
La respuesta es sí
Un servicio porque cuando era sólo es responsable de la implementación exitosa del mensaje, el mensaje puede garantizar la entrega a la B, B de servicio como un resultado final de ejecución después de recibir el mensaje y no importa qué.
B servicio que el fracaso cómo hacerlo?
Si la final B falla, el código es casi seguro que por qué tener un problema causado por el anormal, desde el lado del consumidor tiene mecanismo de reintento RocketMQ, si el código no suele ser un problema de unos reintentos pueden tener éxito.
Si el código de razón es causada después de varios intentos fallan, no importa, las anomalías registradas por el 人工处理después de un tratamiento artificial revelar todos los detalles, se puede dejar que las cosas llegan a un acuerdo final.
