CAP
- 一致性（Consistency）：在分布式系统中的所有数据副本，在同一时刻是否都是同样的。
- 可用性（Availability）：在系统的主体部分出现故障的时候，系统是否仍然保持响应。
- 分区容错（Partition）：系统是否能够在网络分区的情况下继续运行。
在CAP定理中，Raft和ZooKeeper都是选取了"CP"的方式。这表示他们在面临网络分区（Partition tolerance）的情况下，会选择保证数据一致性（Consistency）而牺牲部分可用性（Availability）。
- Raft：Raft是一个用于管理复制日志的一致性算法，广泛应用于分布式系统中，比如etcd。在出现网络分区时，Raft会通过选举机制确保系统的数据一致性，但在选举期间，部分节点可能无法提供服务，因此牺牲了可用性。
- ZooKeeper：ZooKeeper是一个开源的分布式应用程序协调服务，它是集群的管理者，监视所有节点的状态根据节点提交的报告对集群进行重新组织。ZooKeeper也同样选择了在网络分区时保证数据的一致性，其通过Zab协议实现数据的一致性，但在部分节点失去联系时，这部分节点无法提供服务，因此也牺牲了可用性。
缓存雪崩
缓存雪崩是指在同一时刻大量的缓存数据同时失效，导致大量的请求直接落到数据库上
缓存穿透
缓存穿透是指查询的数据既不存在于缓存中也不存在于数据库中，导致每次请求都要去数据库去查询，从而导致不必要的性能损耗
缓存击穿
缓存击穿是指一个存在的数据，在缓存过期的一刹那，同时有大量的请求，这些请求会穿透缓存直接请求数据库，导致数据库压力过大
二段式提交
二段提交（Two-Phase Commit, 2PC）是一个在分布式系统中达成一致性的重要算法，它是一种原子提交协议。 它主要分为两个阶段：
- 准备阶段：这是第一阶段，称为“投票”阶段。在这个阶段，事务协调器（coordinator）询问所有的事务参与者（participant）是否准备好提交事务。事务协调器向所有参与者发送prepare请求，如果所有参与者都响应"Yes"（准备好提交），则进入下一个阶段；如果有任何一个参与者响应"No"（未准备好提交），则事务协调器会中止事务。
- 提交阶段：这是第二阶段，称为“提交”阶段。如果所有参与者都已准备好提交，事务协ordinator会向所有参与者发送commit请求，要求他们提交事务；如果有任何一个参与者响应了"No"，则事务协调器会向所有参与者发送abort请求，要求他们回滚事务。
二段提交协议是一个同步阻塞型的协议，所有参与者在等待其他参与者响应的时候都会被阻塞。这使得二段提交协议在性能上不是非常理想。此外，它也存在单点故障问题。如果协调器在二阶段提交过程中出现故障，那么参与者可能会一直阻塞下去。
三段式提交
三阶段提交有两个改动点
- 引入超时机制。同时在协调者和参与者中都引入超时机制；
- 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
CanCommit阶段
事务询问：协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应
响应反馈：参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No
PreCommit阶段
- 事务预提交：参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
- 响应反馈：如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令!
DoCommit阶段
该阶段进行真正的事务提交，也可以分为以下两种情况。
执行提交
发送提交请求 协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。
- 事务提交：参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
- 响应反馈：事务提交完之后，向协调者发送Ack响应。
- 完成事务：协调者接收到所有参与者的ack响应之后，完成事务。
中断事务
协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。
- 发送中断请求：协调者向所有参与者发送abort请求
- 事务回滚：参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
- 反馈结果：参与者完成事务回滚之后，向协调者发送ACK消息
- 中断事务：协调者接收到参与者反馈的ACK消息之后，执行事务的中断
