分布式系统中三个重要角色：N（Network网络）、P（Process进程）、C（Clock时钟）
乱序、丢失、网络延迟
进程暂定，如gc等
计算机本地时间坑会突然向前或向后跳跃
定义： 在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时， 只能保证 一致性Consistency、可用性Availability、分区容错性PartitionTolerance 三者中的两个，另外一个必须被牺牲
对所有客户端来说，客户端读操作保证能够返回最新的写操作结果
非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）
当出现网络分区后，系统能够继续”履行职责”
CAP关注的是数据或某个功能，而非整个系统，正常网络情况下，需要考虑CA，发生网络分区时，只是暂时优先选择 AP 或者 CP ，网络分区恢复后通过其他补偿措施恢复 CA
必须选择P的理由：
分布式环境中，必须要选择P要素（分区容忍），因为网络本身无法做到100%可靠，所以分区必定会出现。
如果选择CA放弃P，当发生分区时，要满足C一致性，则需要禁止写入返回ERROR（如果不禁止写入则分区后不能进行数据同步无法保证一致性），
禁止写入返回ERROR又违背了A可用性，所以P必须要选择
1) CP
当发生网络分区时，需要保证C一致性，那么就需要只让1个分区正常执行，其他分区禁止写入（返回ERROR）,
违背了A可用性，所以只能CP
2) AP
当发生网络分区时，需要保证A可用性，那么就要所有分区都正常执行，由于分区之间网络不通，满足不了一致性，
所以只能AP
是对 CAP 理论中对 AP 方案的一个补充，在发生网络分区期间，暂时舍弃一致性C，待分区恢复后系统应该达到最终一致性
允许损失部分可用功能，保证核心功能可用，例如订单服务出现问题，但商品服务依然正常
允许不同节点的数据不一致存在数据延时，即存在中间状态（软状态，硬状态指的是强一致性），指的是CAP中的数据不一致
不可能一直是软状态，数据会最终保持一致
Paxos：
被认为是分布式共识算法的根本，其他都是其变种，但是 Paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 Paxos 具有很高的工程复杂度（如多点可写，允许日志空洞等）
Zab：
被应用在 Zookeeper 中，业界使用广泛，但没有抽象成通用的 library
Raft：
以容易理解著称，业界也涌现出很多 Raft 实现，比如大名鼎鼎的 etcd, braft, tikv 等