20191127 分布式系统下最终一致性解决方案

分布式事务+(幂等、重试、状态机、恢复日志、异步校验)

一个操做需要在四个服务上写数据，这四个服务对应不同的db；aMysql,bMysql，cMysql，dMysql；

如何保证同时成功，同时失败？

A服务在写sql的同时，调用服务B,这两个操做在一个事务里面。B服务也可以这样处理。

 

如果接口不能保证幂等性，数据的唯一性将很难保证。 数据的唯一性。

 

账户表数据重复：接口进行幂等性处理，分布式环境下使用redis锁，唯一索引。

把无效数据迁移到另一张表中，对用户的手机号做唯一索引。

 

如何保证消息投递的可靠性？ 使用mysql进行保证，发送消息前保存消息状态，消费端接收完成或者消费完成后，在修改消息状态。配合定时任务处理。重新发送。

 

业务逻辑保证幂等，如果业务逻辑无法保证幂等，则要增加一个去重表或者类似的实现。

 

要保证数据的一致性，首先数据不一致有哪些出现的场景？

1）接口没做幂等，数据重复。

2）消息丢失，导致订单支付状态不一致等。

3）异步处理数据，不知道数据是否执行成功。

4）在四个db中需要落库，如何保证都执行成功。 分布式事务框架。

 

多副本数据的强一致性，弱一致性和最终一致性

1、一致性又可以分为强一致性与弱一致性。

2、强一致性可以理解为在任意时刻，所有节点中的数据是一样的。同一时间点，你在节点A中获取到key1的值与在节点B中获取到key1的值应该都是一样的。

3、弱一致性包含很多种不同的实现，目前分布式系统中广泛实现的是最终一致性。

4、所谓最终一致性，就是不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。也可以简单的理解为在一段时间后，节点间的数据会最终达到一致状态。

BASE原则发展自CAP定理，舍弃了系统的强一致性而选择AP，但每个应用可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。用较通俗的话来描述就是 : “过程宽松，结果严格，你的老板不关心过程，只看结果”。

 

在我原来所做系统中，要根据不同维度记录用户的账本，如根据用户名、银行卡号记录月账、年账。由于数据量大，需对记账数据进行分库分表，一致性的问题就产生了（数据库分表分库以后就会产生一致性问题）。

创建一张重试表，在记账操作重试过若干次（3次）还不成功的情况下，给运营人员发送短信，由人为介入的方式进行相应的调账。至此，可保证记账操作的最终一致性。

 

如何实现分布式系统的最终一致性？

在大型分布式企业级应用中，分布式最终一致性方案需要根据系统自身特点量身定制，是系统设计的重点。

大部分业务流程都需要跨多微服务的调用来协作完成，并且要求系统确保分布式最终一致性。

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

1、基于XA协议的两阶段提交(2PC)方案（两阶段提交协议，三阶段提交协议）

2、基于支付宝最早提出