redis主从架构及redis cluster的高可用高并发原理

redis在项目中扮演着很重要的角色，一旦redis出现故障，就会出现缓存雪崩的问题，进而导致整个系统的崩溃；同时redis还必须应付高并发的场景，为底层的数据库抗下大部分的流量。所以redis需要实现高可用以及高并发的架构，主要的实现方式有redis主从架构和redis cluster两种

redis主从架构

redis的主从架构实现高并发依靠的是读写分离，因为缓存使用的场景主要是读多写少。master节点负责写操作，slave节点负责读操作，横向增加slave机器就可以支持更高的读并发。缓存数据都在master机器上，slave只是同步master的数据对外提供读缓存的服务
主从架构的复制原理依赖于redis replication，redis replication是一种master-slave模式的复制机制，这个机制使得slave节点可以成为与master节点完全相同的副本
slave同步master数据的步骤大致看上去是这样的：
当slave第一次从master上获取数据的时候，使用的是全量复制，slave 通过PSYNC 命令，向 master 发起同步请求
然后master执行 BGSAVE 命令，启动一个后台线程，生成一份RDB文件，同时将客户端新的写请求缓存在backlog中
RDB文件生成后，master将RDB文件发送给slave，slave将RDB文件加载到内存中
然后master将backlog中缓冲的写命令发送给slave，slave同步这一部分的数据
之后master跟slave之间的数据同步就是通过backlog，slave提供offset给master，然后进行数据的增量同步

slave在同步数据的时候，如果跟master节点断开网络连接了，可以使用断点续传
断点续传的原理是master会在内存中建立一个backlog，master和slave都会维护一份replica offset和master id，其中offset就存储在backlog中。如果slave跟master断开连接了，下次进行数据同步的时候，slave就会根据master id找到master节点，然后根据offset从上次断开连接的地方继续进行数据的同步

如果master对应多个slave的话，在进行数据同步的时候，只会生成一份RDB文件，所有的slave都使用这一份RDB文件

redis主从架构中还有一个关键的组件是sentinel哨兵，哨兵的作用有以下几点
（1）集群监控，负责监控redis master和slave进程是否正常工作
（2）消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
（3）故障转移，如果master node挂掉了，会自动转移到slave node上
（4）配置中心，如果故障转移发生了，通知client客户端新的master地址

同时哨兵也需要维护一个高可用的集群，至少需要三个节点才能正常工作，那么哨兵集群是如何工作的呢？
哨兵互相之间的发现，是通过redis的pub/sub系统实现的，每个哨兵都会往_sentinel_:hello这个channel里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在
每隔两秒钟，每个哨兵都会往自己监控的某个master+slaves对应的_sentinel_:hello:hello channel里发送一个消息，内容是自己的host、ip和runid还有对这个master的监控配置
每个哨兵也会去监听自己监控的每个master+slaves对应的_sentinel_:hello:hello channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在
每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步
通过哨兵机制，redis主从架构才是真正的高可用，如果redis主从架构中的某一个master或slave宕机了，都能及时发现并处理，达到了高可用的目的

redis cluster

redis cluster是redis官方提供的一种集群方式，也就是所谓的亲儿子，搭建起来不需要像主从架构一样那么复杂
redis cluster推荐是使用6台机器，组成三主三从的高可用架构，且每个master和自己的slave不在同一台机器上
redis cluster的高并发实现主要是依赖redis cluster自动将数据进行分片，每一个master上只存放部分的数据，这样不断增加master机器就能不断扩容，支撑更高的并发量
至于高可用的话，每个master都带着slave，自动就做读写分离，每个master如果故障，那么就会自动将slave切换成master，实现了高可用

redis cluster架构下，要实现这种分布式的数据存储，肯定就需要各个节点之间进行通信，每个redis会开放两个端口，假如其中一个是6379，那么另一个端口号就加10000，也就是16379，16379端口号就是用来节点之间通信的

redis cluster默认情况下，master负责所有的读写操作，slave只用作master的热备，如果非要使用slave来读数据的话，需要加上readonly命令
而redis cluster官方并不建议做读写分离，因为本身就存在多个master，只需要增加master的数量，同时给master配上slave作为热备，横向的添加机器，就可以支撑更高的读写并发，且存储海量数据

在可用性里还存在一个问题，如果一个master只搭配一个slave的话，且master和slave短时间内都宕机了，那么可用性就降低了
为了避免这种情况的发生，可以多配置几个slave作为冗余，所以可能有的master就有多个slave了，当某个slave宕机之后，冗余的slave会自动迁移过去，作为新的slave，即使master宕机了，这个slave也能作为新的master继续提供服务

适用场景

redis主从架构中是使用的是读写分离思想，数据都保存在一个master节点上，slave节点只对外提供读操作，可以横向加slave来扩充读并发，配置稍微复杂一些，因为还需要配置哨兵集群，适用于缓存数据较少的场景
redis cluster架构中的每一个master节点都是一块数据分片，可以不断增加master机器来增加缓存的容量，配置较为简单，但是需要更多的机器（多个master），适用于海量数据的场景