Redis集群架构及原理

Redis集群架构及原理

• 主从架构
• 哨兵架构
• 集群架构(Redis Cluster)

主从架构

描述

一个主节点多个从节点，主节点向客户端提供读写命令的处理操作，从节点备份主节点数据，提高Redis的容错能力，当主节点挂了，可以从从节点中选取一个作为主节点继续处理客户端的读写操作。主从架构也可以实现读写分离，从节点可以处理一些客户端的读操作，减轻主节点的压力。

工作原理

1，从节点启动之后会与主节点建立socket长连接，然后向主节点发送psync指令

2，主节点收到从节点的psync指令之后，会执行BGsave命令生成新的rbd持久化文件，在生成过程中处理的客户端写操作命令会放在repl缓冲区。

3，主节点将生成的rbd文件放松给从节点，从节点清空老数据，加载新的rbd文件

4，主节点将生成的repl缓冲区的指令发送给从节点，从节点将执行该命令，将数据写入到内从

5，主节点通过socket长连接把修改命令发送给从节点，保证主从一致

断点续传

当从节点与主节点的长连接断开之后恢复连接，redis支持仅部分数据复制。主要依靠主从节点维护的与数据同步的偏移量。

1，从节点重新与主节点建立socket长连接

2，从节点向主节点发送psync命令，并携带同步的偏移量。

3，主节点收到命令之后，会根据偏移量将断掉的连接之后的操作指令批量的发送给从节点

异常情况

当主节点切换或从节点给到的偏移量太旧，会触发全量数据的复制

如果有很多从节点，为了缓解主从复制风暴(多个从节点同时复制主节点导致主节点压力过大)，可以做如下架构，让部分从节点与从节点(与主节点同步)同步数据

Redis哨兵架构

主要解决主从架构下，当主从角色调整时，需手动的维护配置文件，不方便应对线上紧急情况。

sentinel节点主要用来监控主从集群的节点状态，不对客户端提供读写服务。客户端第一次与服务端建立连接后会从哨兵节点中获取主从架构的主节点，后面进行读写操作会访问从哨兵节点获取到的主节点，如果主节点挂了，那哨兵会选举出新的主节点，并将主节点的信息告诉客户端。

对于整个哨兵架构而言，依然只有一个主节点对处理客户端的写请求，无法横向扩展，会有性能瓶颈，如当请求量超过单机处理的阈值时缓存中数据量太大时，生成rbd或aof重写时间会特别长。

集群架构（Redis Cluster）

Redis集群架构是由多个主从集群节点集群组成的分布式服务集群，它具有复制，高可用和分片机制。不需要哨兵节点也能完成节点移除和故障转移功能。其性能高于主从架构和哨兵架构。

集群架构分片原理

Redis Cluster 将整个集群划分为16384个槽位，每个节点负责一部分槽位，并将槽位信息存储在每个节点中。 当客户端与Redis Cluster 建立连接之后，客户端会收到Redis Cluster发过来的槽位信息，并缓存在本地。客户端发送读写命令之前会根据key进行槽位定位算法找到对应集群节点。

跳转重定位

当Redis Cluster的某个节点收到一个不属于自己负责的槽位命令时，会向该客户端发送一段特殊的跳转指令并携带正确的节点信息，客户端收到之后会向正确的节点发送消息，并同同步正确的槽位映射表更新本地缓存。

集群选举流程

1，主节点变为FAIL状态之后，集群中的其他节点会感知到

2，当从节点发现于自己的主节点网络连接断开之后，将自己记录的集群选取周期（currentEpoch）值加1，并向Redis Cluster其他节点广播FAILOVER_AUTH_REQUEST 信息

3，Redis Cluster其他节点收到该信息之后，Master会对判断该信息的合法性（判断该从节点的Master节点是否为FIAL状态），如果合法会发送FAILOVER_AUTH_ACK。对同一选举周期的FAILOVER_AUTH_REQUEST只会响应一次ACK。（当一个主节点收到同一个主从架构节点的多个从节点发送过来的FAILOVER_AUTH_REQUEST如果currentEpoch相同，只会响应一次，通常响应收到第一个请求的从节点）。

4，从节点收到超过半数的Master响应的ACK之后会成为新的主节点，并广播信息通知其他Redis Cluster节点。（这也是为什么Redis Cluster至少要有三个主节点的原因，）

注意：从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举，而是有一定延迟，一定的延迟确保我们等待FAIL状态在集群中传播，slave如果立即尝试选举，其它masters或许尚未意识到FAIL状态，可能会拒绝投票

集群脑裂数据丢失问题

产生原因

主节点与集群中的其他节点网络不通，但仍然可以为客户端提供服务，该主从架构中新的主节点选取之后，会出现多个主节点对客户端提供服务，因与其它节点网络不通导致集群内部数据不一致。等原来的主节点与其他节点通信恢复之后，该主节点会变为集群中的一个从节点，同步新的主节点的数据之后，会丢失掉新的主节点中没有的那一部分数据

规避方法

min‐replicas‐to‐write 1 //写数据成功最少同步的slave数量，这个数量可以模仿大于半数机制配置，比如 集群总共三个节点可以配置1，加上leader就是2，超过了半数