基于Kafka消息驱动最终一致事务（一） 基于Kafka消息驱动最终一致事务（二）

基本可用软状态最终一致事务

本用例分两个数据库分别是用户库和交易库，不使用分布式事务，使用基于消息驱动实现基本可用软状态最终一致事务（BASE）。现在说明下事务逻辑演化步骤，尊从CAP原则，即分布式系统不能全部确保一致性、可用性、分区容错性，只能三选二。文章里从一致性模式讨论，例子里每次出售物品时，将一行添加到交易表中，并更新买方和卖方的数量。 使用ACID风格的事务这是强一致性事务，SQL将如图所示。

同一资源使系统可用性没有提高。如图所示。

后端组件消息处理的可用性较低是可以接受的。2PC消息流如图：

Message flow

Coordinator                                         Cohort
                              QUERY TO COMMIT
                -------------------------------->
                              VOTE YES/NO           prepare*/abort*
                <-------------------------------
commit*/abort*                COMMIT/ROLLBACK
                -------------------------------->
                              ACKNOWLEDGMENT        commit*/abort*
                <--------------------------------  
end

如果需要，可以使用两个独立的事务完成此操作：一个在消息队列中，一个在用户数据库上。 除非数据库操作成功提交，否则队列操作不会提交。 该算法现在支持部分故障，并且仍然提供事务保证而不诉诸于2PC。

 

时间。

 

 用例分析基于Kafka消息驱动最终一致事务（二）

参考资料

1，http://queue.acm.org/detail.cfm?id=1394128

2，Spring Data JPA - Multiple datasources example