第五章----Redis三种集群详解

Redis集群的三种模式

• 主从复制（master/slave）
• 哨兵模式（sentinel）
• 集群模式（cluster）

一张图看懂Redis部署演变方式：

Redis进化史

1. 主从复制（master/slave）

• 新建redis-master文件夹并复制redis.conf文件到该文件夹 分别命名：redis-8001.conf、redis-8002.conf、redis-8003.conf

• 分别修改配置文件的端口号和增加主服务器

port 8001
slaveof 172.31.133.70 7001

修改redis.conf

• 启动三台服务器

启动

• 验证主从配置信息

验证

• 主从链复制模型

主从链

其中master可读写，slave为只读，提高了服务读的能力，一定程度上缓解写能力，可修改redis.conf配置主服务器，也可动态执行slaveof语句配置丛服务器。

• 主从复制过程（全量）

master	slave
等待命令接入	连接master 发送sync命令
开始执行bgsave命令，并使用缓存区记录bgsave之后的写命令	根据配置决定继续接入本服务器命令还是返回接入命令错误提示
bgsave完毕 向从服务器发送快照文件，并继续缓存写命令	清空本服务数据，载入master快照文件
快照执行完毕，向从服务器发送缓存的写命令	像往常一样接收写命令
缓存区执行完毕，以后每个写命令都同步给从服务器	执行缓存区命令，并接收以后的每一个写命令

• 主从复制过程（增量）

  如果全量复制过程中，master-slave 网络连接断掉，那么 slave 重新连接 master 时，会触发增量复制。 master 直接从自己的 backlog 中获取部分丢失的数据，发送给 slave node，默认 backlog 就是 1MB。 master 就是根据 slave 发送的 psync 中的 offset 来从 backlog 中获取数据的。

从服务器同步快照的时候会清空自身原有数据，Redis不支持主主同步，当多个从服务器连接主服务器时快照文件可以重用

主从链模式，可以分担主服务器的复制工作，当中间层从服务器同步数据的时候会断开与下层的连接，同步完毕后，须重新连接重新同步

• 相关命令

1. 连接主服务器
slaveof 172.31.133.70 7001
2. 查看主从信息
info replication
3. 解除主从关系
info no one

2. 哨兵模式（sentinel）

• 新建redis-sentinel文件夹并复制sentinel.conf文件到该文件夹 分别命名：sentinel-9001.conf、sentinel-9002.conf、sentinel-9003.conf

• 分别修改配置文件的端口号和监控的主从链

port 9001
#判断master失效至少需要2个sentinel同意，建议设置为n/2+1，n为sentinel个数
sentinel monitor mymaster 172.31.133.70 7001 2   
#判断master主观下线时间，默认30s              
sentinel down-after-milliseconds mymaster 30000                 

• 启动三台sentinel，可看到监控的信息

./redis-sentinel ../redis-sentinel/sentinel-9001.conf 

启动信息

• 模拟master宕机

#查找进程，日志可看到7001端口宕机，master切换到8002端口
ps -ef | grep redis
#强制杀掉进程
kill -9 799

sentinel日志

sentinel模式是在主从模式基础上升级版，哨兵主要任务就是：监控、提醒、自动故障切换

• 监控

  主观下线： Sentinel会每隔一秒向主从服务器以及其他Sentinel发送Ping命令，如果超过指定的时间（ own-after-milliseconds，默认30秒）没有回复，那么该Sentinel就会认为该服务器下线。

  客观下线： 当一个Sentinel判断一个服务器下线后，它为了确定是否真的下线，会向其他Sentinel确认是否真的下线了，如果足够多的Sentinel认为该服务器下线了（半数原则），那么就判断该服务器客观下线了，如果没有足够的Sentinel同意该服务器是下线的，那么Master的客观下线状态会被移除。

• 提醒

  当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

• 故障切换

  选举主sentinel服务器，原则是先到先得，并且被任命后在主sentinel正常情况下不再接受选举。

  选择一个slave服务器任命为新master服务器，原来master上线后做为新的slave服务器。

• sentinel模式模型

一点也不乱

3. cluster模式

• 在Redis目录下新建redis-cluster文件夹，在新文件夹下新建7001-7006等6个文件夹，分别复制redis.conf到700*文件夹中，并编辑配置文件

bind 172.31.133.70
port 7001
daemonize yes
pidfile /var/run/redis_7001.pid
logfile "/app/redis/redis-cluster/7001/redis-7001.log"
dir "/app/redis/redis-cluster/7001"        # node.conf文件保存路径
appendonly yes
appendfsync everysec
cluster-enabled yes        # 开启集群
cluster-config-file nodes-7001.conf        # 该文件中包含集群信息
cluster-node-timeout 15000

cluster搭建

• 新建批启动文件，给文件赋予权限，并启动各个服务器

vim /app/redis/redis-cluster/cluster.sh

# 文件内容
cd ../src/
./redis-server ../redis-cluster/7001/redis-7001.conf
./redis-server ../redis-cluster/7002/redis-7002.conf
./redis-server ../redis-cluster/7003/redis-7003.conf
./redis-server ../redis-cluster/7004/redis-7004.conf
./redis-server ../redis-cluster/7005/redis-7005.conf
./redis-server ../redis-cluster/7006/redis-7006.conf

# 授权执行
chmod u+x cluster.sh

启动服务器

• 创建集群关系，会在各个文件夹下生成appendonly.aof、dump.rdb、nodes-7001.conf、redis-7001.conf、redis-7001.log文件，这里一定要用外网IP去创建集群！！！

• 每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口，每隔节点每隔一段时间都会往另外几个节点发送ping消息，同时其他几点接收到ping之后返回pong，如果需要请去云服务器开启设置17001-17006的安全组。

# redis5之后就可以用redis-cli命令创建，--cluster-replicas 1  表示前三个为master后三个为slave
./redis-cli --cluster create 118.190.***.***:7001 118.190.***.***:7002 118.190.***.***:7003 118.190.***.***:7004 118.190.***.***:7005 118.190.***.***:7006 --cluster-replicas 1 

开启集群

• 登录任意服务器查看集群信息

# -c 表示集群方式登录 如有密码 -a
./redis-cli -h 172.31.133.70 -p 7001 -c
# 查看集群节点信息
cluster nodes
# 查看集群基本信息
cluster info

集群信息

• 模拟7001节点宕机，其slave（7006）节点会自动切换为master，当7001重启后，改为新master（7006）节点的slave节点

节点宕机

• 集群相关操作命令

# 增加节点，新增节点都是master节点
cluster meet 172.31.133.70 7007

# 更改节点身份（node_id）
cluster replicate 10c632232237a7703f21fb64c8e848fd5ecef63d

# 删除节点 ，无法删除自己
cluster forget 10c632232237a7703f21fb64c8e848fd5ecef63d

#保存配置
cluster saveconfig

• cluster介绍

  1. sentinel模式本质上并没有提高服务器写的能力，只是拥有了故障自动转移，于是cluster应运而生，cluster相当于哨兵+主从的升级版，提供自动故障切换，在线扩容等。
  2. cluster有多个主从服务链组成，每个主节点都提供读写能力，主节点之间保持心跳关系，且无中心化。
  3. cluster复制遵循主从复制原则，cluster故障切换遵循sentinel转移原则。
  4. cluster用分片策略存储数据位置，把数据库分成16348个槽，crc16(key)%16384利用求余来确定位置。
  5. 由于cluster是无中心化，命令会随机分配到某个节点，算出位置后向客户端返回一个redirect转向，客户端根据正确的位置再次发送请求，完成操作。

• cluster模型

cluster模型

• cluster生产环境部署方案

假设6 台机器，3 台机器部署了 redis 主实例，另外 3 台机器部署了 redis 的从实例，每个主实例挂了一个从实例，3个节点对外提供读写服务，每个节点的读写高峰qps可能可以达到每秒 5 万，3 台机器最多是 15 万读写请求/s。

假设32G 内存+ 8 核 CPU + 1T 磁盘，分配给 redis 进程的是10g内存，一般线上生产环境，redis 的内存尽量不要超过 10g，超过 10g 可能会有问题。

• JedisCluster 连接异常 Too many Cluster redirections?
  修改redis-700*.conf配置文件，注释掉 bind 属性，把 protected-mode 属性给成 no

---

花开如火 也如寂寞