CAP 原理

CAP是分布式存储的理论基石， 一致性(C) 、 可用性(A)、 分区容忍性(P); 分布式的节点往往都是分布在不同的机器上，这意味着必然会有网络断开的风险，这个场景叫做网络分区。

在网络分区发生时，两个分布式节点之间无法进行通信，我们对一个节点进行的修改操作将无法同步到另外一个节点，所以数据的「一致性」将无法满足，因为两个分布式节点的数据不再保持一致。除非我们牺牲「可用性」，也就是暂停分布式节点服务，在网络分区发生时，不再提供修改数据的功能，直到网络状况完全恢复正常再继续对外提供服务。

一句话概括 CAP 原理就是——网络分区发生时，一致性和可用性两难全。

redis的主从同步是异步的，所以redis的分布式系统并不满足一致性，即使主从网络出现了问题，主节点依旧可以对外提供服务，所以redis的分布式系统是满足了 AP； 当从节点网络恢复后，会努力追赶主节点，最终会和主节点的状态一致，所以redis采用的是最终一致性。

主从同步

redis同步的是指令流，主节点会把那些对自己状态有变更的指令集了在本地的buffer中，异步同步到从节点，这个过程就是增量同步；

如果因为网络状况不好，从节点在短时间内无法和主节点进行同步，当网络恢复后就需要同步主节点的快照进行redis的状态恢复。

当新的从节点添加到集群时，它需要先进行一次快照同步，同步完成后再继续进行增量同步。

Sentinel

当在主从模式下的redis主节点出现故障的时候，需要人工手动去做主从切换，并且需要通知所有的应用程序把地址统一改成新的主节点地址，这样的流程效率太低，所以redis提供了sentinel模式。

可以简单的把sentinel集群看作是zk集群，他负责监控主从节点的状态，如果主节点出现了故障，sentinel会自动的主从切换，客户端连接集群的时候，先去连接sentinel，然后在询问sentinel来查询主节点的地址，然后再去连接主节点进行数据交互。当主节点发生故障的时候，客户端会重新去询问sentinel新的主节点地址，应用程序自动完成主节点地址的变更。

Redis Cluster

这是redis官方提供的集群方案，Redis Cluster 将所有数据划分为 16384 的 slots， 每个节点负责其中一部分槽位。槽位的信息存储于每个节点中，当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息。这样当客户端要查找某个 key 时，可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不 一致的情况，还需要纠正机制来实现槽位信息的校验调整

槽位定位算法

Cluster 默认会对 key 值使用 crc32 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位。当客户端向一个错误的节点发送了指令，该节点会发现指令的 key 所在的槽位并不归自己管理，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连这个节点去获取数据。

GET x
-MOVED 3999 127.0.0.1:6381

MOVED 指令的第一个参数 3999 是 key 对应的槽位编号，后面是目标节点地址。MOVED 指令前面有一个减号，表示该指令是一个错误消息。客户端收到 MOVED 指令后，要立即纠正本地的槽位映射表。后续所有 key 将使用新的槽位映射表。

原文链接: http://herman7z.site