Redis股-高可用架构（redis架构设计）

Redis主从架构：Redis主从包含了一个主节点和多个从节点。主节点负责接收写操作请求，从节点主要用于接收主节点数据的复制更新，并且可以处理部分读请求来分担主节点的压力。数据同步原理：Redis主从架构的同步是RDB文件的全量同步。当从节点启动时，会向主节点发送SYNC同步数据的请求命令。主节点收到命令后，执行BGSAVE命令生成RDB文件，在此期间请求到来的命令将会缓存到缓冲区，确保RDB同步完成后，此期间的命令也能同步给从节点。在第一次全量同步完成后，主从之间会维护一个复制偏移量，当从节点断开再次连接，先比较从节点发送的ID与自己的运行ID是否相同，以及偏移量差距是否较大，如果ID相同，且偏移量差距较小，则采用部分复制，避免全量复制带来的资源消耗。反之，如果ID或者偏移量差距较大，则需要进行全量复制。当从节点触发全量复制时，首先会删除自身所有现有数据（FLUSHALL等效操作），确保数据归零。适用场景：主从架构适用于读多写少的场景，数据备份。但是主节点故障需要手动维护，在高并发的场景下存在数据不一致的情况。

哨兵架构：哨兵是在主从的基础上，增加了一组哨兵节点，这些节点可以监控主从节点的运行状态。当主节点出现故障，哨兵节点会自动选举一个从节点作为新的主节点，并通知客户端和从节点新主节点的信息。监控分为4个阶段：1、监控阶段：哨兵节点会定期向主从节点发送PING命令检查网络是否可达，以及主从之间的复制偏移量差距是否过大，如果过大，则哨兵就会认为主从复制之间出现问题。2、主观下线判断阶段：当哨兵节点在规定时间内没有收到某个节点的有效响应，就会将该节点标记为“主观下线”，但这只是单个哨兵节点的判断，并不意味着这个Redis节点就不可用了，每个哨兵节点都可以独立的进行标记。3、客观下线判断阶段：当某个哨兵节点认为这个Redis节点主观下线后，会向其他哨兵节点确认对这个节点状态的判断。当有足够数量（通常是超过半数）的哨兵节点认为主节点主观下线时，哨兵节点就会达成共识，客观认为这个主节点故障了，需要重新从从节点中选举主节点。4、选举领导者阶段：当主节点被认为是客观下线后，哨兵节点会采用类似Raft算法，根据选举任期，运行ID等条件来推选。如果选举任期相同，那么ID最小的哨兵节点会当选，只有称为领导者的哨兵节点才会有权力选举主节点。需要注意的是，优先级为0的特殊，表示该哨兵永远不会被哨兵选择成为主节点。5、故障转移阶段：称为领导者的哨兵节点会根据从节点中的复制偏移量，以及运行ID进行比较。首先比较复制偏移量，复制偏移量大的会成为主节点。如果复制偏移量相同，运行ID小的会成为主节点。

补充说明：选举任期是哨兵在选举时都会为自己初始化一个选举任期（这是一个整数），且都会将自己的任期+1。然后每个哨兵节点都会向其他节点拉票。在哨兵节点成为领导者时，会更新自己的任期。保证选举朝着有序的方向进行。

Redis Cluster架构：Redis Cluster是一个分布式的Redis存储方案，每个主节点至少配置一个从节点。它将数据分布在不同的节点上，平衡数据压力。该架构采用哈希槽的方式来管理数据分布。整个集群共有16384个哈希槽，数据的Key通过CRC16算法计算后对16384进行取模，确定其所属的哈希槽。1、故障检测：节点之间通过Gossip协议交换信息，以此保证节点故障时，它负责的哈希槽可以被其他节点接管，保证数据的可用性。故障检测的触发是基于Gossip协议的心跳机制保证，当一个节点没有在一定时间内接收到另一个节点的心跳信息，他会将这个节点标记为疑似故障。2、故障确认：主节点被标记为疑似故障后，他的从节点会向其他主节点确认它的主节点是否故障。如果大多数主节点（超半数）都认为该节点不可达，这个节点就会被标记为故障状态，从而触发故障转移。3、从节点选举机制：其余主节点会根据从节点的复制偏移量以及运行ID选取主节点，从节点成为主节点之后，会向其他节点广播自己成为主节点的信息。其他节点收到消息后会更新自己的集群结构包括重新计算槽位分配。

Redis Cluster集群扩容原理：新节点加入集群后，集群会通过内部的通信机制Gossip协议来传播新节点的信息，然后集群会自动给新的节点分配哈希槽。然后开始迁移数据，需要注意的是数据不是一次性迁移完成，而是逐步迁移，避免迁移期间集群的不可用以及吞吐性能。

Redis Cluster哈希槽的概念：哈希槽主要用于解决数据倾斜问题。一致性哈希算法将所有节点和数据哈希值映射到一个环形结构上，称为哈希环。在存放数据时，首先计算哈希值，然后比较数据在环上的位置，然后从这个位置沿环顺时针分配。但是这种方案在节点较少时，数据可能集中在部分节点，导致负载不均衡；其次增加节点只对相邻的节点有分担压力的效果，并不会对整体性能有改进。于是针对这种情况，又有了虚拟槽的设计。在虚拟一致性哈希分区中，不再将真实节点直接映射到哈希环上，而是将每个真实节点虚拟出若干个虚拟节点，然后再将虚拟节点映射到环上，数据显分配到虚拟机节点上，然后再根据对应的虚拟节点找到对应的真实节点。通过这种方式，提高了数据分布均匀性和系统的负载能力，简化了节点的动态管理。在Redis Cluster中并没有直接使用这种算法，而是结合其思想，采用了虚拟槽分区，虚拟槽是固定的，因此不存在增加或移除节点时调整虚拟节点到真实节点的映射关系，避免了计算开销。其次虚拟槽有固定的归属节点，迁移时只需更新槽位映射表，最后时灵活的负载均衡，管理员可以根据负载情况手动调整槽位分配，将热点槽位迁移到负载较低的节点。

Redis Cluster的槽数量为什么时16384个，是因为如果槽位超过这个数，节点之间的心跳包会过于庞大，浪费宽带。其次支持支持从小型到大型集群的均匀数据分布。最后是与 Redis 早期版本保持一致，便于升级和迁移。