详谈分布式最终一致性

“什么是分布式系统？这取决于看系统的角度。对于坐在键盘前使用IBM个人电脑的人来说，电脑不是一个分布式的系统。但对于在电脑主板上趴着的虫子来说，这台电脑就是一个分布式系统。” —— Leslie Lamport

 

引言

分布式一致性问题随处可见，任何一个实体/联接模型，都可能存在分布式一致性问题。如果把单机拆开来看，CPU、内存、I/O设备组成的机箱本身就是一个小型的分布式系统，需要确保对这个系统操作的最终一致性。幸运的是这部分工作已经交给操作系统和数据库软件来帮我们完成。而在大型分布式企业级应用中，分布式最终一致性方案需要根据系统自身特点量身定制，是系统设计的重点。近年来随着沪江业务的快速增长和微服务治理推广，本地ACID事务早已不能满足业务和系统的发展需求。大部分业务流程都需要跨多微服务的调用来协作完成，并且要求系统确保分布式最终一致性。

可以选择分布式事务框架方案，目前主流的分布式事务框架大致可分为3类实现 :

• 基于XA协议的两阶段提交(2PC)方案

• 基于支付宝最早提出的TCC(Try、Confirm、Cancel)方案

• 基于ebay最早提出的消息队列异步确保方案

此外还有较轻的解决方案，业务系统可以根据自身需要，选择通过幂等/重试、状态机、恢复日志、异步校验等技术来确保最终一致性。

 

重型武器

采用分布式事务框架的方案，最终一致性由分布式事务框架保证，业务程序员对框架细节完全透明。选择这种方案，需要注意几个点。首先，由于分阶段提交协议本身的脆弱性，主流分阶段提交协议如2PC，3PC, TCC都无法完全确保最终一致性，要采用异步校验的手段兜底。其次，分阶段提交协议带来的高延迟，多次协议通信RTT带来的时间损耗。第三，基于消息队列异步确保的分布式事务框架实现，需要考虑消息可靠性和业务侵入问题。分布式事务框架也有巨大的优势，首先，分布式事务被框架封装成切面，业务开发只需关心纯业务。其次，分布式事务的代码开发量大大减少。对一致性和代码质量有极高要求的银行、金融领域，分布式事务框架是最佳选择。

 

轻型武器

不同于采用分布式事务框架的最终一致性方案，程序员也可以选择通过幂等/重试、状态机、恢复日志、异步校验等技术来确保最终一致性。这种方案不受限于平台和框架，系统较精简灵活，初期业务系统大都基于这种分布式一致性解决方案。不过这种方案对业务开发的要求更高，分布式一致性