Base理论及其一致性模型

对于CAP来说，放弃强一致性，追求分区容错性和可用性，这是很多分布式系统设计时的选择。在工程实际中，基于CAP定理逐步演化，就提出了Base理论。

1 .Base 理论

Base 是三个短语的简写，即基本可用（Basically Available）、软状态（Soft State） 和最终一致性（Eventually Consistent）
Base 理论的核心思想是最终一致性，即使无法做法强一致性，但每个应用都可以根据自身的业务特点采用适当的方法来使系统达到最终一致性。

1） 基本可用
就是不追求CAP中的【任何时候，读写都是成功的】，而是系统能够基本运行，一直提供服务。基本可用强调了分布式系统在出现不可预知的故障的时候，允许损失部分可用性，相比正常系统，可能响应时间延长，或者服务被降级。
比如：在双十一秒杀活动中，如果抢购人数太多超过了系统的QPS峰值，可能会排队或者提示限流，这就是通过合理的手段保护系统的稳定性，保证主要的服务正常，保证基本可用。
2） 软状态
软状态可以对应ACID事务中的原子性，在ACID的事务中，实现的是强一致性，要么全做要么全不做，所有用户看到的数据一致。其中原子性要求多个节点的数据副本都是一致的，强调数据一致性。
原子性可以理解为一种“硬状态”，软状态则是允许系统中的数据存在中间状态。并认为该状态不影响系统的整体可用性，即允许系统存在多个不同节点的数据副本存在数据延迟。
3） 最终一致性
数据不可能一直是软状态，必须在一个时间期限之后达到各个节点的一致性，在期限过后，应当保证所有的副本数据保持一致性，也就是达到数据的最终一致性。
在系统设计中，最终一致性实现的时间取决于网络延时，系统负载、不同的存储选型、不同的数据复制方案设计等因素。

2. 不同数据一致性模型

一般来说，数据一致性模型可以分为强一致性和弱一致性，强一致性也叫做线性一致性，除此之外，所有其他的一致性都是弱一致性的特殊情况。弱一致性根据不同的业务场景，又可以分解为更细分的模型，不同一致性模型又有不同的应用场景。
在互联网领域的绝大多数场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往值需要保证“最终一致性”，只要在这个最终时间是在用户可以接受范围内即可。
1） 强一致性
当数据更新完成之后，任何多个后续进程的访问都会返回最新的更新过的值，这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么，根据CAP理论，这种实现需要牺牲可用性。
2）弱一致性
系统在数据写入成功之后，不承诺立即可以读到最新写入的数据，也不会具体的承诺多久可以读到。用户读到某一操作对系统数据的更新需要一段时间，我们称这段时间为“不一致性窗口”。
3） 最终一致性
最终一致性是弱一致性的特例，强调的是所有的数据副本在经过一段时间的同步之后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
达到最终一致性的时间，就是不一致窗口时间，在没有故障发生的前提下，不一致性窗口的时间主要受通信延迟，系统负载和副本的个数影响。
最终一致性模型根据其提供的不同保证可以划分为更多的模型，包括因果一致性和会话一致性等。
因果一致性
因果一致性要求有因果关系的操作顺序得到保证，非因果关系的操作顺序无所谓。
比如：在微博或者微信进行评论的时候，比如你在朋友圈发了一张照片，朋友给你评论了，而你对朋友的评论进行了回复，这条朋友圈的显示中，你的回复必须在朋友之后，这是一个因果关系，而其他没有因果关系的数据，可以允许不一致。
会话一致性
会话一致性对系统数据的访问过程框定在了一个会话中，约定了系统能保证在同一个有效的会话中实现“读己之所写”的一致性，就是在你的一次访问中，执行更新操作之后，客户端能够在同一会话中始终读取到该数据项的最新值。
比如：分布式的Session 一致性问题，可以认为是会话一致性的一个应用。

3. CAP及Base的关系

Base 理论是在CAP上发展的，CAP理论描述了分布式系统中数据一致性、可用性、分区容错性之间的制约关系，当你选择了其中的两个时，就不得不对剩下的一个做一定程度的牺牲。
Base理论是对CAP理论的实际应用，也就是在分区和副本存在的前提下，通过一定的系统设计方案，放弃强一致性，实现基本可用，这是绝大部分分布式系统的选择。比如NoSQL系统、为服务架构。在这个前提下，如何把基本可用做到最好，就是分布式工程师追求的。
除了 CAP 和 Base，上面还提到了 ACID 原理，ACID 是一种强一致性模型，强调原子性、一致性、隔离性和持久性，主要用于在数据库实现中。Base 理论面向的是高可用、可扩展的分布式系统，ACID 适合传统金融等业务，在实际场景中，不同业务对数据的一致性要求不一样，ACID 和 Base 理论往往会结合使用。

4. 逻辑时钟

分布式解决了传统单体架构的单点问题和性能问题，另一方面也带来了很多新的问题，其中一个问题就是多节点的时间同步问题：不同机器上的物理时钟难以同步，导致无法区分在分布式中多个节点的事件时序。
比如：两台机同时发送消息，由于机器A上的时间要比机器B上的时间快，即使机器B后发送消息，最终看到的还是A上发送的消息是最新的，这样就有可能导致问题的出现。
于是就有人提出了逻辑时钟的概念。
1） 什么是逻辑时钟
逻辑时钟是为了区分现实中的物理时钟提出来的概念，一般情况下我们提到的时间都是指物理时间，但在实际很多应用中，只要所有的机器有相同的时间就够了，这个时间不一定要跟实际的时间相同。更进一步，如果两个节点之间不进行交互，那么它们的时间甚至都不需要同步。因此问题的关键点在于节点间的交互要在事件的发生顺序上达成一致，而不是对于时间达成一致。
2）可以对不同的节点的物理时钟做同步么？
方法是有的，NTP就是常用的时间同步算法。比如

/usr/sbin/ntpdate 10.8.1.2 10.8.1.3 10.8.1.4

通过上面的命令可以同步三台机的时间，但是这样也不是完全没有误差，这种误差在某些场景下（金融分布式事务）是不能接受的。
因此，Lamport提出逻辑时钟就是为了解决分布式系统中的时序问题，即如何定义a在b之前发生。值得注意的是，并不是说分布式系统只能用逻辑时钟来解决这个问题，如果以后有某种技术能够让不同节点的时钟完全保持一致，那么使用物理时钟来区分先后是一个更简单有效的方式。
参考资料：不同数据一致性模型有哪些应用？
这里关于逻辑时钟的原理就不详细介绍了，后面会补充上。