Redis实战宝典：从主从模式、哨兵模式、集群模式一步步理解Redis集群

Redis 集群的三种模式

在生产环境中，我们使用 Redis 通常采用集群模式，因为单机版 Redis 稳定性可靠性较低，而且存储空间有限。

Redis 支持三种集群模式

• 主从复制
• 哨兵模式
• Cluster 模式

主从复制

主从复制概念

主从复制模式，有一个主，多个从，从而实现读写分离。主机负责写请求，从机负责读请求，减轻主机压力。

主从复制原理

1. 从数据库启动成功后，连接主数据库，发送 SYNC 命令；
2. 主数据库接收到 SYNC 命令后，开始执行 BGSAVE 命令生成 RDB 文件并使用缓冲区记录此后执行的所有写命令；
3. 主数据库 BGSAVE 执行完后，向所有从数据库发送快照文件，并在发送期间继续记录被执行的写命令；
4. 从数据库收到快照文件后丢弃所有旧数据，载入收到的快照；
5. 主数据库快照发送完毕后开始向从数据库发送缓冲区中的写命令；
6. 从数据库完成对快照的载入，开始接收命令请求，并执行来自主数据库缓冲区的写命令；（从数据库初始化完成）
7. 主数据库每执行一个写命令就会向从数据库发送相同的写命令，从数据库接收并执行收到的写命令（从数据库初始化完成后的操作）
8. 出现断开重连后，2.8之后的版本会将断线期间的命令传给重数据库，增量复制。
9. 主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。Redis 的策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

主从复制优缺点

优点

• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离
• Slave 同样可以接受其它 Slaves 的连接和同步请求，这样可以有效的分载 Master 的同步压力
• Master Server 是以非阻塞的方式为 Slaves 提供服务。所以在 Master-Slave 同步期间，客户端仍然可以提交查询或修改请求

缺点

• 主从不具备容错和恢复能力，一旦主机挂了，那么整个集群处理可读状态，无法处理写请求，会丢失数据
• 主机宕机后无法自动恢复，只能人工手动恢复
• 集群存储容量有限，容量上线就是主库的内存的大小，无法存储更多内容

配置

# redis6379.conf    master
# 包含命令，有点复用的意思
include /soft/redis6.0.6/bin/redis.conf
pidfile redis_6379.pid
port    6379
dbfilename dump6379.rdb
logfile "redis-6379.log"# redis6380.conf    slave1
include /soft/redis6.0.6/bin/redis.conf
pidfile redis_6380.pid
port    6380
dbfilename dump6380.rdb
logfile "redis-6380.log"
# 最后一行设置了主节点的 ip 端口
replicaof 127.0.0.1 6379# redis6381.conf    slave2
include /soft/redis6.0.6/bin/redis.conf
pidfile redis_6381.pid
port    6381
dbfilename dump6381.rdb
logfile "redis-6381.log"
# 最后一行设置了主节点的 ip 端口
replicaof 127.0.0.1 6379## 注意 redis.conf 要调整一项，设置后台运行，对咱们操作比较友好
daemonize yes

哨兵集群

哨兵概念

哨兵，我们经常在电视剧中看到一些放哨的，哨兵的作用和这些放哨的差不多，起到监控作用。一旦 Redis 集群出现问题了，哨兵会立即做出相应动作，应对异常情况。

哨兵模式是基于主从复制模式上搭建的，因为主从复制模式情况下主服务器宕机，会导致整个集群不可用，需要人工干预，所以哨兵模式在主从复制模式下引入了哨兵来监控整个集群，哨兵模式架构图如下：

哨兵功能

监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。

自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。

配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。

通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

下线判断

Redis 下线分为主观下线和客观下线两种

• 主观下线：单台哨兵任务主库处于不可用状态
• 客观下线：整个哨兵集群半数以上的哨兵都认为主库处于可不用状态

哨兵集群中任意一台服务器判断主库不可用时，此时会发送命令给哨兵集群中的其他服务器确认，其他服务器收到命令后会确认主库的状态，如果不可用，返回 YES，可用则返回 NO，当有半数的服务器都返回 YES，说明主库真的不可用，此时需要重新选举

主库选举

当哨兵集群判定主库下线了，此时需要重新选举出一个新的主库对外提供服务。那么该由哪个哨兵来完成这个新库选举和切换的动作呢？

注意：这里不能让每个哨兵都去选举，可能会出现每个哨兵选举出的新主库都不同，这样就没法判定，所以需要派出一个代表。

哨兵代表选择

哨兵的选举机制其实很简单，就是一个Raft选举算法： 选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举

任何一个想成为 Leader 的哨兵，要满足两个条件：

• 第一，拿到半数以上的赞成票；
• 第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。

以 3 个哨兵为例，假设此时的 quorum 设置为 2，那么，任何一个想成为 Leader 的哨兵只要拿到 2 张赞成票，就可以了。

新库选择

上面已经选举出了哨兵代表，此时代表需要完成新主库的选择，新库的选择需要满足以下几个标准

• 新库需要处于健康状态，也就是和哨兵之间保持正常的网络连接
• 选择salve-priority从节点优先级最高（redis.conf）的
• 选择复制偏移量最大，只复制最完整的从节点

故障转移

上面一小节哨兵已经选举出了新的主库，故障转移要实现新老主库之间的切换

故障转移流程如下：

哨兵模式优缺点

优点

• 实现了集群的监控，故障转移，实现了高可用
• 拥有主从复制模式的所有优点

缺点

• 集群存储容量有限，容量上线就是主库的内存的大小，无法存储更多内容

配置

# 文件内容
# sentinel1.conf
port 26379
sentinel monitor mymaster 127.0.0.1 6379 1
# sentinel2.conf
port 26380
sentinel monitor mymaster 127.0.0.1 6379 1
# sentinel3.conf
port 26381
sentinel monitor mymaster 127.0.0.1 6379 1

Cluser 集群

Redis 的哨兵模式实现了高可用了，但是每台 Redis 服务器上存储的都是相同的数据，浪费内存，而且很难实现容量上的扩展。所以在 redis3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的内容。

Redis 集群的数据分片

Redis 集群没有使用一致性hash, 而是引入了 哈希槽的概念.

Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:

• 节点 A 包含 0 到 5500号哈希槽.
• 节点 B 包含5501 到 11000 号哈希槽.
• 节点 C 包含11001 到 16384号哈希槽.

这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态

Redis提供了主从、哨兵、cluster等三种集群模式，其中cluster模式为目前大多数公司所采用的方式。

官方推荐，Cluser 集群至少要部署 3 台以上的 master 节点，最好使用 3 主 3 从。.

但是，redis的cluster模式，有不少的硬伤。redis cluster采用虚拟槽的概念，把所有的key映射到 0～16383个整数槽内，属于无中心化的架构。但它的维护成本较高，slave也不能够参与读取操作。它的主要问题，在于一些批量操作的限制。由于key被hash到多台机器上，所以mget、hmset、sunion等操作就非常的不友好，经常发生性能问题。

redis的主从模式是最简单的模式，但无法做到自动failover，通常在主从切换后，还需要修改业务代码，这是不能忍受的。即使加上haproxy这样的负载均衡组件，复杂性也是非常高的。哨兵模式在主从数量比较多的时候，能够显著的体现它的价值。一个哨兵集群，能够监控成百上千个集群，但是哨兵集群本身的维护是比较困难的。幸运的是，redis的文本协议非常简单，在netty中，甚至直接提供了redis的codec。自研一套哨兵系统，加强它的功能，是可行的。

配置
配置文件内容如下，6 个配置文件信息基本相同，编辑好一份后其他文件直接复制修改端口即可

# 端口
port 7001  
# 启用集群模式
cluster-enabled yes 
# 根据你启用的节点来命名，最好和端口保持一致，这个是用来保存其他节点的名称，状态等信息的
cluster-config-file nodes_7001.conf 
# 超时时间
cluster-node-timeout 5000
appendonly yes
# 后台运行
daemonize yes
# 非保护模式
protected-mode no 
pidfile  redis_7001.pid

功能性需求

redis还能玩很多花样。举个例子，全文搜索。很多人都会首选es，但redis生态就提供了一个模块：RediSearch，可以做查询，可以做filter。

但我们通常还会有更多的需求，比如统计类、搜索类、运营效果分析等。这类需求与大数据相关，即使是传统的DB也不能胜任。这时候，我们当然要把redis中的数据，导入到其他平台进行计算啦。

如果你选择的是redis数据库，那么dba打交道的，就是rdb，而不是binlog。有很多的rdb解析工具(比如redis-rdb-tools)，能够定期把rdb解析成记录，导入到hadoop等其他平台。

此时，rdb成为所有团队的中枢，成为基本的数据交换格式。导入到其他db后的业务，该怎么玩怎么玩，完全不会因为业务系统选用了redis就无法运转。