一、请简述 CAP 原理

C：Consistency

即一致性，访问所有的节点得到的数据应该是一样的。注意，这里的一致性指的是强一致性，也就是数据更新完，访问任何节点看到的数据完全一致，要和弱一致性，最终一致性区分开来。

A：Availability

即可用性，所有的节点都保持高可用性。注意，这里的高可用还包括不能出现延迟，比如如果节点B由于等待数据同步而阻塞请求，那么节点B就不满足高可用性。也就是说，任何没有发生故障的服务必须在有限的时间内返回合理的结果集。

P：Partiton tolerance

即分区容忍性，这里的分区是指网络意义上的分区。由于网络是不可靠的，所有节点之间很可能出现无法通讯的情况，在节点不能通信时，要保证系统可以继续正常服务。



以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择

简单证明：

假设有节点data1和节点data2，一开始有个数据number=1。之后向data1提交更新，将数据number设置为2。接着data1就需要将更新推送给data2，让data2也更新number数据。

1. 在保证C和P的情况下



为了保证数据一致性，data1需要将数据复制给data2，即data1和data2需要进行通信。但是由于网络是不可靠的，我们系统有保证了分区容忍性，也就是说这个系统是可以容忍网络的不可靠的。这时候data2就不一定能及时的收到data1的数据复制消息，当有请求向data2访问number数据时，为了保证数据的一致性，data2只能阻塞等待数据真正同步完成后再返回，这时候就没办法保证高可用性了。所以，在保证C和P的情况下，是无法同时保证A的。

2. 在保证A和P的情况下



为了保证高可用性，data1和data2都有在有限时间内返回。同样由于网络的不可靠，在有限时间内，data2有可能还没收到data1发来的数据更新消息，这时候返回给客户端的可能是旧的数据，和访问data1的数据是不一致的，也就是违法了C。也就是说，在保证A和P的情况下，是无法同时保证C的。

3. 在保证A和C的情况下



如果要保证高可用和一致性，只有在网络情况良好且可靠的情况下才能实现。这样data1才能立即将更新消息发送给data2。但是我们都知道网络是不可靠的，是会存在丢包的情况的。所以要满足即时可靠更新，只有将data1和data2放到一个区内才可以，也就丧失了P这个保证。其实这时候整个系统也不能算是一个分布式系统了，所以分布式系统只需根据业务情况选择AP或者CP。

二、针对 Doris 案例，请用 UML 时序图描述 Doris 临时失效的处理过程（包括判断系统进入临时失效状态，临时失效中的读写过程，失效恢复过程）

失效状态



失效中



失效恢复过程



三、根据当周学习情况，完成一篇学习总结

本周主要学习了三个内容：

• 分布式关系型数据库和分布式NoSQL数据库的架构设计，以及如何通过ZooKeeper实现分布式管理的原理

• 搜索引擎的架构设计

• 通过Doris的实例介绍高可用和可伸缩如何设计

收获点：

• 分布式系统首先应该根据业务需求选择是AP还是CP，也就是CP还是AP。比如在政务信息化中，涉及行政许可发证、不动产转让等业务办理应该是采用CP，确保数据100%准确无歧义。但是内部通知，会议室管理，日常事务等可以采用AP，提高系统反应速度，实现最终一致即可。

• 在确保分布式的一致性问题时，目前最优的解决方案就是“民主集中”。选举一个Leader进行决策，“民主”投票，“集中”做决定，决定后大家认同。

• 使用事件溯源模式可以有效解决数据的一致性问题，比如MySQL的主从同步或主主同步中RelayLog，Doris的失效恢复等，都是采用这种模式。将操作过程进行记录，恢复或同步时只需要重放事件即可。