Redis集群模式

一、集群模式概念
1）概念
2）功能
3)作用
4）弊端
二、结构解析图
1）主从复制过程
2）哨兵（sentinel）
①哨兵的功能
②哨兵节点解析过程
3）哨兵模式下的迁移过程
①优点
②缺点

三、实战操作过程

##############################################################################################################

一、集群模式概念
1）概念简介
①redis集群简单的理解就是多个redis服务进行完成同一个任务或者在并发状态下可以分担或者代替master成为新的master继续进行一个工作的任务，或者保持数据的完整性，一致性。

② redis是一个开源的kev-value存储系统，受到了广大互联网公司的青睐。redis3.0版本之前只支持单例模式，在3.0版本及以后才支持集群 redis集群采用P2P模式，是完全去中心化的，不存在中心节点或者代理节点;
因为集群内置了16384个slot(哈希槽)，并且把所有的物理节点映射到了这16384[0-16383]个slot上，或者说把这些slot均等的分配给了各个节点。

③当需要在Redis集群存放一个数据(key-value)时，redis会先对这个key进行crc16算法，然后得到一个结果再把这个结果对16384进行求余，这个余数会对应[0-16383]其中一个槽，进而决定key-value存储到哪个节点中。所以一旦某个节点挂了，该节点对应的slot就无法使用，那么就会导致集群无法正常工作。
示例(三个节点) ：
节点A覆盖0-5460;
节点B覆盖5461-10922;
节点C覆盖10923-16383
即每个节点有5460个哈希槽
新增一个节点
节占A覆盖1365-5460
节占B覆盖6827-10922
节点C覆盖12288-16383
节点D覆盖0-1364.5461-6826.10923-12287
即每个节点有4095个哈希槽，所以每个Redis集群大致最多可以有16384个节点

2）功能
③ 为了实现集群的高可用，即判新节点是否健康(能否正常使用)， redis-cluster有一个投票容错机制如果集群中超过半数的节点投票认为某个节点挂了，那么这个节点就挂了(fail)。这是判断节点是否挂了的方法 判新集群是否正常，如果集群中任意一个节点挂了，而且该节点没有从节点(备份节点)，那么这个集群就挂了。这是判断集群是否挂了的方法那么为什么任意一个节点挂了(没有从节点)这个集群就挂了

①redis群集有三种模式，分别是主从同步复制、哨兵模式、Cluster。
②在redis生产环境中，实现高可用的技术主要包括持久化、主从复制、哨兵和集群。

3）作用
①主从复制 主从复制是高可用Redis的基础，哨兵和cluster都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。
② 在主从复制的基础上，哨兵实现了自动化的故障恢复。

4）弊端
① 故障恢复无法自动化
② 写操作无法负载均衡，
③ 存储能力受到单机的限制。
④写操作无法负载均衡
⑤存储能力受到单机的限制。
③ 集群（cluster - 至少6台左右） 通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

二、结构解析图

1）主从复制解析
① 若启动一个Slave机器进程，则它会向Master机器发送一个sync_command命令，请求同步连接

② 无论是第一次连接还是重新连接，Master机器都会启动一个后台进程，将数据快照(RDB)保存到
数据文件中(执行rdb操作)，同时Master还会记录修改数据的所有命令并缓存在数据文件中。

③ 后台进程完成缓存操作之后，Master机器就会向Slave机器发送数据文件，Slave端机器将数据
文件保存到硬盘上，然后将其加载到内存中，接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若Slave出现故障导致宕机，则恢复正常后会自动重新连接。

④ Master机器收到slave端机器的连接后，将其完整的数据文件发送给Slave端机几器，如果Mater同时收到多个slave发来的
同步请求则Master会在后台启动一个进程以保存数据文件，然后将其发送给所有的Slave端机器，确保所有的Slave端机器都正常。

2）哨兵（sentinel）

在主从复制的基础上起到主节点自动故障转移的作用

1、作用及原理
（1）、哨兵模式的作用
监控
哨兵会不断地检查主节点和从节点是否运作正常
自动故障转移
当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点
通知
哨兵可以将故障转移的结果发送给客户端（指的是管理集群的工作人员）

2 哨兵模式的原理
投票机制：
“哨兵”它一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的 Master 并将所有 slave 连接到新的 Master

整个运行哨兵的集群的数量不得少于 3 个节点

3 结构
哨兵结构由两部分组成，哨兵节点和数据节点：

哨兵节点
哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的 redis 节点，不存储数据
数据节点
主节点和从节点都是数据节点

4 工作过程
哨兵的启动依赖于主从模式，所以须把主从模式安装好的情况下再去做哨兵模式，所以节点上都需要部署哨兵模式，哨兵模式会监控所有的 Redis 工作节点是否正常

当 Master 出现问题的时候，因为其他节点与主节点失去联系，因此会投票，投票过半就认为这个 Master 的确出现问题，然后会通知哨兵间会推选出一个哨兵来进行故障转移工作（由该哨兵来指定哪个 slave 来做新的 master），然后从 Slaves 中选取一个作为新的 Master

筛选方式是哨兵互相发送消息，并且参与投票，票多者当选
需要特别注意的是，客观下线是主节点才有的概念，即如果从节点和哨兵节点发生故障，被哨兵主观下线后，将不会再有后续的客观下线和故障转移操作（及哨兵模式只负责 Master 的方面，而不管 Slaves）

当某个哨兵发现主服务器挂掉了，会将 master 中的 SentinelRedistance 中的 master
改为SRI_S_DOWN（主观下线），并通知其他哨兵，告诉他们发现 master 挂掉了
其他哨兵在接收到该哨兵发送的信息后，也会尝试去连接 master，如果超过半数（配置文件中设置的）确认 master 挂掉后，会将
master 中的 SentinelRedistance 中的 master 改为 SRI_O_DOWN（客观下线）

1）哨兵模式集群架构
哨兵是Redis集群架构中非常重要的一个组件，哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题
（2）哨兵模式主要功能
① 集群监控负责监控Redis master和slave进程是否正常工作
② 消息通知如果某个Redis实例有故障，那么哨兵负责发送消息作为告警通知给管理员
③ 故障转移如果master 节点挂掉了，会自动转移到slave 节点上（offset 段偏移量 = position）
④ 配置中心如果故障转移发生了，通知client客户端新的master地址

使用一个或者多个哨兵(Sentinel)实例组成的系统，对redis节点进行监控 在主节点出现故障的情况下， 能将从节点中的一个升级为主节点，进行故障转义，保证系统的可用性。

（3）哨兵们监控整个系统节点的过程(图2)

① 首先主节点的信息是配置在哨兵(Sentinel)的配置文件中

② 哨兵节点会和配置的主节点建立起两条连接，分别为：命令连接和订阅连接
PSRedis发布订阅(pubsub)是一种消息通信模式发送者(pub)发送消息，订阅者 (sub) 接收消息。

③ 哨兵会通过命令连接每10s发送一次INFO命令，通过INFO命令，主节点会返回自己的run_id和自己的从节点信息

④ 哨兵会对这些从节点也建立两条连接命令连接和订阅连接

⑤ 哨兵通过命令连接向从节点发送INFO命令，获取到他的一些信息
run id(redis服务器id)
role(职能)
从服务器的复制偏移量offset
其他

大致解析
1、哨兵对主从复制集群进行监控监控的对象:所有redis数据库节点
2、哨兵与哨兵之间进行相互监控监控的对象:哨兵彼此
3、监控的目的
①、哨兵和哨兵之间的监控，目的为:检测彼此的存活状态
②、哨兵监控所有redis数据库的目的:为了实现自动故障切换
4、故障切换
①当master挂掉，哨兵会及时发现，发现之后，进行投票机制，选举出一个新的master服务器(得是基数)
②完成slave-》 master的从向主的切换
③完成其他从服务器对新master的配置
5、通过redis哨兵原理掌握所有redis 数据库的信息，

哨兵之间的监控解析：
1、 通过命令连接向服务器的sentinelhello频道发送一条消息，内容包括自己的ip端口、run id、配置(后续投票的时候会用到)等

2、 通过订阅连接对服务器的sentinelhello频道做了监听，所以所有的向该频道发送的哨兵的消息都能被接受到

3、解析监听到的消息，进行分析提取，就可以知道还有那些别的哨兵服务节点也在监听这些主从节点了，更新结构体将这些
哨兵节点记录下来

4、 向观察到的其他的哨兵节点建立命令连接----没有订阅连接

3）哨兵模式下的故障迁移
① 主观下线
哨兵(Sentinel)节点会每秒一次的频率向建立了命令连接的实例发送PING命令，如果在down-after-milliseconds毫秒内没有做出有效响应包括(PONGLOADINGMASTERDOWN)以外的响应，哨兵就会将该实例在本结构体中的状态标记为SRI_S_DOWN主观下线

② 客观下线
当一个哨兵节点发现主节点处于主观下线状态是，会向其他的哨兵节点发出询问，该节点是不是已经主观下线了。如果超过配置参数quorum个节点认为是主观下线时，该哨兵节点就会将自己维护的结构体中该主节点标记为SRIO DOWN客观下线询问命令SENTINEL is-master-down-by-addr

③ master选举
在认为主节点客观下线的情况下，哨兵节点节点间会发起一次选举，命令为SENTINEL is-master-down-by-addr
只是runid这次会将自己的runid带进去，希望接受者将自己设置为主节点。如果超过半数以上的节点返回将该节点标记为leacer的情况下，会有该leader对故障进行迁移

④ 故障转移
#在从节点中挑选出新的主节点
通讯正常
优先级排序
优先级相同时选择offset最大的

将该节点设置成新的主节点SLAVEOF no one,并确保在后续的INGO命令时 该节点返回状态为master
将其他的从节点设置成从新的主节点复制，SLAVEOF命令
将旧的主节点变成新的主节点的从节点
PS优缺点
优点
高可用，哨兵模式是基于主从模式的，所有主从模式的优点，哨兵模式都具有有;主从可以自动切换，系统更
健壮，可用性更高
缺点
redis比较难支持在线扩容，在群集容量达到上限时在线扩容会变得很复杂

（5）Cluster群集
redis的哨兵模式基本已经可以实现高可用、读写分离，但是在这种模式每台redis服务器都存储相同的数据，很浪费内存资源，所以在redis3.0上加入了Cluster群集模式，实现了redis的分布式存储，也京是说每台redis节点存储着不同的内容根据官方推荐，集群部署至少要3台以上的master节点，最好使用3主3从六个节点的模式。
Cluster群集由多个redis服务器组成的分布式网络服务群集，群集之中有多个master主节点，每一个主节点都可读可写，节点之间会相互通信，两两相连，redis群集无中心节点

在redis-Cluster群集中，可以给每个一个主节点添加从节点，主节点和从节点直接尊循主从模型的特性，当用户需要处理更多读请求的时候，添加从节点可以扩展系统的读性能
redis-cluster的故障转移redis群集的主机节点内置了类似redissentinel的节点故障检测和自动故障转移功能，当群
集中的某个主节点下线时，群集中的其他在线主节点会注意到这一点，并且对已经下线的主节点进行故障转移
集群进行故障转移的方法和redis sentinel进行故障转移的方法基本一样，不同的是，在集群里面，故障转移是由集群中
其他在线的主节点负责进行的，所以群集不必另外使用redis sentinel

三、实战操作过程
首先搭建Redis主从复制
节点名 IP地址
master 192.168.10.20
slave1 192.168.10.21
slave2 192.168.10.30

(1)安装Redis
三台服务器都需要安装（我已经安装好）
systemctl stop firewalld
systemctl disable firewalld
setenforce 0

yum -y install gcc gcc-c++ make

cd opt
wget -P opt httpdownload.redis.ioreleasesredis-5.0.9.tar.gz
tar -zxvf redis-5.0.9.tar.gz

cd redis-5.0.9
make && make PREFIX=usrlocalredis install
#Redis源码包中直接提供了makefile文件 直接执行make与make install命令进行安装

cd optredis-5.0.9utils
./install_server.sh

#回车，直到出现以下选项，手动修改为“usrlocalredisbinredis-server”
Please select the redis executable path [usrlocalbinredis-server] usrlocalredisbinredis-server

ln -s usrlocalredisbin usrlocalbin

netstat -natp | grep redis

(2) 修改Redis配置文件
① Master节点
vim etcredis6379.conf

bind 0.0.0.0
#70行，修改监听地址为 0.0.0.0
daemonize yes
#137行，开启守护进程
logfile var1ogredis_6379.1og
#172行，指定日志文件目录
dir varlibredis6379
#264行，指定工作目录
appendonly yes
#700行，开启 AOF 持久化功能

etcinit.dredis_6379 restart
#重启服务使配置生效

② Slave12节点
vim etcredis6379.conf

bind 0.0.0.0
#70行，修改监听地址为 0.0.0.0
daemonize yes
#137行，开启守护进程
logfile varlogredis_6379.log
#172行，指定日志文件目录
dir varlibredis6379
#264行，指定工作目录
replicaof 192.168.126.128 6379
#288行，指定要同步的 Master 节点 IP 和端口
appendonly yes
#700行，开启 AOF 持久化功能

etcinit.dredis_6379 restart
#重启服务使配置生效

（3） 验证主从效果
主节点输入
tail -f varlogredis_6379.log

redis-cli info replication
#Replication
rolemaster
connected_slaves2
slave0ip=192.168.226.130,port=6379,state=online,offset=28,lag=1
slave1ip=192.168.226.129,port=6379,state=online,offset=28,lag=1
#master启动时生成的40位16进制的随机字符串，用来标识master节点
master_replid0a1c276e72f872fc6db0e2d9171d874014a7000d
#切换主从的时候master节点标识会有更改
master_replid20000000000000000000000000000000000000000
#复制流中的一个偏移量，master处理完写入命令后，会把命令的字节长度做累加记录，统计在该字段。该字段也是实现部分复制的关键字段。

master_repl_offset42
#无论主从，都表示自己上次主实例repid1和复制偏移量；用于兄弟实例或级联复制，主库故障切换psync
second_repl_offset-1
repl_backlog_active1
repl_backlog_size1048576
repl_backlog_first_byte_offset1
repl_backlog_histlen42

[root@node1 utils]# redis-cli
127.0.0.16379
127.0.0.16379
127.0.0.16379
127.0.0.16379 keys
(empty list or set)
127.0.0.16379 set teacher zhangsan
OK
127.0.0.16379 get teacher
zhangsan

4）报错排查
#当前每一个端口最大的监听队列的长度不满足这个高负载环境，需要调整。
① WARNTNG: The TCP backlog setting of 51l cannot be enforced because /proc/sys/net/core/somaxconnis set to the lower value of128
解决方案
echo 2048 > /proc/ sys/net / core/ somaxconn

#内存超额警告，当前内存设置为0会导致后台保存失败。
②WARNING overcommit memory is set to 0! Background save may fail under low memory condition
解决方案
echo “vm.overcommit_memory=1” >/etc/sysctl.conf
#刷新配置文件保其生效
sysctl vm.overcommit memory=1

#内核中启用了透明大页面（THP）支持会将导致Redis的延迟和内存使用问题
③ WARNING you have Transparent Huge Pages (THP) support ertabled in your kernel. This will createlatency and memory usage issues with Redis
解决方案
echo never > lsys/kernel/mm/transparent_hugepage/enabled

#连接被拒绝，因为主服务器可能绑定了自身IP地址
④ Error condition on socket for SYNC: Connection reset by peer
解决方案
主节点配置文件
bind o.0.0.o

搭建哨兵模式
节点名 IP地址
master 192.168.226.128
slave1 192.168.226.129
slave2 192.168.226.130
5 修改哨兵配置文件[所有节点皆需]
vim optredis-5.0.9sentinel.conf

#17行，关闭保护模式
protected-mode no
#21行，Redis哨 兵默认的监听端口
port 26379

#26行 开启守护进程
daemonize yes
#36行，指定日志存放路径
logfile varlogsentinel.log

#65行，指定数据库存放路径
dir varlibredis6379

#84行，指定哨兵节点
#2表示，至少需要 2 个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel monitor mymaster 192.168.226.128 6379 2

#113行，判定服务器down掉的时间周期，默认30000毫秒 (30秒 )
sentinel down-after-milliseconds mymaster 3000

#146行，故障节点的最大超时时间为180000 (180秒)
sentinel failover-timeout mymaster 180000

6 启动哨兵模式
先启动主节点在启动从节点

cd optredis-5.0.9
redis-sentinel sentinel.conf &

查看哨兵信息
[root@master redis-5.0.7]# redis-cli -p 26379 info sentinel
#Sentinel
sentinel_masters1
sentinel_tilt0
sentinel_running_scripts0
sentinel_scripts_queue_length0
sentinel_simulate_failure_flags0
master0name=mymaster,status=ok,address=192.168.226.1286379,slaves=2,sentinels=1

模拟故障（rm -rf varrunredis_6379.pid）
ps -ef grep redis
#查看 redis-server 的进程号

kill -9 2379
#杀死 Master 节点上的 redis-server 的进程号
查看哨兵信息
[root@master redis-5.0.7]# redis-cli -p 26379 info sentinel
#Sentinel
sentinel_masters1
sentinel_tilt0
sentinel_running_scripts0
sentinel_scripts_queue_length0
sentinel_simulate_failure_flags0
master0name=mymaster,status=odown,address=192.168.226.1286379,slaves=2,sentinels=3

PSstatus=odown
o即objectively ，客观

#查看master哨兵日志
验证结果
tail -f varlogsentinel.log

redis-cli -p 26379 info Sentinel