架构师训练营第 1 期 -Week6 - 课后练习

1.请简述 CAP 原理。



CAP 定理（CAP theorem） 又被称作布鲁尔定理（Brewer's theorem）。是加州大学伯克利分析的计算机科学家埃里克.布鲁尔（Eric Brewer）在2000年的ACM PODC上提测的一个猜想。CAP定理是分布式计算领域公认的一个定理。对应分布式系统（互联网系统应用）的架构来说，CAP是必须掌握的理论。



CAP定理是说：在一个分布式系统（指相互连接并共享数据的节点的集合）中，当设计读写操作时，只能保证一致性（Consistency）、可用性（Avalibility）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲掉。注意：牺牲掉并不等于什么都不做，需要为分区恢复后做准备。



• 一致性（Consistency）是说：每次读取的数据都应该是最近写入的数据或者返回一个错误，而不是过期数据。

• 可用性（Avalibility）是说：每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的。

• 分区容错性（Partition tolerance）是说：即使因为网络原因，部分服务器节点之间消息丢失或者网络延迟了，系统依然应该是可以操作的。



CAP定理是设计高可用的分布式系统的公认的定理，如果是单机的应用则谈不到CAP定理，因为数据都放在同一台服务器上，那么就没有分区，没有可用性，没有一致性。而要保证高可用，那么就要讲数据保存在多台服务器上，服务器之间进行数据共享（如mysql分片集群，如Redis的分片集群），正常运行情况下，不存在 CP 和 AP 的选择，可以同时满足 CA。因为要数据共享，所以就有了分区、就会有分区现象（数据同步延迟，网络故障，服务器故障等等），就要保证一致性或者可用性。



CAP 关注的粒度是数据，而不是整个系统。C 与 A 之间的取舍可以在同一系统内以非常细小的粒度反复发生，而每一次的决策可能因为具体的操作，乃至因为牵涉到特定的数据或用户而有所不同。要根据实际场景来决定是CP还是AP。



另外值得注意的是，CAP 是忽略网络延迟的。在分布式事务执行的过程中，系统其实是处于一个不一致状态的，不同的服务节点的数据并不完全一致，它们是最终一致的。



BASE是指基本可用（Basically Avaliable）、软状态（Soft State）、最终一致性（Eventual Consistency）。核心思想是即使无法做到强一致性（CAP的一致性），但是应用可以采用合适的方法达到最终一致性。



那么在出现故障的时候，如何保证可用性呢？如何保证实一致性？

一致性算法解决多个服务器之间，如何达成一致的，保证对外提供的是统一的决策，或者是一个数据状态。通常是采用投票的方式来实现。常用的分布式一致性算法有Paxos、Zab、Raft等协议。



2.针对 Doris 案例，请用 UML 时序图描述 Doris 临时失效的处理过程（包括判断系统进入临时失效状态，临时失效中的读写过程，失效恢复过程）。参考《海量分布式存储系统 Doris 的高可用架构设计分析.pdf》