分布式数据库数据一致性的原理、与技术实现方案

背景

可用性（Availability）和一致性（Consistency）是分布式系统的基本问题，先有著名的CAP理论定义过分布式环境下二者不可兼得的关系，又有神秘的Paxos协议号称是史上最简单的分布式系统一致性算法并获得图灵奖，再有开源产品ZooKeeper实现的ZAB协议号称超越Paxos。

在大数据场景下，分布式数据库的数据一致性管理是其最重要的内核技术之一，也是保证分布式数据库满足数据库最基本的ACID特性中的 “一致性”(Consistency)的保障，在分布式技术发展下，数据一致性的解决方法和技术也在不断的演进。

分布式系统的挑战

一致性可理解为所有节点都能访问到最新版本的数据，这在单机场景下非常容易实现，使用共享内存和锁即可解决，但数据存储在单机会有两个限制：

1）单机不可 用系统整体将不可用；

2）系统吞吐量受限于单机的计算能力。

消除这两个限制的方法是用多机来存储数据的多个副本，负责更新的客户端会同时更新数据的多个副 本，于是问题就来了，多机之间的网络可能无法连接，当负责更新的客户端无法同时到连接多个机器时，如何能保证所有客户端都能读到最新版本的数据？

CAP理论

CAP理论由加州大学伯克利分校的计算机教授Eric Brewer在2000年提出，其核心思想是任何基于网络的数据共享系统最多只能满足数据一致性(Consistency)、可用性 (Availability)和网络分区容忍(Partition Tolerance)三个特性中的两个，三个特性的定义如下：

1.数据一致性：等同于所有节点拥有数据的最新版本

2.可用性：数据具备高可用性

3.分区容忍：容忍网络出现分区，分区之间网络不可达

在大规模的分布式环境下，网络分区是必须容忍的现实，于是只能在可用性和一致性两者间做出选择，CAP理论似乎给分布式系统定义了一个悲观的结局，一时间 大家都按照CAP理论在对热门的分布式系统进行判定，譬如认为HBase是一个CP系统，Cassandra是AP系统，我个人认为这是不严谨的，理由是 CAP理论是对分布式系统中一个数据无法同时达到可用性和一致性的断言，而一个系统中往往存在很多类型的数据，部分数据（譬如银行账户中的余额）是需要强 一致性的，而另外一部分数据（譬如银行的总客户数）并不要求强一致性，所以拿CAP理论来划分整个系统是不严谨的， CAP理论带来的价值是指引我们在设计分布式系统时需要区分各种数据的特点，并仔细考虑在小概率的网络分区发生时究竟为该数据选择可用性还是一致性。

分布式数据一致性

1.数据一致性是什么

大部份使用传统关系型数据库的DBA在看到“数据一致性”时，第一反应可能都是数据在跨表事务中的数据一致性场景。但是本文介绍的“数据一致性”，指的是“数据在多份副本中存储时，如何保障数据的一致性”场景。

由于在大数据领域，数据的安全不再由硬件来保证，而是通过软件手段，通过同时将数据写入到多个副本中，来确保数据的安全。数据库在同时向多个副本写入记录时，如何确保每个副本数据一致，称为“数据一致性”。

2.关系型数据库如何保障数据一致性

传统的关系型数据库在大数据的场景，对于运行环境–硬件要求都比较高，例如Oracle会建议用户使用小型机+共享存储作为数据库的运行环境，DB2 DPF也同样建议用户采用更好的服务器+高端存储来搭建数据库的运行环境。

所以在数据存储安全的技术要求下，传统关系型数据库在大数据场景更多是依赖硬件的技术来保障数据的安全性。

因为关系型数据库的数据安全是基于硬件来保障，并且数据也不会通过同时存储多份来保障数据的安全，所以关系型数据库的用户默认认为数据存储是一致的。

3.分布式存储如何保障数据一致性

本文在讨论分布式存储时，主要指的是大数据产品中的分布式文件系统和分布式数据库，例如：HDFS。

用户在搞明白分布式存储的数据一致性原理时，必须要先明白为什么他们就需要数据一致性，和分布式存储的数据存储与关系型数据库的数据存储又有什么区别。

大数据技术的诞生，确确实实让系统的性能有新的突破，并且支持硬件以水平扩展的方式来获得线性增长的性能和存储。

这些都是过去传统关系型数据库所无法提供的。另外，大数据技术也抛弃了运行环境必须足够好的硬性要求，而是允许用户通过批量廉价X86服务器+本地磁盘的方式搭建规模集群，从而获得比过去依赖硬件垂直扩展所提供的更强的计算能力和更多的存储空间。

大数据技术的核心思想就是分布式，将一个大的工作任务分解成多个小任务，然后通过分布式并发操作的方式将其完成，从而提高整个系统的计算效率或者是存储能力。而在分布式环境下，由于硬件的要求降低，必然需要大数据产品提供另外一个重要的功能–数据安全。

大数据产品在解决数据安全的方式上，都比较接近，简单来说，就是让一份数据通过异步或者同步的方式保存在多台机器上，从而保障数据的安全。

分布式存储在解决数据安全的技术难点后，又引入了一个新的技术问题，就是如何保障多个副本中的数据一致性。目前SequoiaDB是使用Raft算法来保证数据在多个副本中一致性。

Raft算法

1.Raft算法背景

在分布式环境下，最著名的一致性算法应该是Paxos算法，但是由于它实在过于晦涩难懂，并且实现起来极度困难，所以在2013年，Diego Ongaro、John Ousterhout两个人以易懂(Understandability)为目标设计了一套一致性算法Raft。Raft算法最大的特点在于简单易懂，并且实现起来简单

2.Raft算法概述

与Paxos不同，Raft强调的是易懂，Raft和Paxos一样只要保证n/2+1节点正常就能够提供服务。

众所周知当问题较为复杂时可以把问题分解为几个小问题来处理，Raft也使用了分而治之的思想。Raft算法重点解决三个子问题：

1）选举(Leader election)

2）日志复制(Log replication)

3）安全性(Safety)。

Raft算法强化了Leader节点的功能，Follower节点的数据只能够从Leader中获取，所以Follower节点的实现就变得简单，只要负责和Leader保持通信，并且接受Leader推送的数据即可。

3.Raft算法原理

节点角色

Raft算法中，对节点的状态分为3种角色:

1)分别是Leader(领导者)

2)Follower(追随者)

3)Candidate(候选者)

Leader，负责处理来自客户端的请求，负责将日志同步到Follower中，并且保证与Follower之间的heartBeat联系;

Follower，当集群刚刚启动时，所有节点均为Follower状态，它的工作主要为响应Leader的日志同步请求，响应Candidate的请求，以及把请求到Follower的事务请求转发给Leader;

Candidate，选举Leader时负责投票，选举出来Leader后，节点将从Candidate状态变为Leader状态。

Terms

在分布式环境下，“时间同步”一直都是老大难的技术难题。Raft为了解决这个问题，将时间划分为一个一个的Term(可以理解为“逻辑时间”)来处理在不同时间段里的数据一致性。

4.日志复制

日志复制主要的作用就是用来保证节点的数据一致性与高可用性。

当Leader被选举出来后，所有的事务操作都必须要经过Leader处理。这些事务操作成功后，将会被按顺序写入到LOG中，每个LOG都包含一个index编号。

5. 安全性

安全性是用于确保每个节点都是按照相同的日志序列进行执行的安全机制。

分布式数据库数据一致性技术实现

以国产原厂的分布式数据库SequoiaDB为例，SequoiaDB在多副本的部署中，采用Raft算法保证数据在多副本环境中保持一致。

SequoiaDB集群中，总共包含3中角色节点，分别是

1）协调节点

2）编目节点

3）数据节点

由于协调节点本身不存任何数据，所以只有编目节点和数据节点存在事务操作，换言之，编目分区组和数据分区组的副本同步采用Raft算法保证数据一致性。

1.编目节点和数据节点的事务日志介绍

编目节点和数据节点由于都是需要存储数据的，并且在集群部署中该，为了确保数据的安全，都是建议采用分布式的方式进行部署，所以在数据同步中，需要采用Raft算法的基本原理进行数据同步。

编目节点和数据节点在存储数据时，共包含两大部分：

1）一个真实的数据文件

2）另一个是事务日志文件

SequoiaDB的节点事务日志，默认情况下由20个64MB(总大小为1.25GB)的文件构成。节点的事务日志主要包含一个index编号和数据操作内容，index编号保持永远递增状态。

另外，SequoiaDB节点的事务日志不会永久保存，而是当所有的事务日志写满后，再重新从第一个文件开始进行覆盖写入。

2.编目分区组的数据一致性

由于编目分区组是保存SequoiaDB集群的元信息，数据同步要求高，所以编目分区组的数据一致性要求为强一致性，即每次向编目分区组执行事务操作时，必须要确保所有的编目节点操作成功，才计算该操作执行成功，否则该事务操作将在整个编目分区组中回退事务日志，以保证分区组内的数据一致性。

3.数据分区组的数据一致性

数据分区组的数据一致性默认情况下为最终一致性性，即只要求主节点执行事务操作成功即视为操作成功，主节点将在未来异步同步ReplicaLOG到从节点上。

4.主从节点的事务日志同步

SequoiaDB的主从节点是通过事务日志同步来保证数据一致性的，并且主从节点的事务日志同步是单线程完成。

如果当主节点和从节点的LSN差距为一条记录，则主节点会主动将最新的事务日志推送给从节点。

如果主节点和从节点的LSN差距超过一条记录，则从节点会主动向主节点请求同步事务日志，主节点收到同步请求后，会将从节点的LSN号到主节点最新的LSN号对应的事务日志打包一次性发送给从节点。

5.从节点日志重放

当从节点获取到主节点推送过来的事务日志后，就会自动解析事务日志和重放。从节点在重放事务日志时，默认情况下会以10并发来重放事务日志。

从节点在执行并发重放日志时有条件限制，即在集合的唯一索引个数<=1的情况下，INSERT、DELETE、UPDATE、LOB WRITE、LOBUPDATE、LOB REMOVE操作可以支持并发重放事务日志。

从节点在做并发重放时，是通过记录的OID进行打散并发执行，这样就可以保证对相同记录的操作不会由于并发重放导致数据不一致。

总结

分布式的数据库，通过Raft算法来确保在分布式情况上数据的一致性，并且编目分区组和数据分区组对数据一致性要求又有所不同，编目分区组始终要求的是数据在多副本请情况下数据强一致性，而数据分区组则可以由用户在创建集合时来执行数据一致性的强度，强度越高，数据安全性越好，但是执行的效率就会相对较差，反之依然。

 

--------------------------------------------------------------------------------

CAP 理论

CAP 理论的诞生

在分布式系统的发展中，影响最大最广泛的莫过于 CAP 理论了，可以说 CAP 理论是分布式系统发展的理论基石。早在 1998 年，加州大学的计算机科学家 Eric Brewer ，就提出分布式系统的三个指标。在此基础上，2 年后，Eric Brewer 进一步提出了 CAP 猜想。又过了 2 年，到了 2002 年，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP 猜想。CAP 猜想成为了 CAP 定理，也称为布鲁尔定理。从此，CAP 定理成为分布式系统发展的理论基石，广泛而深远的影响着分布式系统的发展。

CAP 理论指标

CAP 理论，简单的说就是分布式系统不可能同时满足 Consistency 一致性、Availability 可用性、Partition Tolerance 分区容错性三个要素。因为 Consistency、Availability 、Partition Tolerance 这三个单词的首字母分别是 C、A、P，所以这个结论被称为 CAP 理论。

Consistency 一致性

CAP 理论的第一个要素是 Consistency 一致性。一致性的英文含义是指“all nodes see the same data at the same time”。即所有节点在任意时间，被访问返回的数据完全一致。CAP 作者 Brewer 的另外一种解释是在写操作之后的读指令，必须得到的是写操作写入的值，或者写操作之后新更新的值。从服务端的视角来看，就是在 Client 写入一个更新后，Server 端如何同步这个新值到整个系统，从而保证整个系统的这个数据都相同。而从客户端的视角来看，则是并发访问时，在变更数据后，如何获取到最新值。

Availability 可用性

CAP 理论的第二个要素是 Availability 可用性。可用性的英文含义是指“Reads and writes always succeed”。即服务集群总能够对用户的请求给予响应。Brewer 的另外一个种解释是对于一个没有宕机或异常的节点，总能响应用户的请求。也就是说当用户访问一个正常工作的节点时，系统保证该节点必须给用户一个响应，可以是正确的响应，也可以是一个老的甚至错误的响应，但是不能没有响应。从服务端的视角来看，就是服务节点总能响应用户请求，不会吞噬、阻塞请求。而从客户端视角来看，发出的请求总有响应，不会出现整个服务集群无法连接、超时、无响应的情况。

Partition Tolerance 分区容错性

第三个要素是 Partition Tolerance 分区容错性。分区容错的英文含义是指“The system continues to operate despite arbitrary message loss or failure of part of the system”。即出现分区故障或分区间通信异常时，系统仍然要对外提供服务。在分布式环境，每个服务节点都不是可靠的，不同服务节点之间的通信有可能出现问题。当某些节点出现异常，或者某些节点与其他节点之间的通信出现异常时，整个系统就产生了分区问题。从服务端的视角来看，出现节点故障、网络异常时，服务集群仍然能对外提供稳定服务，就是具有较好的分区容错性。从客户端视角来看，就是服务端的各种故障对自己透明。

正常服务场景

如图所示，网络上有 2 个服务节点 Node1 和 Node2，它们之间通过网络连通组成一个分布式系统。在正常工作的业务场景，Node1 和 Node2 始终正常运行，且网络一直良好连通。

假设某初始时刻，两个节点中的数据相同，都是 V0，用户访问 Nodel 和 Node2 都会立即得到 V0 的响应。当用户向 Node1 更新数据，将 V0 修改为 V1时，分布式系统会构建一个数据同步操作 M，将 V1 同步给 Node2，由于 Node1 和 Node2 都正常工作，且相互之间通信良好，Node2 中的 V0 也会被修改为 V1。此时，用户分别请求 Node1 和 Node2，得到的都是 V1，数据保持一致性，且总可以都得到响应。

网络异常场景

作为一个分布式系统，总是有多个分布的、需要网络连接的节点，节点越多、网络连接越复杂，节点故障、网络异常的情况出现的概率就会越大。要完全满足 CAP 三个元素。就意味着，如果节点之间出现了网络异常时，需要支持网络异常，即支持分区容错性，同时分布式系统还需要满足一致性和可用性。我们接下来看是否可行。

现在继续假设，初始时刻，Node1 和 Node2 的数据都是 V0，然后此时 Node1 和 Node2 之间的网络断开。用户向 Node1 发起变更请求，将 V0 变更为 V1，分布式系统准备发起同步操作 M，但由于 Node1 和 Node2 之间网络断开，同步操作 M 无法及时同步到 Node2，所以 Node2 中的数据仍然是 V0。

此时，有用户向 Node2 发起请求，由于 Node2 与 Node1 断开连接，数据没有同步，Node2 无法立即向用户返回正确的结果 V1。那怎么办呢？有两种方案。

第一种方案，是牺牲一致性，Node2 向请求用户返回老数据 V0 的响应。

第二种方案，是牺牲可用性，Node2 持续阻塞请求，直到 Node1 和 Node2 之间的网络连接恢复，并且数据更新操作 M 在 Node2 上执行完毕，Node2 再给用户返回正确的 V1 操作。

至此，简要证明过程完毕。整个分析过程也就说明了，分布式系统满足分区容错性时，就无法同时满足一致性和可用性，只能二选一，也就进一步证明了分布式系统无法同时满足一致性、可用性、分区容错性这三个要素。

CAP 权衡

在通常的分布式系统中，为了保证数据的高可用，通常会将数据保留多个副本（Replica），网络分区是既成的现实，于是只能在可用性和一致性两者间做出选择。CAP 理论关注的是在绝对情况下，在工程上，可用性和一致性并不是完全对立的，我们关注的往往是如何在保持相对一致性的前提下，提高系统的可用性。

• CA 架构：不支持分区容错，只支持一致性和可用性。

不支持分区容错性，也就意味着不允许分区异常，设备、网络永远处于理想的可用状态，从而让整个分布式系统满足一致性和可用性。

但由于分布式系统是由众多节点通过网络通信连接构建的，设备故障、网络异常是客观存在的，而且分布的节点越多，范围越广，出现故障和异常的概率也越大，因此，对于分布式系统而言，分区容错 P 是无法避免的，如果避免了 P，只能把分布式系统回退到单机单实例系统。

• CP 架构：因为分区容错 P 客观存在，即相当于放弃系统的可用性，换取一致性。

系统在遇到分区异常时，会持续阻塞整个服务，直到分区问题解决，才恢复对外服务，这样可以保证数据的一致性。选择 CP 的业务场景比较多，特别是对数据一致性特别敏感的业务最为普遍。比如在支付交易领域，Hbase 等分布式数据库领域，都要优先保证数据的一致性，在出现网络异常时，系统就会暂停服务处理。分布式系统中，用来分发及订阅元数据的 Zookeeper，也是选择优先保证 CP 的。因为数据的一致性是这些系统的基本要求，否则，银行系统 余额大量取现，数据库系统访问，随机返回新老数据都会引发一系列的严重问题。

• AP 架构：由于分区容错 P 客观存在，即相当于放弃系统数据的一致性，换取可用性。

在系统遇到分区异常时，节点之间无法通信，数据处于不一致的状态，为了保证可用性，服务节点在收到用户请求后立即响应，那只能返回各自新老不同的数据。这种舍弃一致性，而保证系统在分区异常下的可用性，在互联网系统中非常常见。比如微博多地部署，如果不同区域的网络中断，区域内的用户仍然发微博、相互评论和点赞，但暂时无法看到其他区域用户发布的新微博和互动状态。对于微信朋友圈也是类似。还有如 12306 的火车购票系统，在节假日高峰期抢票时，偶尔也会遇到，反复看到某车次有余票，但每次真正点击购买时，却提示说没有余票。这样，虽然很小一部分功能受限，但系统整体服务稳定，影响非常有限，相比 CP，用户体验会更佳。

CAP 问题及误区

CAP 理论极大的促进了分布式系统的发展，但随着分布式系统的演进，大家发现，其实 CAP 经典理论其实过于理想化，存在不少问题和误区。

首先，以互联网场景为例，大中型互联网系统，主机数量众多，而且多区域部署，每个区域有多个 IDC。节点故障、网络异常，出现分区问题很常见，要保证用户体验，理论上必须保证服务的可用性，选择 AP，暂时牺牲数据的一致性，这是最佳的选择。

但是，当分区异常发生时，如果系统设计的不够良好，并不能简单的选择可用性或者一致性。例如，当分区发生时，如果一个区域的系统必须要访问另外一个区域的依赖子服务，才可以正常提供服务，而此时网络异常，无法访问异地的依赖子服务，这样就会导致服务的不可用，无法支持可用性。同时，对于数据的一致性，由于网络异常，无法保证数据的一致性，各区域数据暂时处于不一致的状态。在网络恢复后，由于待同步的数据众多且复杂，很容易出现不一致的问题，同时某些业务操作可能跟执行顺序有关，即便全部数据在不同区域间完成同步，但由于执行顺序不同，导致最后结果也会不一致。长期多次分区异常后，会累积导致大量的数据不一致，从而持续影响用户体验。

其次，在分布式系统中，分区问题肯定会发生，但却很少发生，或者说相对于稳定工作的时间，会很短且很小概率。当不存在分区时，不应该只选择 C 或者 A，而是可以同时提供一致性和可用性。

再次，同一个系统内，不同业务，同一个业务处理的不同阶段，在分区发生时，选择一致性和可用性的策略可能都不同。比如前面讲的 12306 购票系统，车次查询功能会选择 AP，购票功能在查询阶段也选择 AP，但购票功能在支付阶段，则会选择 CP。因此，在系统架构或功能设计时，并不能简单选择 AP 或者 CP。

而且，系统实际运行中，对于 CAP 理论中的每个元素，实际并不都是非黑即白的。比如一致性，有强一致性，也有弱一致性，即便暂时大量数据不一致，在经历一段时间后，不一致数据会减少，不一致率会降低。又如可用性，系统可能会出现部分功能异常，其他功能正常，或者压力过大，只能支持部分用户的请求的情况。甚至分区也可以有一系列中间状态，区域网络完全中断的情况较少，但网络通信条件却可以在 0~100% 之间连续变化，而且系统内不同业务、不同功能、不同组件对分区还可以有不同的认知和设置。

最后，CAP 经典理论，没有考虑实际业务中网络延迟问题，延迟自始到终都存在，甚至分区异常P都可以看作一种延迟，而且这种延迟可以是任意时间，1 秒、1 分钟、1 小时、1 天都有可能，此时系统架构和功能设计时就要考虑，如何进行定义区分及如何应对。

基于 ZooKeeper 的服务发现（CP）

流程分析

1、服务平台管理端先在 ZooKeeper 中创建一个服务根路径，可以根据接口名命名（例如： /dubbo/com.foo.BarService），在这个路径再创建服务提供方目录与服务调用方目录（例如：providers、consumers），分别用来存储服务提供方的节点信息和服务调用方的节点信息。

2、当服务提供方发起注册时，会在服务提供方目录中创建一个临时节点，节点中存储该服务提供方的注册信息。

创建临时节点是因为临时节点的生命周期与客户端会话相关，所以一旦提供者所在的机器出现故障导致提供者无法提供服务，该临时节点就会自动从 Zookeeper 删除。

3、当服务调用方发起订阅时，则在服务调用方目录中创建一个临时节点，节点中存储该服务调用方的信息，同时服务调用方 watch 该服务的服务提供方目录 （/dubbo/com.foo.BarService/providers）中所有的服务节点数据。

4、当服务提供方目录下有节点数据发生变更时，ZooKeeper 就会通知给发起订阅的服务调用方。

存在的问题

问题一：

ZooKeeper 的一大特点就是强一致性，ZooKeeper 集群的每个节点的数据每次发生更新操作，都会通知其它 ZooKeeper 节点同时执行更新。

当连接到 ZooKeeper 的节点数量特别多，对 ZooKeeper 读写特别频繁，且 ZooKeeper 存储的目录达到一定数量的时候，ZooKeeper 将不再稳定，CPU 持续升高，最终宕机。而宕机之后，由于各业务的节点还在持续发送读写请求，刚一启动，ZooKeeper 就因无法承受瞬间的读写压力，马上宕机。

问题二：

ZooKeeper 无法正确处理服务发现的网络分区。在 ZooKeeper 中，无法达到仲裁数量的分区的节点客户端完全无法与ZooKeeper 及其服务发现机制进行通信。

基于 Eureka 的服务发现（AP）

流程分析

1、Eureka-Client 在初始化时会将服务实例信息注册到任意一个 Eureka-Server，并且每隔 30 秒发送心跳请求。

2、该 Eureka-Server 会将注册、心跳的请求，批量打包同步到其他 Eureka-Server。

存在的问题

问题一：

订阅端拿到的是服务的全量的地址：这个对于客户端的内存是一个比较大的消耗，特别在多数据中心部署的情况下，某个数据中心的订阅端往往只需要同数据中心的服务提供端即可。

问题二：

客户端采用周期性向服务端主动 pull 服务数据的模式（也就是客户端轮训的方式），这个方式存在实时性不足以及无谓的拉取性能消耗的问题。

问题三：

Eureka 集群的多副本的一致性协议采用类似“异步多写”的 AP 协议，每一个 server 都会把本地接收到的写请求发送给组成集群的其他所有的机器（Eureka 称之为 peer），特别是 hearbeat 报文是周期性持续不断的在 client->server->all peers 之间传送；这样的一致性算法，导致了如下问题

• 每一台Server都需要存储全量的服务数据，Server 的内存明显会成为瓶颈。
• 当订阅者却来越多的时候，需要扩容 Eureka 集群来提高读的能力，但是扩容的同时会导致每台 server 需要承担更多的写请求，扩容的效果不明显。
• 组成 Eureka 集群的所有 server 都需要采用相同的物理配置，并且只能通过不断的提高配置来容纳更多的服务数据。

扩展：Eureka 2.0

Eureka 2.0主要就是为了解决上述问题而提出的，主要包含了如下的改进和增强：

• 数据推送从 pull 走向 push 模式，并且实现更小粒度的服务地址按需订阅的功能。
• 读写分离：写集群相对稳定，无需经常扩容；读集群可以按需扩容以提高数据推送能力。
• 新增审计日志的功能和功能更丰富的 Dashboard。

阿里 Nacos

与 Eureka 1.x 对比增强的地方如下：

• 去除了基于客户端的同步模式，采用了批量的基于长连接级别的数据同步+周期性的 renew 的方案来保证数据的一致性；
• 客户端通过订阅感兴趣的服务信息，服务端只会"推送"客户端感兴趣的少量数据给客户端。
• 集群拆分成 session 和 data 两个集群，客户端分片的把服务数据注册到 session 集群中，session 集群会把数据异步的写到 data 集群，data 集群完成服务数据的聚合后，把压缩好的服务数据推送到 session 层缓存下来，客户端可以直接从session 层订阅到所需要的服务数据。

注：Nacos 服务信息"推送"本质还是拉模式，具体流程为：

1、Nacos 客户端会循环请求服务端变更的数据，并且超时时间设置为 30s，当配置发生变化时，请求的响应会立即返回；

2、服务端数据变更后，找到具体的客户端请求中的 response，然后直接将结果写入 response 中；

3、Nacos 客户端就能够实时感知到服务端配置发生了变化。

总结

对于服务发现而言，拥有可能包含虚假信息的信息要比根本不拥有任何信息更好，所以个人认为 AP 优于 CP。

在 AP 模式下，如果请求到不准确的服务实例信息，导致请求发送到一个宕机的服务端，只要做好失败重试机制和负载均衡，这次请求能够顺利的进行。