深入了解redis集群方案（主从模式、哨兵模式、Redis Cluster模式）

深入了解redis集群方案（主从模式、哨兵模式、Redis Cluster模式）

本篇文章给大家带来了关于redis的相关知识，其中主要介绍了主从模式、哨兵模式以及redis 模式的相关问题，希望对大家有帮助。

推荐学习：Redis教程

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

一、主从模式

将数据完全存储在单个redis中主要存在两个问题：

数据备份和数据体量较大造成的性能降低。

Redis的主从模式为这两个问题提供了一个较好的解决方案。主从模式指的是使用一个redis实例作为主机，其余的实例作为备份机。

主机和从机的数据完全一致，主机支持数据的写入和读取等各项操作，而从机则只支持与主机数据的同步和读取，也就是说，客户端可以将数据写入到主机，由主机自动将数据的写入操作同步到从机。

主从模式很好的解决了数据备份问题，并且由于主从服务数据几乎是一致的，因而可以将写入数据的命令发送给主机执行，而读取数据的命令发送给不同的从机执行，从而达到读写分离的目的。

实现主从复制（-Slave ）的工作原理：

Slave从节点服务启动并连接到之后，它将主动发送一个SYNC命令。服务主节点收到同步命令后将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，将传送整个数据库文件到Slave，以完成一次完全同步。而Slave从节点服务在接收到数据库文件数据之后将其存盘并加载到内存中。此后，主节点继续将所有已经收集到的修改命令，和新的修改命令依次传送给，Slave将在本次执行这些数据修改命令，从而达到最终的数据同步。

如果和Slave之间的链接出现断连现象，Slave可以自动重连，在连接成功之后，一次完全同步将被自动执行。

部署：

redis :6.0.9

1.分别复制4份Redis配置文件

命名为 .conf .conf .conf .conf

2.对4份配置文件进行简单配置

节点的配置文件一般不需要特殊设置 port默认为6379

节点 port设置 6380 再配置一行 127.0.0.1 6379

节点 port设置 6381 再配置一行 127.0.0.1 6379

节点 port设置 6382 再配置一行 127.0.0.1 6379

3.分别开启 节点和3个Slave节点

redis- .conf

redis- .conf

redis- .conf

redis- .conf

4.验证集群主从状态

主从模式的优缺点：

1、优点：

同一个可以同步多个。

能自动将数据同步到slave，可以进行读写分离，分担的读压力

、slave之间的同步是以非阻塞的方式进行的redis集群挂掉，同步期间，客户端仍然可以提交查询或更新请求

2、缺点：

不具备自动容错与恢复功能，或slave的宕机都可能导致客户端请求失败，需要等待机器重启或手动切换客户端IP才能恢复

宕机，如果宕机前数据没有同步完，则切换IP后会存在数据不一致的问题

难以支持在线扩容，Redis的容量受限于单机配置

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

二、哨兵模式（）

哨兵顾名思义，就是来为Redis集群站哨的，一旦发现问题能做出相应的应对处理。其功能包括

监控、slave是否正常运行

当出现故障时，能自动将一个slave转换为（大哥挂了，选一个小弟上位）

多个哨兵可以监控同一个Redis深入了解redis集群方案（主从模式、哨兵模式、Redis Cluster模式），哨兵之间也会自动监控

当自动发现slave和其他哨兵节点后，哨兵就可以通过定期发送PING命令定时监控这些数据库和节点有没有停止服务。

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

哨兵认为客观下线后，故障恢复的操作需要由选举的领头哨兵来执行，

选出领头哨兵后，领头者开始对系统进行故障恢复，从出现故障的的从数据库中挑选一个来当选新的,

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

哨兵模式基于前面的主从复制模式。哨兵的配置文件为.conf，在相应目录中添加以下配置，注意端口不要冲突：

port 26379
protected-mode no
daemonize yes
pidfile "/var/run/redis-sentinel-26379.pid"
logfile "/data/redis/logs/sentinel_26379.log"
dir "/data/redis/6379"
sentinel monitor mymaster 127.0.0.1 6379 2           ##指定主机IP地址和端口，并且指定当有2台哨兵认为主机挂了，则对主机进行容灾切换
#sentinel auth-pass mymaster pwdtest@2019             ##当在Redis实例中开启了requirepass，这里就需要提供密码
sentinel down-after-milliseconds mymaster 3000                      ##这里设置了主机多少秒无响应，则认为挂了
sentinel failover-timeout mymaster 180000       ##故障转移的超时时间，这里设置为三分钟

格式如下：

查看哨兵状态：

三、redis 集群模式（)

采用无中心结构,它的特点如下：

客户端与redis节点直连,客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

模式的具体工作机制：

在Redis的每个节点上，都有一个插槽（slot），取值范围为0-16383 ，一共16384个槽

当我们存取key的时候redis集群挂掉，Redis会根据CRC16的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

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

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

Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。

为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个主节点，挂n个slave从节点。这时，如果主节点失效，Redis 会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务，Redis 本身提供了故障转移容错的能力。

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

集群部署

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

模式是建立在模式的基础上的，当数据多到需要动态扩容的时候，前面两种就不行了，需要对数据进行分片，根据一定的规则把redis数据分配到多台机器。

该模式就支持动态扩容，可以在线增加或删除节点，而且客户端可以连接任何一个主节点进行读写，不过此时的从节点仅仅只是备份的作用。至于为何能做到动态扩容，主要是因为Redis集群没有使用一致性hash,而是使用的哈希槽。Redis集群会有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，而集群的每个节点负责一部分hash槽。

那么这样就很容易添加或者删除节点深入了解redis集群方案（主从模式、哨兵模式、Redis Cluster模式）， 比如如果我想新添加个新节点， 我只需要从已有的节点中的部分槽到过来；如果我想移除某个节点，就只需要将该节点的槽移到其它节点上，然后将没有任何槽的A节点从集群中移除即可。由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。

需要注意的是，该模式下不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为。

搭建集群

这里就直接搭建较为复杂的模式集群，也是企业级开发过程中使用最多的。

1.建redis各节点目录

最终目录结构如下

2.逐个修改redis配置

以 9001 的为例子，其余五个类似。