Redis集群（读写分离、哨兵机制、Cluster集群）

概念概述
一、主从复制
原理
优点
缺点
同步原理
二、哨兵（Sentinel）机制
原理
哨兵的三大工作任务
优点
缺点
三、Redis内置集群（Cluster模式）
原理
集群搭建（实践出真知嘛，加油！朋友们）
需要的环境
主从复制模式搭建
哨兵机制集群搭建
内置集群搭建（Cluster集群）
Cluster集群维护
分片重哈希
移除节点
添加节点
概念概述
首先我们要知道的是，Redis实际上有三种集群方案：
主从复制模式、哨兵机制（又称为Sentinel模式）、集群模式（又称为Cluster模式）
其次我们得知道为什么需要集群模式
实际上，单机Redis的读写速度非常快，可以支持大量用户的访问，虽然Redis的性能很高，但是对于大型网站来说，每秒钟所需要获取的数据远远超过单台redis服务所能承受的压力
所以我们需要一种方案来解决单台Redis服务性能不足的问题
一、主从复制
原理
主从复制方案：对读写能力扩展，采用读写分离的方式解决性能瓶颈。
即运行一个新的服务器（简称为从服务器），从服务器与主服务器进行连接，然后主服务器发送数据副本，从服务器通过网络根据主服务器的数据副本进行准实时更新（具体的更新速度取决于网络带宽），主服务器可以进行读写操作，当写操作导致数据发生变化时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。
！！注意，一个主服务器可以有多个从服务器，但一个从服务器只能有一个主服务器。这就像一个老大可以有很多小弟，但一个小弟不能同时跟多个老大一样。
这样我们就有额外的从服务器来处理读请求，通过将读请求分散到不同的从服务器上面进行处理，用户可以从新添加的从服务器上获得额外的读查询处理能力
并且Redis通过持久化功能，保证了即使服务器宕机或重启的情况下也不会丢失数据，因为持久化会把内存中的数据保存到硬盘上，重启会从硬盘上加载数据。
优点
主从复制，主机会自动将数据同步到从机，实现了读写分离
从服务器提供只读操作，主服务器提供读读写操作
从服务器同样可以接受其他从服务器的连接和同步请求，这样可以有效的分载主服务器的同步压力
主服务器是以非阻塞的方式为从服务器提供服务，所以在主从同步期间，客户端依然可以提交查询或修改请求
从服务器也是以非阻塞的方式完成数据同步的，在同步期间，如果有客户端提供查询请求，Redis则返回同步之前的数据
缺点
Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或手动切换前端的IP才能恢复（即人工介入）
主机宕机后如果有部分数据没有及时同步到从机，更换主机IP后会导致数据不一致的问题
如果多个从机断线，需要重启的时候，如果在同一时间段进行重启，多个slave重启，都会发送sync请求并进行主机全量同步，那就会导致主机 IO剧增从而主机宕机
Redis较难支持在线扩容，在集群容量达到上限时在线扩容就会变得艰难
同步原理
redis2.8之前使用的是sync同步命令，redis2.8之后使用的是psync命令
两者的不同在于：sync仅支持全量复制过程，psync支持全量和部分复制

更改命令的原因在于，如果服务器在主从复制的过程中出现了断线，重连之后需要全量同步一次，但如果断线时间非常短，可能会出现主从之间数据还是一致的，简单的进行了全量同步，就造成了主从服务器之间cpu，内存，网络带宽方面的浪费
使用psync命令，对于服务器断线重连主服务器这种情景，从服务器重连之后，发送psync命令给主服务器，主服务器会根据该从服务器的同步情况，决定是只需将断线期间的写入同步给该服务器，还是需要进行全量同步
因为本文重点不是这个，所以具体的PYSNC核心设计改日再写，😉
二、哨兵（Sentinel）机制
原理
主从复制这种同步模式，只有一个节点，那么当该主节点宕机后，需要手动切换从服务器为主服务器，这就造成不但需要人工干预，还会造成一段时间内的服务不可用，哨兵机制的集群模式就可以有效的改善这个问题
用能听的懂的话来说，就是用一个哨兵来监控所有的服务器状态，一旦发现某个主服务器宕机或故障了，就自动让从服务器顶上去
哨兵是一个独立的进程，会独立运行，哨兵进程通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器
当哨兵进程检测到某个主机宕机后，会自动将slave切换为master，然后通过发布订阅模式同之其他从服务器，修改配置文件，让他们切换主机
那么哨兵是知晓服务器是否下线呢，主要分为主观下线和客观下线
主观下线（SDOWN）： 就是说单个哨兵对服务器做出的下线判断，我愿称之为”君主式哨兵”,也就是王说你下线了，你就是下线了
如果一个服务器没有在master-down-after-milliseconds选项所指定的时间内，对向它发送PING命令的哨兵返回一个有效的回复，那么哨兵就会将这个服务器标记为主观下线
客观下线（ODOWN）： 客观下线的评判由多个哨兵完成，我称之为"民主式哨兵“，也就是说一个主机是否下线，由多个哨兵投票完成，当多个哨兵说该主机下线了，那么它就是下线了
从主观下线切换为客观下线状态使用的不是法定人数算法，而是流言传播，即如果哨兵在给定范围内，从其他哨兵那里接收到了足够数量的主服务器下线报告，那么哨兵就会将主服务器的状态从主观下线切换为客观下线
PS:客观下线只适用于主服务器，对于其他类型的Redis实例，哨兵在将它们判断为下线前不需要进行协商，所以从服务器或其他哨兵不会达到客观下线条件。
并且只要一个哨兵发现了某个主服务器进入了客观下线状态，那么这个哨兵就可能会被其他哨兵推选出，并对失效的服务器执行自动故障迁移操作。
当然下线状态的标记是可以被去除的，如果没有足够的哨兵进程同意主服务器下线，那么主服务器的客观下线状态标记就会被移除
如果主服务器重新向哨兵发送的PING命令返回了有效的回复，主服务器的主观下线状态就会被移除
哨兵的三大工作任务
其实在上述原理中已经讲过了，只是这里更精简一点
监控（Monitoring）： 哨兵会不断检查主服务器和从服务以及其他哨兵是否运作正常
提醒（Notification）: 当被监控的某个服务器出现问题时，哨兵可以通过API向管理员或其他应用程序发送通知
自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时，哨兵会开始一次自动故障转移操作，它会将失效的主服务器的其中一个从服务器升级为新的主服务器，并让失效的主服务器的其他从服务器知晓新的主服务器。
当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。
优点
从上文可以看出，哨兵机制集群模式是基于主从复制模式的，所以它有主从复制的所有优点
主从服务器可以自动切换，系统更加健壮，可用性更高
缺点
Redis较难支持在线扩容，在集群容量达到上限时在线扩容就会变得很复杂
三、Redis内置集群（Cluster模式）
原理
Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供
哨兵机制的集群已经基本可以实现高可用，读写分离，但是在这种模式下，每台Redis服务器都存储了相同的数据，非常浪费内存，所以在Redis3.0上加入了Cluster集群模式，实现了Redis的分布式存储，即每台Redis节点上存储了不同的内容
以下是原理图（图源网络）

 

解释一下，上图中每一个蓝色圆圈代表着一个Redis的服务器节点，可以看到的是，任意两个节点之间都是相互连通的（采用的是PING-PONG机制），内部使用二进制协议优化传输速度和带宽。客户端可以与任意一个节点相连，然后就可以访问集群中的任何一个节点。对其进行存取和其他操作
Redis集群使用的是哈希槽的概念，Redis集群有16384个哈希槽，每个Key通过CRC16校验后对16384取模来决定放置在那个槽。集群中的每个节点负责一部分的hash槽，意思是无论有多少个节点，都只有16384个槽来分。
使用这种架构很容易添加或删除节点，比如如果想删除某个节点，那么就将该节点的槽移动到其他节点上，然后将没有任何槽的节点移除
同时为了保证高可用，Redis-Cluster集群引入了主从复制模型，一个主节点对应一个或多个从节点，当主节点宕机后，就会启用从节点
对于主机的宕机判断，采用的是投票方式，当其它主节点ping一个主节点时，如果半数以上的主节点与A通信超时，那么就认为该主节点宕机了，为了得出投票结果，主节点个数一般是奇数。
集群搭建（实践出真知嘛，加油！朋友们）
需要的环境
redis-4.0.14
redis-4.1.0.gem
Centos7
主从复制模式搭建
Redis已经发现了读写分离这个场景的普遍性，所以自身集成了读写分离供用户使用，我们只需要在redis的配置文件里面加上一条slaveof host port语句进行配置即可。

之前已经在Centos里安装了redis了，所以我们直接开始搭建配置

1、停止运行的Redis

查找正在运行的redis服务

ps -ef | grep redis

在redis的bin目录下停止对应端口的redis服务

./redis-cli -h 127.0.0.1 -p 6379 shutdown

2、删除bin文件夹下的数据文件，并修改bin文件名为bin7001，同时更改bin7001中的redis.conf文件
首先我们看一下bin文件夹下的内容

其次删除数据文件

rm -rf appendonly.aof dump.rdb

更改文件夹名称后，修改redis.conf文件
（这里使用的是idea进行更改文件，之前的文章里也有过介绍）

更改成功后如下

3、修改bin文件夹为bin7001，并复制为一个bin7002

复制文件夹

修改bin7002的文件夹的redis.conf

port 7002
slaveof 192.168.100.129 7001

4、分别启动7001和7002

以下显示7001的启动过程，7002是一样的，记得7002再开一个Xhsell界面进行连接

可以通过如下命令可以看到启动的redis服务

启动服务器后，还需要启动客户端，才可以进行数据操作
-p 后的参数是redis服务所对应的端口号

5、置入数值看一下

这里我们看到7001是主节点，7002是从节点，也就是说如果在主节点里放入值，就可以在从节点中查到
当我们尝试在7002节点中放入值时就会报错

但是如果在7001放入值就不会出现这种错误

这就实现了读写分离

6、一个主节点可以有多个节点

 

所以我们再复制一个bin7003，并删除复制的数据文件，方便它生成自己的数据文件

记得更改端口号

因为是复制的7002，所以redis.conf中已经有，说明7003是7001的从节点

slaveof 192.168.100.129 7001

启动7003服务

可以看到7003中可以获得7001中的值

ps:可以使用info命令查看当前节点的信息

如下是7003的信息，可以看到是从节点

高可用演示

高可用是分布式系统架构中必须考虑的因素之一，它可以减少系统所不能提供服务的时间。我理解它为如果一个挂掉了，还有其他的来自动补位，减少系统的宕机时间。
保证高可用通常遵循以下几点：

单点是系统高可用最大的敌人，在系统设计中应该避免单点
通过架构设计而保证系统高可用的核心准则是冗余
每次出现故障时需要人工介入恢复，会增加系统的不不可用时间，实现自动故障转移

我们将7001主节点手动停止

进入从节点使用info查看状态，可以看到主节点宕机

 

然后我们通过命令slaveof no one将7002升级主节点

使用info可以看到7002节点状态

可以看到当前节点无从节点，这是因为7003还不知道主节点成为了7002，那我们限制告诉它

查看状态

主节点升级后我们进行数据置入，看看效果

 

哨兵机制集群搭建
1、复制哨兵机制的配置文件并进行更改

在redis解压包解压后的文件中找到哨兵机制的配置文件

进入到redis文件夹中，将sentinel.conf配置文件复制到该文件夹

更改sentinel.conf文件中的如下字段

bind 0.0.0.0 
# 设定主节点名和地址，1 为失效的投票数
sentinel monitor mymaster 192.168.200.129 7001 1 
# 设置Sentinel认为服务器已经断线所需的毫秒数。
sentinel down-after-milliseconds mymaster 10000 
# 设置failover（故障转移）的过期时间。当failover开始后，在此时间内仍然没有触发任何failoer操作，当前sentinel 会认为此次failoer失败。
sentinel failover-timeout mymaster 60000 
# 设置在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1

2、关闭所有redis服务并重新启动redis服务，同时启动sentinel

进入到最原始的文件夹的src，即redis-4.0.14解压后的文件夹

redis-sentinel就是哨兵服务，然后启动

3、关闭主节点后的哨兵服务

进入7001主节点结束服务

哨兵机制会将从节点中的一个推选为主节点

重新启动7001

可以看到哨兵机制中7001已经重新加入集群，并且以7003作为主节点

我们使用info查看7001节点状态，会发现7001变成了从节点