redis：详解三种集群策略

edis包含三种集群策略

• 主从复制
• 哨兵
• 集群

主从复制

在主从复制中，数据库分为俩类，主数据库(master)和从数据库(slave)。其中主从复制有如下特点：

    主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库
    从数据库一般都是只读的，并且接收主数据库同步过来的数据
    一个master可以拥有多个slave，但是一个slave只能对应一个master
 

主从复制工作机制

当slave启动后，主动向master发送SYNC命令。master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照文件和命令后加载快照文件和缓存的执行命令。

复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。
 

主从配置

redis默认是主数据，所以master无需配置，我们只需要修改slave的配置即可。

设置需要连接的master的ip端口:

    slaveof 192.168.0.107 6379

如果master设置了密码。需要配置：

    masterauth

连接成功进入命令行后，可以通过以下命令行查看连接该数据库的其他库信息:

    info replication
 

哨兵

哨兵的作用是监控 redis系统的运行状况，他的功能如下：

• 监控主从数据库是否正常运行
• master出现故障时，自动将slave转化为master
• 多哨兵配置的时候，哨兵之间也会自动监控
• 多个哨兵可以监控同一个redis

哨兵工作机制

哨兵进程启动时会读取配置文件的内容，通过sentinel monitor master-name ip port quorum查找到master的ip端口。一个哨兵可以监控多个master数据库，只需要提供多个该配置项即可。

同事配置文件还定义了与监控相关的参数，比如master多长时间无响应即即判定位为下线。

哨兵启动后，会与要监控的master建立俩条连接：

    一条连接用来订阅master的_sentinel_:hello频道与获取其他监控该master的哨兵节点信息
    另一条连接定期向master发送INFO等命令获取master本身的信息

与master建立连接后，哨兵会执行三个操作，这三个操作的发送频率都可以在配置文件中配置：

    定期向master和slave发送INFO命令
    定期向master个slave的_sentinel_:hello频道发送自己的信息
    定期向master、slave和其他哨兵发送PING命令

这三个操作的意义非常重大，发送INFO命令可以获取当前数据库的相关信息从而实现新节点的自动发现。所以说哨兵只需要配置master数据库信息就可以自动发现其slave信息。获取到slave信息后，哨兵也会与slave建立俩条连接执行监控。通过INFO命令，哨兵可以获取主从数据库的最新信息，并进行相应的操作，比如角色变更等。

接下来哨兵向主从数据库的_sentinel_:hello频道发送信息与同样监控这些数据库的哨兵共享自己的信息，发送内容为哨兵的ip端口、运行id、配置版本、master名字、master的ip端口还有master的配置版本。这些信息有以下用处：

    其他哨兵可以通过该信息判断发送者是否是新发现的哨兵，如果是的话会创建一个到该哨兵的连接用于发送PIN命令。
    其他哨兵通过该信息可以判断master的版本，如果该版本高于直接记录的版本，将会更新

当实现了自动发现slave和其他哨兵节点后，哨兵就可以通过定期发送PING命令定时监控这些数据库和节点有没有停止服务。发送频率可以配置，但是最长间隔时间为1s，可以通过sentinel down-after-milliseconds mymaster 600设置。

如果被ping的数据库或者节点超时未回复，哨兵任务其主观下线。如果下线的是master，哨兵会向其他哨兵点发送命令询问他们是否也认为该master主观下线，如果达到一定数目（即配置文件中的quorum）投票，哨兵会认为该master已经客观下线，并选举领头的哨兵节点对主从系统发起故障恢复。

如上文所说，哨兵认为master客观下线后，故障恢复的操作需要由选举的领头哨兵执行，选举采用Raft算法：

    发现master下线的哨兵节点（我们称他为A）向每个哨兵发送命令，要求对方选自己为领头哨兵
    如果目标哨兵节点没有选过其他人，则会同意选举A为领头哨兵
    如果有超过一半的哨兵同意选举A为领头，则A当选
    如果有多个哨兵节点同时参选领头，此时有可能存在一轮投票无竞选者胜出，此时每个参选的节点等待一个随机时间后再次发起参选请求，进行下一轮投票精选，直至选举出领头哨兵

选出领头哨兵后，领头者开始对进行故障恢复，从出现故障的master的从数据库中挑选一个来当选新的master,选择规则如下：

    所有在线的slave中选择优先级最高的，优先级可以通过slave-priority配置
    如果有多个最高优先级的slave，则选取复制偏移量最大（即复制越完整）的当选
    如果以上条件都一样，选取id最小的slave

挑选出需要继任的slaver后，领头哨兵向该数据库发送命令使其升格为master，然后再向其他slave发送命令接受新的master，最后更新数据。将已经停止的旧的master更新为新的master的从数据库，使其恢复服务后以slave的身份继续运行。

哨兵配置

哨兵配置的配置文件为sentinel.conf，设置主机名称，地址，端口，以及选举票数即恢复时最少需要几个哨兵节点同意。

    sentinel monitor mymaster 192.168.0.107 6379 1

只要配置需要监控的master就可以了，哨兵会监控连接该master的slave。

启动哨兵节点：

    redis-server sentinel.conf --sentinel &

出现如下内容表示启动成功

集群

使用集群，只需要将每个数据库节点的cluster-enable配置打开即可。每个集群中至少需要三个主数据库才能正常运行。

集群配置

安装依赖环境ruby，注意ruby版本必须高于2.2

yum install ruby
yum install rubygems
gem install redis

修改配置文件:

bind 192.168.0.107

配置端口

port 6380

配置快照保存路径

dir /usr/local/redis-cluster/6380/

开启集群

cluster-enabled yes

为节点设置不同的工作目录

    cluster-config-file nodes-6380.conf
    集群失效时间

    cluster-node-timeout 15000

开启集群中的节点:

    reids-service …/6380/redis.conf

将节点加入集群中

    redis-trib.rb create --replicas 1 192.168.0.107:6380 192.168.0.107:6381 192.168.0.107:6382 192.168.0.107:6383 192.168.0.107:6384 192.168.0.107:6385

中途需要输入yes确定创建集群:

[root@buke107 src]# redis-trib.rb create --replicas 1 192.168.0.107:6380 192.168.0.107:6381 192.168.0.107:6382 192.168.0.107:6383 192.168.0.107:6384 192.168.0.107:6385
>>> Creating cluster
Connecting to node 192.168.0.107:6380: OK
Connecting to node 192.168.0.

如上图所示，已经建立起三主三从的集群。

增加集群节点

 

三种模式的优缺点对比

主从模式（redis2.8版本之前的模式）、哨兵sentinel模式（redis2.8及之后的模式）、redis cluster模式（redis3.0版本之后）

 

    主从模式原理

同Mysql主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。下图为级联结构。
 

优点：

1、解决数据备份问题

2、做到读写分离，提高服务器性能

缺点：

1、每个客户端连接redis实例的时候都是指定了ip和端口号的，如果所连接的redis实例因为故障下线了，而主从模式也没有提供一定的手段通知客户端另外可连接的客户端地址，因而需要手动更改客户端配置重新连接

2、主从模式下，如果主节点由于故障下线了，那么从节点因为没有主节点而同步中断，因而需要人工进行故障转移工作

3、无法实现动态扩容

 

    sentinel模式

Sentinel（哨兵）是Redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

 

优点

1、Master 状态监测

2、如果Master 异常，则会进行Master-slave 转换，将其中一个Slave作为Master，将之前的Master作为Slave

3、Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

缺点：

1、如果是从节点下线了，sentinel是不会对其进行故障转移的，连接从节点的客户端也无法获取到新的可用从节点

2、无法实现动态扩容

 

• cluster模式

在这个图中，每一个蓝色的圈都代表着一个redis的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。

一般集群建议搭建三主三从架构，三主提供服务，三从提供备份功能。

每一个节点都存有这个集群所有主节点以及从节点的信息。

它们之间通过互相的ping-pong判断是否节点可以连接上。如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用节点。如果某个节点和所有从节点全部挂掉，我们集群就进入faill状态。还有就是如果有一半以上的主节点宕机，那么我们集群同样进入发力了状态。这就是我们的redis的投票机制，具体原理如下图所示：

(1)投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超时(cluster-node-timeout),认为当前master节点挂掉.

(2):什么时候整个集群不可用(cluster_state:fail)?

    a:如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. ps : redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败.

    b:如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.

 

优点：

1、有效的解决了redis在分布式方面的需求

2、遇到单机内存，并发和流量瓶颈等问题时，可采用Cluster方案达到负载均衡的目的

3、可实现动态扩容

4、P2P模式，无中心化

5、通过Gossip协议同步节点信息

6、自动故障转移、Slot迁移中数据可用

缺点：

1、架构比较新，最佳实践较少

2、为了性能提升，客户端需要缓存路由表信息

3、节点发现、reshard操作不够自动化