Redis的主从模式、哨兵模式、集群模式

最近学习了一下这三种架构模式，这里记录一下，仅供参考

一、主从架构

1、搭建方式

2、同步原理

3、优化策略：

4、总结：

二、哨兵架构

1、搭建哨兵集群

2、RedisTemplate如何使用哨兵模式

三、分片集群架构

1，搭建分片集群

2、散列插槽

3、集群伸缩

4、故障转移

5、RedsiTemplate访问分片集群

一、主从架构

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

1、搭建方式

如何开启主从关系呢：

我们可以使用salveof或者replicaof命令实现

假设现在在7001、7002、7003三个端口部署了三个redis

我们要想7002作为从7001作为主，需要先连接7002节点

#连接7002
redis-cli -p 7002
#执行slaveof
slaveof xxx.xxx.xxx 7001

另外一个节点也是如此，查询配置情况我们可以使用INFO replication命令

2、同步原理

全量同步：

主从的第一次同步是全量同步

1.1.首先从节点执行replicaof命令请求建立连接，向主节点发送请求数据同步

1.2.主节点判断是否是第一次同步

1.3.如果是第一次，返回主节点的数据版本信息

1.4.从节点保存版本信息

2.1.主节点执行bgsave操作时会生成RDB文件

2.1.1.生成RDB文件之后会将旗舰所有的命令记录到一个baklog文件当中

2.2.然后发送RDB文件向从节点

2.3.从节点接收到RDB会清空本地数据加载RDB文件

3.1.主节点发送repl_baklog中的命令

3.2.从节点执行repl_baklog中的命令

master如何判断slave是不是第一次来同步数据?

这里会用到两个很重要的概念:

Replication ld:简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replidslave则会继承master节点的replid
offset:偏移量，随着记录在repl baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset.如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此slave做数据同步，必须向master声明自己的replicationid和offset，master才可以判断到底需要同步哪些数据

从节点向主节点发送链接请求会携带replication Id,主节点判断这个id是否一致，如果不一致说明是第一次连接需要全量同步，如果一致那么说明只需要增量同步既可

增量同步：

1.1.从节点向主节点发送同步请求，并携带relication id和偏移量offset

1.2.主节点判断relid是否和当前节点一致

1.3.如果不是第一次，恢复continue

2.1.主节点去repl_baklog中获取偏移量offset后的命令数据

2.2.主节点向从节点发送offset后的命令

2.3.从节点执行命令

注意：这里可能会出现一个问题，就是从节点如果因为一些原因很长时间没用做增量同步，主节点这边的repl_baklog如果出现了覆盖，这时候从节点再去根据命令做同步就会出现数据不一致，所以这时候只能通过全量同步

3、优化策略：

可以从以下几个方面来优化Redis主从就集群:

在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘10。
Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘I0
适当提高repl baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

4、总结：

简述全量同步和增量同步区别?

全量同步:master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl baklog，逐个发送给slave。
增量同步:slave提交自己的offset到master，master获取repl baklog中从offset之后的命令给slave

什么时候执行全量同步?

slave节点第一次连接master节点时
slave节点断开时间太久，replbaklog中的offset已经被覆盖时

什么时候执行增量同步?

slave节点断开又恢复，并且在replbaklog中能找到offset时

二、哨兵架构

在主从模式当中，从节点宕机后可以找到主节点同步数据，但是主节点宕机就丸辣。

解决办法是什么呢？我们可以安排一个或多个哨兵去观察这个主节点，一但主节点出现问题，那我们哨兵就立刻取代掉主节点，重新选举出一个新的主节点。这就是哨兵（Sentinel）机制

Redis提供了哨兵（sentinel）机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下：

监控：S嗯停了会不断检查你的master和slave是否按预期工作
自动故障恢复：如果master故障，sentinel会将一个slave提升为master。当故障示例恢复后也以新的master为主
通知：java客户端找主从地址不是直接去找，而是去哨兵sentinel集群中去找，由哨兵通知我们客户端需要去访问哪个地址，当飞机群发生故障转移时，会将最新消息推送个redis的客户端

sentinel的服务检测基于心跳机制检测服务状态，每隔1秒向集群的每个实例发送ping命令：

主观下线:如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
客观下线:若超过指定数量(quorum)的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

一旦发现master故障，sentinel需要在salve中选择一个座位新的master,选择依据是这样：

首先会判断slave节点与master节点断开时间长短，如果超过指定值(down-after-miliseconds*10)则会排除该slave节点
然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举
如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
最后是判断slave节点的运行id大小，越小优先级越高。

当选中一个slave为新的master之后（例如slave1：7002），会发生一个故障转移：

sentinel给备选的slave1节点发送slaveofnoone命令，让该节点成为master
sentinel给所有其它slave发送slaveof192.168.150.101:7002命令，让这些slave成为新master的从节点，开始从新的master上同步数据。
最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点

1、搭建哨兵集群

假设现在有三个redis实例，端口分别是27001、27002、27003,我们需要再每一个的实例文件目录下创建一个sentinel.conf文件，添加如下内容

port 27001（根据节点更改）
sentinel announce-ip 192.168.150.101
sentinel monitor mymaster 192.168.150.101 7001 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
dir "/tmb/s1"（需要修改）

运行时要启动sentinel实例：

redis-sentinel ***.conf  #运行启动sentinel实例

2、RedisTemplate如何使用哨兵模式

三、分片集群架构

哨兵模式只能解决高并发读的问题，当有高并发写的需求的时候，主从和哨兵模式就会有大量的IO操作，造成效率的底下。对于这个问题，解决办法就是搭建分片集群架构。

使用分片集群可以解决上述问题，分片集群特征:

集群中有多个master，每个master保存不同数据
每个master都可以有多个slave节点master之间通过ping监测彼此健康状态
客户端请求可以访问集群任意节点，最终都会被转发到正确节点\\

1，搭建分片集群

现假设有六个redis节点7001、7002、7003、8001、8002、8003搭建redis集群，三个主节点，三个从节点

在每个文件目录下准备一个redis.conf文件：内容如下，端口要改

通过命令一键运行六个目录文件下的.conf文件

部署成集群的命令如下：

redis-cli --cluster create -cluster-replicas 1 
192.168.150.101:7001 192.168.150101:7002 
192.168.150.101:7003 492.168.150.101:8001 
192.168.150.101:8002 192.168.150.101:8003