分布式事务思想实现-最终一致性(实际产品实现的分享)

 

分布式事务思想：利用前置的消息服务保证消息生产到消息发送至消息中间件时可靠的，即必须发。
通过“消息服务”中消息的状态来保证可靠性。

描述个简单单一版本的分布式事务，用的就是最终一致性的概念(比较简陋，但是就是这种思想，条条大路通罗马)

1.预发送要执行的消息到消息服务，并持久化存储该消息(如一条要操作的信息的id及相关信息)。
2.返回存储结果(如成功时返回“预发送”，失败时返回“预发送失败”)
3.生产方得到返回结果时，如为成功就可以开始执行业务操作，如写到数据库一条记录，并把执行结果发送给消息服务。
4.消息服务得到该消息后，如是成功的，则可以“预发送”消息状态改为"发送中"状态，并发送改消息到kafka.
如是失败，即不执行后续操作即可。

以上操作执行时可能在任意过程出现问题，如网络断，服务异常等等等。
这时可以用“消息生产确认”这样的一个服务来根据消息生产方和消息服务的消息的状态来做一个确认和重发。
如，在2步骤时返回失败了，但是消息服务确实持久化了一条预发送的信息，我们就可以通过“消息生产确认”服务来通知消息生产方
进行业务上的重新执行，也就是从3步骤继续执行。
再比如，在3步骤又失败了，也就意味着生产者那方已经执行了3步骤的“写到数据库一条记录”，但是正向消息服务发送执行结果时
因为某些原因发送失败了。这时正常情况下，生产者业务正常处理并存到mysql,同时消息服务应该已经把该条消息的状态
改为"发送中"并发送的kafka。出现异常肯定是不对，就可以通过“消息生产确认”服务来对该数据轮询查看，如每五秒查看一下消息服务里面
的状态为"预发送"状态的数据，再到消息生产方根据消息id进行一个可查询的操作，如发现该消息在生产方已入库，即为成功执行了
一个用户操作，继续执行3步骤，保证了消息的完整。
再这种会出现异常的情况下，可以看到如果同一条消息异常出现的很频繁，如五秒内重发了很多次还是没有发送成功，当有很多类似的消息时
肯定对系统产生不良影响，我们可以为消息服务里面的消息执行重发多少次就不发了的这种终止操作，由“消息生产确认”服务，定时删除
生产方和消息服务两个里面的数据。保证一致性。

经过上面步骤，已经保证了消费发送到kafka的可靠性。后面说消费方如何消费，并如何保证和生产方的数据一致。

5.消费方消费kafka里面的消息，进行业务处理，持久化。
6.返回结果(带着消息的唯一标识等)，如成功了，则调用消息服务将里面对应记录由"发送中"状态改为“已消费”状态。这样就完成了一整条
完整链路，从生产到消费数据强一致性。

但是问题是步骤5/6都可能异常。即意味着消费不到kafka的数据，这时可以参考上面说的那个“消息生产确认”服务。用一个
类似的服务“消息消费确认”来保证消费者一定能消费到生产过来的数据。
如，当该“消息消费确认”服务看到消息服务中一条状态为“发送中”的数据存在了五秒，就认为该消息没被消费方消费，接下来把这条消息重发即可，
这样又形成了闭环，由于消费方的业务是幂等的，所以不会对业务有影响。