Redis之常用架构

当涉及Redis的架构时，有几种常见的架构模式，包括主从复制、哨兵架构和Redis集群。这些架构模式为Redis提供了高可用性、扩展性和容错性.下面我们来逐个了解：

主从复制

主从复制是redis最基本的架构形式.有一个主节点，和1个或多个从节点组成.
主节点负责写请求和部分读请求，从节点负责部分读请求.

工作原理

总得来说主从架构就是从节点复制主节点上的数据，然后为客户端提供读请求，降低主节点的压力.

全量复制

为一个主节点新配置一个从节点，则会全量复制.

// 1.slave向master发送psync命令要求同步数据
// 2.mster收到从节点的命令，生成此刻的rdb数据快照
// 3.master生成rdb快照后则将rdb数据发送给slave(rdb生成数据较快).
// 4.在slave先清空老数据，然后执行rdb文件，同时master也在接受新的数据请求，这部分数据会缓存在repl buffer里
// 5.当从节点执行完rdb文件后，master会发送buffer里的操作数据命令
// 6.slave执行buffer里传过来的命令，这样主从数据就一致了。
// 7.后续master执行新的操作，都会发送给slave执行，保持最终数据一致.

部分复制

当一个主从架构中的从节点宕机然后恢复，此时从节点肯定没有同步主节点的一部分数据，此时也会向主节点发送同步数据的请求，此时会带着一个buffer的偏移量，从偏移量后的数据开始同步，这就是部分同步.（全量同步性能要求高）

// 1.slave宕机，断开了连接,没有同步到后续主节点的数据.
// 2.slave恢复重新与master连接，发送psync命令，带着数据同步的偏移量offet
// 3.如果offet在master的repl buffer中能找到，则将offet后的数据发送给slave.
// 4.但是如果repl buffer里没有offet，说明slave宕机时间过长，master已经写了很多数据（buffeer默认存1M的数据）,这是就要执行全量复制了.

// 5.数据一致后最终都是master执行数据操作后，同步给slave.

注：如果master配置太多的slave,可能会有主从复制风暴，多个从节点同时复制主节点导致主节点压力过大.

哨兵架构

sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点.
它能够自动检测主节点的故障，并在需要时执行故障转移，将一个从节点提升为新的主节点，确保系统的高可用性。哨兵也能管理故障节点的恢复，并在节点重新加入集群时进行配置。

// 主要流程
1.哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点.
2.当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis主节点通知给client端.(redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)

注：哨兵模式相比较与主从模式，哨兵模式能够自动故障检测和转移，能够在主节点出现问题的时候，选举从节点成为新的的主节点，保证redis高可用.（主从架构如果主节点挂了，会出现redis不可用，需要人工干预）.

集群架构

不管是主从架构还是哨兵架构,由于主从复制数据不宜太大，推荐大约是10个G左右，当需要存储大数据量的时候，性能就会大大降低.所以就有了集群模式。
现在假设要存储的数据有30个G，使用集群架构3个主节点，则每个主节点存储10个G的数据，每个主节点存储的数据都不同,后续如果数据再增加，只要跟着增加增加redis节点就行.

// 以下是集群架构的优点
// 1.自动化的数据分片和负载均衡
Redis集群能够自动将数据分片到多个节点中，并在节点之间实现数据的均衡分布。这意味着它能更好地利用硬件资源，提高了系统的扩展性和负载均衡性。
// 2.增加了横向扩展性
相比于主从架构和哨兵模式的单节点限制，Redis集群允许横向扩展，通过添加更多的节点来增加存储容量和吞吐量。
// 3.高可用性
Redis集群通过在不同节点上复制数据来提高可用性。每个数据片段都有多个副本分布在不同节点上，当某个节点出现故障时，系统仍然可用。
// 4.自动化的节点管理和故障恢复
Redis集群通常具有自动化的故障检测和节点恢复机制，能够自动完成节点的替换和数据迁移，减少人工干预。

Redis集群原理分析

Redis Cluster 将所有数据划分为 16384 个 slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。
当client连接到集群时，它会得到集群的槽位配置信息,然后缓存到本地.后续当client操作某个key时，会根据算法直接定位到目标节点。

// 槽位定位算法
默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位。
假设:
现在3个主节点,第一个节点管理1-5461，第二个节点5462-10923，第三个节点10924-16384.
操作某个key:HASH_SLOT = CRC16(key) % 16384 -> 算出槽点1024，则操作第一个节点

集群选举

当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master可能会有多个slave，从而存在多个slave竞争成为master节点的过程， 其过程如下：

1.slave发现自己的master变为FAIL
2.将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST 信息
3.其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack
4.尝试failover的slave收集master返回的FAILOVER_AUTH_ACK
5.slave收到超过半数master的ack后变成新Master（所以集群至少3个节点，不然当有节点挂了无法选举）
6.slave广播Pong消息通知其他集群节点。

集群脑裂问题

造成的原因：假设一个子集群主节点和从节点网络不通了，超过一定时间从节点就会发起选举成为新的主节点，这时这个子集群就会有两个主节点，客户端会随机向两个主节点写数据，等到网络恢复后，最先的主节点会变为从节点，这时会同步数据，导致部分数据丢失.
解决方法：配置参数min‐replicas‐to‐write 1（写数据至少同步一个从节点才算成功）,这样就可以尽可能保证数据不丢失.但是可用性会变差，如果从节点都宕机了，那么这个节点就不可用了。

总结

主从复制是简单的备份和读写分离模式，适用于基本的备份需求。
哨兵模式在主从架构基础上提供了自动化的故障检测和转移。
集群模式适用于处理大规模数据和高并发请求的情况，提供了自动化的分片和负载均衡。

每种架构都有其优势和限制，选择合适的架构取决于应用需求、复杂性和可用性要求。在设计Redis架构时，需要根据具体情况综合考虑这些因素，并可能结合多种架构模式来达到最佳的性能、可用性和扩展性。