redis集群

主从同步

• 当主节点挂掉之后，从节点过来接管。

CAP原理：当网络分区发生时，一致性与可用性两难全

• 一致性、可用性、分区容忍性
• 网络分区：分布式系统的节点发生网络断开的情况

最终一致

• redis主从数据是异步同步的，并不满足一致性，但满足可用性，即使网络分区，主节点也会支持修改。redis保证最终一致性，即从节点会努力追赶主节点，使数据保持一致。

主从同步与从从同步

• 从从同步是为了减轻主节点的压力。

增量同步

• redis的同步是指令流，主节点会把对自己状态产生影响的指令记录到本地的内存buffer里面，然后异步的同步到从节点。但因为复制内存buffer是一个定长的环形数组，所以网络分区时间过长会发生覆盖。

快照同步

• 非常消耗资源，快照同步是将主节点内存里的数据快照到磁盘上，然后将内容传送到从节点，从节点进行全量加载，然后通知主节点继续增量同步。但会发生死循环，即快照同步的过程中又发生了buffer覆盖，所以需要设定一个合适的buffer大小参数。

增加从节点

• 必须先进行一次快照同步，再进行增量同步。

无盘复制

• 因快照同步会严重影响系统的负载与主节点的服务效率，所以无盘复制出现了，即主节点直接通过套接字将快照内容发送到从节点，主节点一边遍历内存一边将序列化的内容发送到从节点。

wait指令

• redis的复制是异步的，wait指令可以让异步复制变成同步复制，即wait到从节点同步完成才返回成功。

Sentinel

• Sentinel负责监控主从节点的健康，当主节点挂掉时，会自动选择一个最优的从节点切换成为主节点。

消息丢失

• 异步复制，代表着如果主机点挂掉，从节点可能没有接受到全部的同步消息，会产生消息丢失，Sentinel可以限制主从延迟过大。

基本用法

• 客户端通过Sentinel发现主从节点地止，然后通过这些地址建立连接

Codis

• Codis是redis的集群方案之一
• Codis上挂接着所有的redis实例构成一个集群，当集群空间不足时，可以动态增加redis实例实现扩容
• 我们可以启动多个Codis实例，单个Codis能支撑的QPS十分有限。
• 因Codis不是redis亲儿子，对原理暂不深究。

Cluster

• redis cluster是去中心化的，由三个节点组成，每个节点负责集群的一部分数据。
• redis cluster将所有数据划分为16384个槽位，每个节点负责其中的一部分槽位，当客户端连接集群的时候，会得到一份集群的槽位信息，以便于查找某个key。

槽位定位算法

默认对key使用crc16算法进行hash，将得到的整数对16384进行取模获得具体槽位。也可以强制将key挂在某个特定槽位上。

跳转

当客户端向一个错误节点发送指令的时候，该节点发现该槽位不归自己管，会反馈给客户端，客户端修改槽位表，然后跳转到其他节点。

迁移

• redis的迁移单位是槽，一个一个的进行迁移，redis-trib会将源节点与目标节点设置好中间状态，一次性获取源节点所有key，然后一个一个迁移。大致流程是：从源节点获取内容->存到目标节点->从源节点删除。
• 注意：迁移过程是同步的，源节点的主线程会处于阻塞状态，，直至key被删除。
• 迁移过程中，如果key很小，不会影响客户端使用，如果key很大，会导致redis集群卡顿。
• 迁移过程中，客户端对数据的访问：客户端首先访问源节点，如果不存在，源节点会反馈给客户端，客户端会重定向到目标节点，客户端收到后，先向目标节点发送一个ASKING指令，这一步主要是为了防止目标节点不认该槽位是自己的，反馈跳转到源节点，从而形成死循环。

容错

• 可以为每个主节点设置多个从节点，如果某个主节点没有从节点，然后主节点发生故障，集群将处于不可用状态，redis也可以设置允许部分节点发生故障。

网络抖动

• redis cluster提供了一个选项cluster-node-timeout，表明当某个节点持续timeout时间失联才判定出现故障，防止频繁的主从切换。还有另一个系数放大这个超时时间。

可能下线与确定下线

• redis集群节点广播对某个节点失联的状态信息，然后得到大多数节点认可后，才确定标记该节点为确定下线。，并广播整个集群。

Cluster用法

槽位迁移感知

• 更新客户端的槽位与节点的映射表
• MOVED指令：纠正槽位
• ASKING指令：临时纠正槽位，防止形成重定向循环。

集群变更感知

• 目标节点挂掉，抛出异常，客户端随机挑选一个节点重试，然后通过MOVED被告知新的节点地址
• 运维修改了集群地址，，客户端会抛错，然后清空槽位映射表，，等下一个指令过来，会尝试重新初始化节点。