redis 集群方案的介绍（主从模式、哨兵模式、Redis Cluster模式）

分享内容：

redis 集群方案的介绍（主从模式、哨兵模式、Redis Cluster模式）

Redis Cluster 的部署和使用

本次演示使用的Redis版本为 redis-5.0.3

一、主从模式

将数据完全存储在单个redis中主要存在两个问题：数据备份和数据体量较大造成的性能降低。
Redis的主从模式为这两个问题提供了一个较好的解决方案。主从模式指的是使用一个redis实例作为主机，其余的实例作为备份机。
主机和从机的数据完全一致，主机支持数据的写入和读取等各项操作，而从机则只支持与主机数据的同步和读取，也就是说，客户端可以将数据写入到主机，由主机自动将数据的写入操作同步到从机。
主从模式很好的解决了数据备份问题，并且由于主从服务数据几乎是一致的，因而可以将写入数据的命令发送给主机执行，而读取数据的命令发送给不同的从机执行，从而达到读写分离的目的。

实现主从复制（Master-Slave Replication）的工作原理：Slave从节点服务启动并连接到Master之后，它将主动发送一个SYNC命令。Master服务主节点收到同步命令后将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，Master将传送整个数据库文件到Slave，以完成一次完全同步。而Slave从节点服务在接收到数据库文件数据之后将其存盘并加载到内存中。此后，Master主节点继续将所有已经收集到的修改命令，和新的修改命令依次传送给Slaves，Slave将在本次执行这些数据修改命令，从而达到最终的数据同步。
如果Master和Slave之间的链接出现断连现象，Slave可以自动重连Master，在连接成功之后，一次完全同步将被自动执行。

我们可以利用master来处理写操作，slave提供读操作。这样可 以有效减少单个机器的并发访问数量。

主从模式的搭建：
Redis配置文件常用配置

# 通用配置
# bind 127.0.0.1 # 绑定监听的网卡IP，注释掉或配置成0.0.0.0可使任意IP均可访问
port 6379  # 设置监听端口
#是否开启保护模式，默认开启。
# 设置为no之后最好设置一下密码
protected-mode no
#是否在后台执行，yes：后台运行；no：不是后台运行
daemonize yes
# 复制选项，slave复制对应的master。
# replicaof <masterip> <masterport>
#如果master设置了requirepass，那么slave要连上master，需要有master的密码才行。masterauth就是用来
# 配置master的密码，这样可以在连上master后进行认证。
# masterauth <master-password>

更多配置参数

部署演示
分别复制4份Redis配置文件 命名为 master.conf slave1.conf slave2.conf slave3.conf
对4份配置文件进行简单配置
Master节点的配置文件一般不需要特殊设置 port默认为6379
Slave1 节点 port设置 6380 再配置一行 replicaof 127.0.0.1 6379
Slave2 节点 port设置 6381 再配置一行 replicaof 127.0.0.1 6379
Slave3 节点 port设置 6382 再配置一行 replicaof 127.0.0.1 6379
分别开启 Master节点和3个Slave节点

redis-server  master.conf
redis-server  slave1.conf
redis-server  slave2.conf
redis-server  slave3.conf

操作Redis读写

Master可读写 Slave只读

主从模式的优缺点：

1、优点：

• 同一个Master可以同步多个Slaves。
• master能自动将数据同步到slave，可以进行读写分离，分担master的读压力
• master、slave之间的同步是以非阻塞的方式进行的，同步期间，客户端仍然可以提交查询或更新请求

2、缺点：

• 不具备自动容错与恢复功能，master或slave的宕机都可能导致客户端请求失败，需要等待机器重启或手动切换客户端IP才能恢复
• master宕机，如果宕机前数据没有同步完，则切换IP后会存在数据不一致的问题
• 难以支持在线扩容，Redis的容量受限于单机配置

其实redis的主从模式很简单，在实际的生产环境中很少使用，不建议在实际的生产环境中使用主从模式来提供系统的高可用性，之所以不建议使用都是由它的缺点造成的，在数据量非常大的情况，或者对系统的高可用性要求很高的情况下，主从模式也是不稳定的。虽然这个模式很简单，但是这个模式是其他模式的基础，所以理解了这个模式，对其他模式的学习会很有帮助。

二、哨兵模式（Sentinel）

哨兵顾名思义，就是来为Redis集群站哨的，一旦发现问题能做出相应的应对处理。其功能包括
监控master、slave是否正常运行
当master出现故障时，能自动将一个slave转换为master（大哥挂了，选一个小弟上位）
多个哨兵可以监控同一个Redis，哨兵之间也会自动监控

当自动发现slave和其他哨兵节点后，哨兵就可以通过定期发送PING命令定时监控这些数据库和节点有没有停止服务。
如果被PING的数据库或者节点超时（通过 sentinel down-after-milliseconds master-name milliseconds 配置）未回复，哨兵认为其主观下线（sdown，s就是Subjectively —— 主观地）。如果下线的是master，哨兵会向其它哨兵发送命令询问它们是否也认为该master主观下线，如果达到一定数目（即配置文件中的quorum）投票，哨兵会认为该master已经客观下线（odown，o就是Objectively —— 客观地），并选举领头的哨兵节点对主从系统发起故障恢复。若没有足够的sentinel进程同意master下线，master的客观下线状态会被移除，若master重新向sentinel进程发送的PING命令返回有效回复，master的主观下线状态就会被移除。

哨兵认为master客观下线后，故障恢复的操作需要由选举的领头哨兵来执行，
选出领头哨兵后，领头者开始对系统进行故障恢复，从出现故障的master的从数据库中挑选一个来当选新的master,
挑选出需要继任的slave后，领头哨兵向该数据库发送命令使其升格为master，然后再向其他slave发送命令接受新的master，最后更新数据。将已经停止的旧的master更新为新的master的从数据库，使其恢复服务后以slave的身份继续运行。

部署演示
哨兵模式基于前面的主从复制模式。哨兵的配置文件为sentinel.conf，在文件中添加以下配置

# mymaster定义一个master数据库的名称，后面是master的ip， port，1表示至少需要一个Sentinel进程同意才能将master判断为失效
# 如果不满足这个条件，则自动故障转移（failover）不会执行
sentinel monitor mymaster 127.0.0.1 6379 1 

# master的密码
# sentinel auth-pass mymaster 123456 

# 5s未回复PING，则认为master主观下线，默认为30s
sentinel down-after-milliseconds mymaster 5000 

 # 指定在执行故障转移时，最多可以有多少个slave实例在同步新的master实例，在slave实例较多的情况下
 # 这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
sentinel parallel-syncs mymaster 2 

# 如果在该时间（ms）内未能完成故障转移操作，则认为故障转移失败，生产环境需要根据数据量设置该值
sentinel failover-timeout mymaster 300000 

更多哨兵配置参数
使用命令 redis-server sentinel.conf --sentinel 或者 redis-sentinel sentinel.conf 启动哨兵进程

哨兵模式优缺点：
优点：
哨兵模式基于主从复制模式
哨兵模式下，master挂掉可以自动进行切换，系统可用性更高

缺点：
同样也继承了主从模式难以在线扩容的缺点，Redis的容量受限于单机配置
需要额外的资源来启动sentinel进程，实现相对复杂一点

三、redis cluster 介绍

Cluster采用无中心结构,它的特点如下：
客户端与redis节点直连,客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

Cluster模式的具体工作机制：
在Redis的每个节点上，都有一个插槽（slot），取值范围为0-16383 ，一共16384个槽
当我们存取key的时候，Redis会根据CRC16的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

为了保证高可用，Cluster模式也引入主从复制模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。

当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点都宕机了，那么该集群就无法再提供服务了。

Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。
为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务，Redis Cluster本身提供了故障转移容错的能力。

Cluster模式集群节点最小配置6个节点(根据cluster的选举机制和主从备份的实现，redis要求至少三主三从共6个节点才能组成redis集群，因为至少需要半数以上才能确定某个节点是否宕机且需要主从备份)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。

cluster集群部署

根据cluster的选举机制和主从备份的实现，redis要求至少三主三从共6个节点才能组成redis集群，测试环境可一台物理机器上启动6个redis节点，但生产环境至少要准备2～3台物理机。(这里使用三台虚拟机)

服务端口	IP地址	配置文件名
7001	192.168.200.200	redis.conf
7002	192.168.200.201	redis.conf
7003	192.168.200.202	redis.conf
7004	192.168.200.200	redis.conf
7005	192.168.200.201	redis.conf
7006	192.168.200.202	redis.conf

redis 配置修改

redis.config 配置支持集群，需要修改部分配置项，所有节点(不分主从)修改都是一致的，修改配置完成后启动对应的所有节点即可，和启动普通单例没有区别。

配置项	说明
port	指定端口，默认值：6379
cluster-enabled	开启集群，去掉#： cluster-enabled yes
cluster-config-file	集群的配置文件，去掉#，首次启动会自动生成，命名修改： nodes-{port}.conf
cluster-node-timeout	请求超时 默认15秒，可自行设置
appendonly	指定是否在每次更新操作后进行日志记录，默认不开启，即aof模式备份数据
include	指定包含其它的配置文件
daemonize	redis 是否后台运行，默认值：no
pidfile	daemonize方式运行时，pid可以通过pidfile指定： /var/run/redis_6379.pid
requirepass	对集群设置密码
masterauth	如果设置，requirepass和masterauth都需要设置，并且每个节点的密码要一致
以上修改 6 份实例，然后正常启动即可。

创建集群

创建redis集群命令（三主三从，每个主一个从，注意redis-5.0.0版本开始才支持“–cluster”，redis-cli --cluster 为 redis-5.0.0/src 下的 redis-cli ，老版本不支持，之前的版本会报错。）

redis-cli --cluster create 192.168.200.200:7001 192.168.200.201:7002 192.168.200.202:7003 192.168.200.200:7004 192.168.200.201:7005 192.168.200.202:7006 --cluster-replicas 1

如果配置项 cluster-enabled 的值不为yes，则执行时会报错“[ERR] Node 192.168.0.251:6381 is not configured as a cluster node.”。这个时候需改为yes，然后重启 redis-server 进程，之后才可以重新执行 redis-cli 创建集群。

redis-cli的参数说明：

1. create
   表示创建一个redis集群。

2. –cluster-replicas 1
   表示为集群中的每一个主节点指定一个从节点，即一比一的复制。

运行过程中，会有个提示，输入yes 回车即可。从屏幕输出，可以很容易地看出哪些是主（master）节点，哪些是从（slave）节点：

集群测试

客户端测试，6个节点等价，在单机版redis基础上指定参数“-c”,链接仍意一个节点即可: redis-cli -a 123456 -p 7001 -c
查看当前集群信息 : cluster info
查看集群里有多少个节点: cluster nodes

添加一个新主（master）节点
假设要添加新的节点“192.168.200.200:6390”，先以单机版配置和启动好6390，然后执行命令（“127.0.0.1:6381”为集群中任一可用的节点）

redis-cli --cluster add-node 192.168.200.200:6390 127.0.0.1:6381

添加一个新从（slave）节点
以添加“192.168.200.200:6390”为例

redis-cli --cluster add-node 192.168.0.251:6390 127.0.0.1:6381 --cluster-slave

“192.168.200.200:6390” 为新添加的从节点，“127.0.0.1:6381”可为集群中已有的任意节点，这种方法随机为6390指定一个master，如果想明确指定master，假设目标master的ID为“123546”，则：

redis-cli --cluster add-node 192.168.200.200:6390 127.0.0.1:6381 --cluster-slave --cluster-master-id 123456

删除节点
从集群中删除一个节点命令格式：
redis-cli --cluster del-node 127.0.0.1:7000 <node-id>
“127.0.0.1:7000”为集群中任意一个非待删除节点，“node-id”为待删除节点的ID。如果待删除的是master节点，则在删除之前需要将该master负责的slots先全部迁到其它master。

$ ./redis-cli --cluster del-node 127.0.0.1:7000   082c079149a9915612d21cca8e08c831a4edeade 
>>> Removing node 082c079149a9915612d21cca8e08c831a4edeade from cluster 127.0.0.1:7000 
>>> Sending CLUSTER FORGET messages to the cluster...
>>> SHUTDOWN the node.

参考《Redis中文网》