Redis架构

主从架构

工作原理

• 建立连接：在Redis主从架构中，主节点（Master）和从节点（Slave）之间建立了长连接。从节点会定期向主节点发送PING命令，确保与主节点的连接正常。
• 复制数据：主节点负责接收客户端的写操作命令，并将写操作记录到内存中的数据库中。同时，主节点将写操作的指令通过网络传输给所有连接的从节点。从节点接收到指令后，会执行相同的写操作，保持数据的一致性。
• 初始同步：当从节点首次连接到主节点时，它会执行一次全量数据同步（Initial
  Synchronization）操作，即将主节点上的所有数据复制到自己的内存数据库中。初始同步完成后，从节点会以增量方式继续接收主节点的写操作。
• 增量同步：在初始同步完成后，主节点会将写操作的指令以增量方式传输给从节点。从节点根据接收到的指令更新自己的数据库，保持与主节点数据的一致性。
• 心跳检测：主节点会定期向从节点发送心跳信息，确认从节点是否在线。如果从节点长时间未响应主节点的心跳信息，则主节点会将该从节点标记为下线。

优点

• 读写分离
  主节点负责处理写操作，而从节点负责处理读操作，可以有效分担主节点的读取压力，提高系统整体的读取性能。
• 数据备份：
  通过主从复制，可以实现数据的备份和灾难恢复。即使主节点发生故障，从节点仍然可以提供服务，同时也可以通过从节点进行数据的恢复。
• 扩展性：
  可以通过添加多个从节点来实现横向扩展，提高系统的容量和吞吐量。
• 故障容错：
  当主节点发生故障时，可以快速将一个从节点晋升为新的主节点，保证系统的可用性

缺点

• 单点故障
  主节点是单点故障，如果主节点发生故障，可能会导致整个系统的不可用。
• 数据延迟
  由于主从复制是异步进行的，从节点上的数据可能会有一定的延迟，这可能导致读取到的数据不是最新的。
• 网络带宽消耗
  主节点每次写操作都需要将数据同步给从节点，可能会占用大量的网络带宽

主从架构主要问题是单点故障，主节点宕机后，Redis就无法写入，可能导致服务不可用，且不能完成主备切换，不符合高可用设计原则，增加哨兵集群可以解决这个问题。

哨兵架构

工作原理

• 监控主节点状态：每个哨兵（Sentinel）实例会周期性地监控主节点（Master）的状态，包括主节点是否存活、主节点是否正常处理命令请求等。
• 主节点故障检测：当哨兵检测到主节点不可用或异常时，它会将主节点标记为下线，并开始进行故障转移流程。
• 选举新的主节点：哨兵会通过选举算法从当前的从节点中选出一个作为新的主节点。选举的过程主要考虑从节点的优先级、复制偏移量等因素，以确保选出的节点是最合适的。
• 通知客户端：一旦选举出新的主节点，哨兵会向客户端发送通知，告知客户端主节点发生了变化。
• 更新配置：哨兵会将新的主节点信息更新到所有的从节点和其他哨兵的配置文件中，使其可以正确连接到新的主节点。
• 故障恢复：一旦新的主节点选举完成并投入使用，哨兵会持续监控所有节点的状态，确保整个Redis集群处于正常运行状态。

故障迁移过程

• 启动阶段
  当 Redis Sentinel 进程启动时，所有哨兵节点都处于监听状态，等待收集 Redis 主从节点信息。
• 主观下线检测
  每个哨兵节点定期向其他哨兵节点发送 PING 命令以确认彼此之间的连接是否正常。如果一个哨兵节点连续一段时间无法收到其他哨兵节点的响应，它会将其他哨兵节点标记为主观下线。
• 客观下线检测
  当一个哨兵节点将Redis节点标记为主观下线后，它会请求其他哨兵节点对被标记的节点进行确认。如果大多数哨兵节点都认为某个节点处于主观下线状态，那么该节点就会被判定为客观下线。
• 领导者选举
  一旦一个 Redis 主节点被认定为客观下线，各个哨兵节点会开始进行领导者选举。哨兵节点通过在响应投票中达到多数票来选举领导者。领导者选举过程中，每个哨兵节点都可以成为候选领导者，并向其他哨兵节点发送选举请求。
• 领导者选举结果
  最终，通过一系列的投票和通信，哨兵节点会选举出一个新的领导者。选举出的领导者负责监控和管理 Redis 高可用性集群，并在主节点故障时选举新的主节点。
• 故障转移
  一旦选举出新的领导者，它会负责执行故障转移操作，将原来的主节点替换为一个从节点，并将新的从节点升级为主节点。哨兵领导者会向其他Sentinel节点发送指令，通知它们切换到新的主节点。同时，哨兵领导者会向客户端发送指令，让它们重新连接到新的主节点。
• 数据同步和复制
  在新的主节点上，Redis会自动启动数据同步和复制操作，将原来主节点的数据同步到新的从节点上，以确保数据的完整性和一致性。

哨兵领导者选举流程

Raft算法：整体思路是先到先得，例如A、B、C三个哨兵节点，A向B、C发送成为领导者的申请，如果B、C没有同意过其他节点的申请，就同意A的申请，当A被同意的次数超过设定的阈值，那么它就成为领导者了。

主节点选举

新的领导者会从当前的从节点中选举出一个作为新的主节点。选举的依据通常包括以下几个方面：

• 复制偏移量（replication offset）
  从节点同步主节点的数据偏移量，通常选择最接近主节点的从节点。
• 复制优先级（replication priority）
  从节点的复制优先级，通常选择复制优先级最高的从节点。
• 连接状态
  从节点与主节点的连接状态，通常选择连接状态稳定的从节点。

优点

• 高可用性：哨兵架构可以实现主节点的自动故障检测和故障转移，提高了Redis集群的可用性。当主节点发生故障时，哨兵会自动选举一个从节点作为新的主节点，保证了服务的连续性。
• 自动化管理：哨兵负责监控主节点的状态，并自动执行故障转移操作，无需人工干预。这简化了Redis集群的管理和维护工作。
• 扩展性：哨兵架构支持动态添加和移除节点，可以根据业务需求灵活扩展Redis集群的规模和容量。

缺点

• 复杂性：哨兵架构引入了额外的组件和逻辑，增加了系统的复杂性。哨兵的部署和配置需要一定的经验和技术能力。
• 性能损耗：哨兵架构需要周期性地进行状态检测和故障转移操作，会产生一定的性能损耗。特别是在主节点发生故障时，故障转移过程可能会引起服务的停顿和延迟。
• 单点故障：哨兵本身也可能成为系统的单点故障。如果哨兵发生故障或不可用，可能会导致整个集群的异常。
• 配置复杂性：哨兵架构需要配置较多的参数和选项，包括哨兵的数量、监控间隔、故障转移阈值等，配置不当可能会影响系统的稳定性和可靠性。

集群架构

工作原理：

• 数据分片：Redis集群将数据分散存储在多个节点中，每个节点存储部分数据。通过对数据进行分片，可以实现横向扩展，提高系统的吞吐量和容量。
• 节点通信：集群中的各个节点间相互通信，维护集群的拓扑结构和节点状态信息。每个节点都会周期性地向其他节点发送信息，以确保整个集群的一致性和稳定性。
• 主从复制：每个分片都有一个主节点和若干个从节点，主节点负责处理客户端的读写请求，从节点负责复制主节点的数据。当主节点发生故障时，集群会自动选举一个从节点作为新的主节点，保证服务的连续性。
• 客户端路由：客户端通过Redis集群的客户端库连接到集群，并通过集群的路由功能将请求路由到正确的节点。集群会根据Key的哈希值计算出对应的槽位，并将请求发送到负责该槽位的节点上。
• 槽分配：Redis集群将所有的数据分成16384个槽位（slot），每个槽位都有一个唯一的编号。当客户端进行数据操作时，集群会根据Key的哈希值将数据映射到对应的槽位，然后将该槽位的数据存储在负责该槽位的节点上。
• 故障检测和恢复：Redis集群会周期性地进行节点状态检测，一旦发现节点异常，就会触发故障转移流程，将异常节点从集群中移除，并重新分配槽位。同时，集群还会自动进行数据迁移和复制，以确保数据的完整性和可用性。

slot槽映射方式

主要有三种：

• 哈希取余
  hash(key)/分片数，主要问题是不能扩展，增加或者减少分片后，原有的映射关系不存在。
• 一致性哈希
  

一致性哈希（Consistent Hashing）是一种用于分布式系统中数据分片的算法，它能够在增加或删除节点时最小化数据重新分配的情况，保证系统的可扩展性和稳定性。一致性哈希的基本原理如下：

环形哈希空间：一致性哈希将哈希空间抽象为一个环形空间，取值范围为0到2^32-1（32位哈希值）。所有的数据和节点都映射到这个环形空间上。

每个节点通过哈希算法计算出一个哈希值，表示在环形空间上的位置。然后，数据将被映射到距离其最近的下一个节点上。

当有新节点加入或现有节点退出时，只会影响到相邻节点的负载，不会对整个环形空间造成影响。因此，只有一小部分数据需要重新映射到其他节点，可以实现负载均衡的目的。
一致性性哈希算法的主要缺点是数据倾斜：由于数据的哈希值是随机的，有时候可能会出现数据倾斜的情况，即部分节点上存储的数据量远远超过其他节点。这样会导致一些节点的负载过重，可能会影响系统的性能和稳定性

• 哈希槽算法
  对于要存储或查询的每个键，将键的哈希值对16384取模，得到一个在0到16383之间的整数，这个整数就是键被分配到的哈希槽的编号。每个Redis节点负责维护部分哈希槽。
  当要存储或查询一个键时，计算出所属的哈希槽，找到负责该槽的节点，然后将数据存储在该节点上或从该节点上查询数据。

最大槽数为什么是16384个？

CRC16算法产生的hash值有16bit，可以产生65536个值。为什么哈希槽的数量是2^14（16384）个。
Redis会发送心跳消息，心跳消息的内容里包括一个槽位信息：myslots[CLUSTER_SLOTS/8]，其中CLUSTER_SLOTS就是槽数，如果是2^16(65536)个槽，那么myslots的大小就是8kb，消息头太大了，浪费带宽。
正常情况下，Redis集群的节点不会超过1000个，因此16384个槽位是足够的

优点

• 高可用性：Redis集群采用主从复制机制，即使某个节点发生故障，集群仍然能够继续工作，不会因为单点故障而导致整个系统的不可用。
• 横向扩展性：Redis集群支持横向扩展，可以通过增加更多的节点来扩展集群的容量和性能，从而满足不断增长的数据存储和处理需求。
• 负载均衡：Redis集群采用一致性哈希算法将数据分布到多个节点上，能够保证数据的均匀分布和负载均衡，有效地提高了系统的整体性能和稳定性。
• 数据备份：Redis集群中的每个主节点都可以配置多个从节点进行数据备份，可以保证数据的持久性和可靠性，同时在主节点故障时可以快速切换到从节点进行数据恢复。
• 故障恢复：Redis集群通过监控和自动故障检测机制能够快速发现故障节点，并通过自动故障转移功能将故障节点替换为新的主节点，保证系统的高可用性和数据一致性。
• 动态扩展：Redis集群支持动态扩展和缩减，可以根据实际需求灵活地增加或减少节点，实现资源的动态调配和优化。
• 并行处理：Redis集群中的各个节点可以并行处理请求，从而提高系统的并发能力和响应速度，适用于高并发场景下的数据存储和处理。