微服务架构服务注册中心的数据一致性问题

Posted 2021-04-14 架构设计模式

微服务架构服务注册中心的数据一致性涉及的理论是CAP理论。CAP（Consistency，Availability，Partition Tolerance）理论，是由Eric Brewer教授提出并由Seth Gilbert 和 Nancy Lynch两人证明了其正确性的一套分布式理论。该理论阐述了一个分布式系统的三个主要方面，分别是数据一致性（Consistency）、系统可用性（Availability）和分区容忍性（Partition Tolerance），如图1所示。数据一致性是指分布式环境下，多个节点的数据是否强一致；系统可用性是指分布式服务能一直保持可用状态，当用户发出一个请求后，服务能在有限时间内返回结果；而分区容忍性特指对网络分区的容忍性，其中，分区容忍性又是不可或缺的。CAP 理论说明，在分布式系统中，一致性、可用性和分区容忍性3个要素最多只能同时满足两个，三者不可兼得。

图1  CAP的三个要素图

CAP理论包含3个内容，分别是一致性、可用性和分隔容忍。一致性模型可以分成以下三类：第一强一致性，数据更新成功后，任意时刻所有副本中的数据都是一致的，一般采用同步的方式实现；第二弱一致性，数据更新成功后，系统不承诺立即可以读到最新写入的值，也不承诺具体多久之后可以读到；第三最终一致性，弱一致性的一种形式，数据更新成功后，系统不承诺立即可以返回最新写入的值，但是保证最终会返回上一次更新操作的值。分布式系统数据的强一致性、弱一致性和最终一致性可以通过Quorum NRW 算法分析来实现。这三者的相互渗透融合，可形成图2的交叉内容。

                            

图2 CAP相互交叉的三种组合图

交叉内容可以形成3种组合，分别是CA 组合（Consistency高一致性 + Availability高可用性）、CP组合（Consistency高一致性 + Partition tolerance分区容错性）和AP组合（Availability高可用性 + Partition tolerance分区容错性）。其中CA组合可以通过2PC 两阶段事务提交来保证。其缺点无法实现分区容错性，一旦某个操作失败，整个系统就出错，这种组合一般应用在传统的关系数据库，如Oracle数据库等。CP使用Paxos算法来保证，可用性降低，其应用有HBase、MongoDB数据库等。AP使用Gossip算法等实现最终一致性，其应用有Cassandra、Dynamo等。

下面通过几个实际软件平台来进行说明。

① ZooKeeper框架采用CP组合

ZooKeeper框架是采用CP组合策略模式，即Consistency高一致性 + Partition tolerance分区容错性。也就是说，服务注册功能对一致性的要求要高于可用性。ZooKeeper框架采用的是 Paxos算法。

这主要是针对ZooKeeper集群会出现的一种特殊场景，当ZooKeeper集群的master节点因异常原因与其他节点失去联系时，剩余节点会重新进行Leader选举。可是选举Leader的时间太长，一般需要30 ~ 120s，且选举期间整个ZooKeeper集群都是不可用的，这就导致在选举期间注册服务瘫痪。而这种情况在应用环境中是经常性概率事件，虽然服务能够最终恢复，但较长的选举时间会导致ZooKeeper集群的服务长期处于不可用状态。

② Eureka框架采用AP组合

Eureka框架是采用AP组合策略模式，即Availability高可用性 + Partition Tolerance分区容错性。也就是说，框架对可用性的要求要高于一致性。

Eureka框架提供了一个弱一致的服务视图，使用尽力而为的复制策略，在设计时优先保证可用性。Eureka框架各个节点都是平等的，部分节点挂掉后剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka框架注册时或如果发现连接失败时，则会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务可用，这实际上就是高可用性，也许检索到的信息可能不是最新的，即不能保证强一致性。因此，Eureka框架可以很好地应对异常原因导致部分节点失去联系的情况，而不会像ZooKeeper框架那样使整个注册服务瘫痪。

③ Consul框架采用CA组合

Consul框架采用CA组合策略模式，即Consistency高一致性 + Availability高可用性。也就是说，高可用性和高一致性。

Consul框架能提供较高的可用性，使用Raft算法，通过k/vStore服务来保证一致性。同时Consul框架也提供强大的一致性保证，因为服务器使用Raft协议复制状态。客户端节点参与健康检查，该检查分发健康检查工作，发现请求被路由到选举出来的领事来进行领导，这使他们默认情况下强烈一致。Consul框架强烈的一致性意味着它可以作为领导选举和集群协调而锁定服务。Consul框架强一致性带来的是服务注册相比会稍慢一些。因为Consul框架的Raft协议要求必须过半数的节点都写入成功才认为注册成功，Leader挂掉时，重新选举期间整个Consul不可用。故Consul框架保证了强一致性却牺牲了可用性。