在线文档是一个数据一致性要求很强的项目，我们经常会提到一个在线文档的技术：“协同冲突处理算法——OT”。这是协同编辑处理的核心。因为它保障了在多客户端同时提交修改的情况下的数据一致性，用通俗一点的方式描述：多人在线编辑，每个人提交的内容不一样，但通过协同冲突算法，最终都能看到一样的内容。
但在这里我们不想深入去探讨协同编辑冲突算法的具体内容，对这块有兴趣的朋友可以参考之前我们团队的博客，已经有过很多介绍。本文主要是介绍协同冲突算法产生的原因，以及它背后关于数据一致性的问题。
CAP 理论
CAP 理论是分布式算法里面非常非常重要的一个概念，几乎所有的分布式系统都在应用这一理论。如果我们将在线文档的客户端看作是分布式系统中的节点，那么协同编辑算法就是用于处理分布式系统中数据一致性问题。
CAP 理论这么重要，那么它究竟指的是什么呢？C、A、P 每一个字母都代表了一个非常重要的概念
C Consistensy，一致性
A availability，可用性
P Partition Tolerance，分区容忍性
而 CAP 最重要的概念是分布式系统中，CAP 三个条件中，最多只能同时满足两个
这是为什么呢？而且光从概念上，很难去理解这句话。这里我们挑一个例子来看：
假设在分布式系统中存在 100 个节点，但由于故障，使得网络发生了分区，其中有一半的节点无法向另外一半节点通信，于是系统被分割为 A 区与 B 区。
那么在网络分区的情况下，客户端发送请求尝试来对 A 区一个节点进行数据写入，由于 AB 区网络不通，这时候无法同步写入信息给到 B 区节点。
在这种场景下，究竟允不允许当前客户端进行数据写入呢？请思考一下。
1、如果允许客户端数据写入，那么当前节点的可用性得到了保证，但是由于网络分区，所以网络不可触达，数据无法同步。因此此时是无法满足一致性，也就是分布式系统中，同时访问两个节点，可能会返回不同数据。
2、如果不允许客户端数据写入，那么当前节点的一致性得到了保证，所有节点数据都是一致的。但是由于数据都无法写入，这时系统显然是 “不可用” 的，也就是可用性无法满足
这就是常见的 CP 与 AP 的组合。但为什么没有提到 CA 的组合呢？为什么假设都是在允许网络分区的情况下呢？答案是这里的场景是分布式系统，如果不允许存在网络分区，那么显然每次写入数据都可以进行同步，自然一致性和可用性显然得到了保障。但这也不是分布式系统了。
BASE 理论
但将这个理论放在协同场景下，好像又不适用了？假设在网络差的情况下，两个客户端同时提交，虽然暂时一致性无法满足，本地客户端会看到不同的内容，但网络恢复后，通过协同冲突算法数据也能保持一致，这不是既满足了一致性又满足了可用性吗？
这个是对的，只是这里的一致性不等于 CAP 理论的一致性，CAP 理论是假设在没有网络延迟的情况下的强一致性，也就是数据时刻都是一致的。而协同编辑的场景，我们需要了解另外的概念：BASE
既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
BA：Basically Avaliable（基本可用）
S: Soft State（软状态）
E: Eventually consistency（最终一致性）
BASE 的核心思想：在不满足强一致性的情况下，也可以通过其他手段来达到最终一致性。
1、基本可用
允许损失部分可用性，允许牺牲响应时间、降级系统功能等操作
2、软状态
允许存在数据中间状态，不要求强一致性，并不影响整体可用性，允许副本之间的数据同步延迟。
3、最终一致性
所有的副本，在最终都能达到数据一致的状态，但不要求实时的强一致性。
最终一致性又会有许多划分：读写一致性、写读一致性、单调读一致性、单调写一致性等。
在 BASE 理论中，我们可以看到协同编辑文档的场景中，虽然 CAP 的强一致性无法满足，但通过损失部分可用性，允许暂时的客户端不一致情况，通过协同编辑冲突算法，可以解决数据不一致问题，达到了最终的数据一致性。
总结
通过协同编辑算法来解决数据冲突问题，其实属于共识过程，而对于共识，有兴趣的读者可以进一步了解 Paxos、Raft、ZAB 等共识算法。了解 Paxos 是如何解决分布式系统中多节点的编号和数据同步问题、Raft 如何通过 Leader 选举等操作来降低 Paxos 两段 RPC 调用产生的延迟、Zookeeper 的 ZAB 算法又是如何解决分布式系统中的问题的。
最后，感谢大家等阅读，分布式系统中的概念确实是属于比较复杂而且解释繁多的一部分，如有错误，欢迎斧正。
