【转】微服务架构下的数据一致性保证（一）

今天分享第一篇，主要内容包括：

 

1.传统使用本地事务和分布式事务保证一致性。

2.传统分布式事务不是微服务中一致性的最佳选择。

3.微服务架构中应知足数据最终一致性原则。

4.微服务架构实现最终一致性的三种模式。

5.对帐是最后的终极防线。

1、传统使用本地事务和分布式事务保证一致性

 

传统单机应用通常都会使用一个关系型数据库，好处是应用可使用 ACID transactions。为保证一致性咱们只须要：开始一个事务，改变（插入，删除，更新）不少行，而后提交事务（若是有异常时回滚事务）。更进一步，借助开发平台中的数据访问技术和框架（如Spring），咱们须要作的事情更少，只须要关注数据自己的改变。

 

随着组织规模不断扩大，业务量不断增加，单机应用和数据库已经不足以支持庞大的业务量和数据量，这个时候须要对应用和数据库进行拆分，就出现了一个应用须要同时访问两个或两个以上的数据库状况。开始咱们用分布式事务来保证一致性，也就是咱们常说的两阶段提交协议（2PC）。

 

本地事务和分布式事务如今已经很是成熟，相关介绍很丰富，此处很少做讨论。

 

2、传统分布式事务不是微服务中一致性的最佳选择

 

首先，对于微服务架构来讲，数据访问变得更加复杂，这是由于数据都是微服务私有的，惟一可访问的方式就是经过API。这种打包数据访问方式使得微服务之间松耦合，而且彼此之间独立很是容易进行性能扩展。

其次，不一样的微服务常用不一样的数据库。应用会产生各类不一样类型的数据，关系型数据库并不必定是最佳选择。

 

例如，某个产生和查询字符串的应用采用Elasticsearch的字符搜索引擎；某个产生社交图片数据的应用能够采用图数据库，例如，Neo4j；

基于微服务的应用通常都使用SQL和NoSQL结合的模式。可是这些非关系型数据大多数并不支持2PC。

可见在微服务架构中已经不能选择分布式事务了。

 

3、微服务架构中应知足数据最终一致性原则 

依据CAP理论，必须在可用性（availability）和一致性（consistency）之间作出选择。若是选择提供一致性须要付出在知足一致性以前阻塞其余并发访问的代价。这可能持续一个不肯定的时间，尤为是在系统已经表现出高延迟时或者网络故障致使失去链接时。

 

依据目前的成功经验，可用性通常是更好的选择，可是在服务和数据库之间维护数据一致性是很是根本的需求，微服务架构中选择知足最终一致性。

固然选择了最终一致性，就要保证到最终的这段时间要在用户可接受的范围以内。

 

那么咱们怎么实现最终一致性呢？

 

4、微服务架构实现最终一致性的三种模式

 

从一致性的本质来看，是要保证在一个业务逻辑中包含的服务要么都成功，要么都失败。那咱们怎么选择方向呢？保证成功仍是保证失败呢？

咱们说业务模式决定了咱们的选择。实现最终一致性有三种模式：可靠事件模式、业务补偿模式、TCC模式。

 

1) 可靠事件模式

可靠事件模式属于事件驱动架构，当某件重要事情发生时，例如更新一个业务实体，微服务会向消息代理发布一个事件。消息代理会向订阅事件的微服务推送事件，当订阅这些事件的微服务接收此事件时，就能够完成本身的业务，也可能会引起更多的事件发布。

1. 如订单服务建立一个待支付的订单，发布一个“建立订单”的事件。

 

2.支付服务消费“建立订单”事件，支付完成后发布一个“支付完成”事件。

3.订单服务消费“支付完成”事件，订单状态更新为待出库。

从而就实现了完成的业务流程。

这个过程可能致使出现不一致的地方在于：某个微服务在更新了业务实体后发布事件却失败；虽然微服务发布事件成功，可是消息代理未能正确推送事件到订阅的微服务；接受事件的微服务重复消费了事件。

 

可靠事件模式在于保证可靠事件投递和避免重复消费，

可靠事件投递定义为:

（a）每一个服务原子性的业务操做和发布事件

（b）消息代理确保事件传递至少一次。 

避免重复消费要求服务实现幂等性，如支付服务不能由于重复收到事件而屡次支付。

 

2) 补偿模式

为了描述方便，这里先定义两个概念：

业务异常：业务逻辑产生错误的状况，好比帐户余额不足、商品库存不足等。

技术异常：非业务逻辑产生的异常，如网络链接异常、网络超时等。

补偿模式使用一个额外的协调服务来协调各个须要保证一致性的微服务，协调服务按顺序调用各个微服务，若是某个微服务调用异常（包括业务异常和技术异常）就取消以前全部已经调用成功的微服务。

 

补偿模式建议仅用于不能避免出现业务异常的状况，若是有可能应该优化业务模式，以免要求补偿事务。如帐户余额不足的业务异常可经过预先冻结金额的方式避免，商品库存不足可要求商家准备额外的库存等。

咱们经过一个实例来讲明补偿模式，一家旅行公司提供预订行程的业务，能够经过公司的网站提早预订飞机票、火车票、酒店等。

 

假设一位客户规划的行程是，（1）上海-北京6月19日9点的某某航班，（2）某某酒店住宿3晚，（3）北京-上海6月22日17点火车。在客户提交行程后，旅行公司的预订行程业务按顺序串行的调用航班预订服务、酒店预订服务、火车预订服务。最后的火车预订服务成功后整个预订业务才算完成。

若是火车票预订服务没有调用成功，那么以前预订的航班、酒店都得取消。取消以前预订的酒店、航班即为补偿过程。

 

须要注意的是酒店的取消预订、航班的取消预订一样不能保证必定成功，因此补偿过程每每也一样须要实现最终一致性，须要保证取消服务至少被调用一次和取消服务必须实现幂等性。

 

咱们应该尽量经过设计避免采用补偿方式，好比上面的例子中，在预订火车票失败的时候能够提示客户更改其余的时间。

 

 3) TCC模式（Try-Confirm-Cancel）

 

一个完整的TCC业务由一个主业务服务和若干个从业务服务组成，主业务服务发起并完成整个业务活动，TCC模式要求从服务提供三个接口：Try、Confirm、Cancel。

例如从服务有2个：

1) Try：完成全部业务检查

预留必须业务资源

 

2) Confirm：真正执行业务

不做任何业务检查

只使用Try阶段预留的业务资源

Confirm操做知足幂等性

 

3) Cancel：

释放Try阶段预留的业务资源

Cancel操做知足幂等性

整个TCC业务分红两个阶段完成。

第一阶段：主业务服务分别调用全部从业务的try操做，并在活动管理器中登记全部从业务服务。当全部从业务服务的try操做都调用成功或者某个从业务服务的try操做失败，进入第二阶段。

第二阶段：活动管理器根据第一阶段的执行结果来执行confirm或cancel操做。若是第一阶段全部try操做都成功，则活动管理器调用全部从业务活动的confirm操做。不然调用全部从业务服务的cancel操做。

须要注意的是第二阶段confirm或cancel操做自己也是知足最终一致性的过程，在调用confirm或cancel的时候也可能由于某种缘由（好比网络）致使调用失败，因此须要活动管理支持重试的能力，同时这也就要求confirm和cancel操做具备幂等性。

 

5、对帐是最后的终极防线

若是有些业务因为瞬时的网络故障或调用超时等问题，经过上文所讲的3种模式通常都能获得很好的解决。可是在当今云计算环境下，不少服务是依赖于外部系统的可用性状况，在一些重要的业务场景下还须要周期性的对帐来保证真实的一致性。好比支付系统和银行之间天天日终是都会有对帐过程。

转：https://mp.weixin.qq.com/s?__biz=MzI5MDEzMzg5Nw==&mid=2660392782&idx=1&sn=d28e43bf6f7cf140eed9fffcf2f29e86&scene=1&srcid=0811qaoc12E47x6vDVNkynBO#rd