其理论依据就是CAP原理。在分布式系统中，同时满足CAP定律中的一致性 Consistency、可用性 Availability和分区容错性 Partition Tolerance三者是不可能的。在绝大多数的场景，为了可用性和分区容错性，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证最终一致性。
CAP理解：
-
Consistency：一致性就是在客户端任何时候看到各节点的数据都是一致的。
-
Availability：可用性就是在任何时刻都可以提供读写。
-
Partition Tolerance：分区容错性是在网络故障、某些节点不能通信的时候系统仍能继续工作。
具体地讲在分布式系统中，在任何数据库设计中，一个Web应用最多只能同时支持上面的两个属性。显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。
- AP（高可用&&分区容错）:
允许至少一个节点更新状态会导致数据不一致，即丧失了C性质（一致性）。会导致全局的数据不一致。
- CP（一致&&分区容错）:
为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质（可用性）。分区同步会导致同步时间无限延长（也就是等数据同步完成之后才能正常访问）
- CA（一致&&高可用）:
两个节点可以互相通信，才能既保证C（一致性）又保证A（可用性），这又会导致丧失P性质（分区容错性）。这样的话就分布式节点受阻，无法部署子节点,放弃了分布式系统的可扩展性。因为分布式系统与单机系统不同，它涉及到多节点间的通讯和交互，节点间的分区故障是必然发生的，所以在分布式系统中分区容错性是必须要考虑的。
分布式事务服务
分布式事务服务（Distributed Transaction Service，DTS）是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。
CAP理论告诉我们在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的，所以我们只能在一致性和可用性之间进行权衡。
为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。
[](
)追问1：怎么理解强一致性、弱一致性和最终一致性？
强一致性：当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。
弱一致性：系统并不保证后续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。
最终一致性：弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。
最终一致性是指系统中所有的副本经过一段时间的异步同步之后，最终能够达到一个一致性的状态，也就是说在数据的一致性上存在一个短暂的延迟。
几乎所有的互联网系统采用的都是终一致性，只有在实在无法使用终一致性，才使用强一致性或事务，比如，对于决定系统运行的敏感数据，需要考虑采用强一致性，对于与钱有关的支付系统或金融系统的数据，需要考虑采用事务。
也就是说能够使用最终一致性的业务就尽量使用最终一致性，因为强一致性会降低系统的可用性。
课间休息，又来秀一下来自咱们群里同学的搬砖工地，坐标：杭州 西湖。
作者：Anchor
[](
)面试题2：了解base理论么？
==============================================================================
在分布式系统中，我们往往追求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢？前人已经给我们提出来了另外一个理论，就是base理论，它是用来对CAP定理进行进一步扩充的。base理论指的是：
-
Basically Available（基本可用）
-
Soft state（软状态）
-
Eventually consistent（最终一致性）
base理论是对CAP中的一致性和可用性进行一个权衡的结果，是对互联网大规模分布式系统的实践总结，强调可用性。
理论的核心思想就是：基本可用（Basically Available）和最终一致性（Eventually consistent）。虽然无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
[](
)追问1：基于base理论，举几个实际的例子
我们以12306订票系统为例
- 流量削峰
可以在不同的时间，出售不同区域的票，将访问请求错开，削弱请求峰值。比如，在春运期间，深圳出发的火车票在 8 点开售，北京出发的火车票在 9 点开售。
- 延迟响应
在春运期间，自己提交的购票请求，往往会在队列中排队等待处理，可能几分钟或十几分钟后，系统才开始处理，然后响应处理结果。
- 体验降级
比如用小图片来替代原始图片，通过降低图片的清晰度和 大小，提升系统的处理能力。
- 过载保护
比如把接收到的请求放在指定的队列中排队处理，如果请求等 待时间超时了（假设是 100ms），这个时候直接拒绝超时请求；再比如队列满了之后，就 清除队列中一定数量的排队请求，保护系统不过载，实现系统的基本可用。
课间休息，又来秀一下来自咱们群里同学的搬砖工地，坐标：武汉。
[](
)作者：北海
[](
)面试题3：实现分布式事务一致性（Consistency）的方法有哪些?
