CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合，对于一个分布式系统来说，当设计读写操作时，只能满足 CP 或者 AP
分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。 为啥呢？ 举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了
选择 CP 还是 AP 的关键在于当前的业务场景，没有定论，比如对于需要确保强一致性的场景如银行一般会选择保证 CP
另外，需要补充说明的一点是： 如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C 和 A 能够同时保证
ZK 就是著名的 CP 架构，它的 ZAB 协议可以保证系统强一致性
当 ZK 集群中存在 Leader 时，自动进入消息广播模式，流程如下：
客户端发起一个写操作请求，从机收到请求后会将该请求发给主机
Leader 服务器将求转化为事务提案，同时为每个提案分配一个全局的 ID，Leader 服务器为每个 Followe 服务器分配一个单独的队列，然后将需要广播的提案依次放到队列中，并且根据 FIFO 策略进行消息发送
Follower 接收到提案后，会首先将其以事务日志的方式写入本地磁盘中，写入成功后 Leader 反馈一个响应消息
Leader 接收到超过半数以上 Follower 的成功响应消息后，即认为消息发送成功，发送提交消息，自身也会完成事务提交
Leader 服务器与每一个 Follower 服务器之间都维护了一个单独的 FIFO 消息队列进行收发消息，使用队列消息可以保证数据传输的顺序性。请求处理的顺序不同就会导致数据的不同，从而产生数据不一致问题
BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写
BASE 理论的核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性，这样就可以保持系统整体“主要可用”
redis 使用集群分摊压力、实现扩容，获得更多的内存空间，并且保证了一定的高可用性
采用无中心化集群（每个redis都有从机，与其他redis可以相互通信，每个redis都可以被访问），而数据的分配一般使用数据分片来实现（并非哈希一致性算法实现，虽然这两者几乎差不多）
所谓数据分片，就是一个有16384个slot（槽），数据库中的每个键都能通过算法（使用公式 CRC16(key) % 16384来计算）算出需要操作的数据属于这16384个哈希槽的哪一个
而集群中的每个节点负责处理一部分哈希槽，这些节点又叫redis分片，比如：
而如果想要添加或者删除节点的话，将其他节点的槽放入或者增加就行了，槽中的数据也会一并转移
Redis分片之间通过Gossip协议进行通讯，Gossip协议简单点说是一种弱最终一致性算法，主要用于解决大规模去中心化 P2P 网络中的数据一致性问题
该协议发送数据只干两件事：
1，随机选择 N 个尚未发送过消息的邻接节点发送消息
2，收到信息的节点等待一段时间，再重复上述步骤