分布式Redis集群系列【上】
1.集群概述
2.主从复制
3.哨兵机制
====================================
一. 集群概述
先来简单了解下redis中提供的集群策略, 虽然redis有持久化功能能够保障redis服务器宕机也能恢复并且只有少量
的数据损失，但是由于所有数据在一台服务器上，如果这台服务器出现硬盘故障，那就算是有备份也仍然不可避免
数据丢失的问题。
在实际生产环境中，我们不可能只使用一台redis服务器作为我们的缓存服务器，必须要多台实现集群，避免出现
单点故障；
redis集群演变过程
-
单机版
核心技术：持久化
持久化是最简单的高可用方法（有时甚至不被归为高可用的手段），主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。 -
复制
复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷是故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。 -
哨兵
在复制的基础上，哨兵实现了自动化的故障恢复。缺陷是写操作无法负载均衡；存储能力受到单机的限制。 -
集群
通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案
二. 主从复制
复制的作用是把redis的数据库复制多个副本部署在不同的服务器上，如果其中一台服务器出现故障，也能快速迁
移到其他服务器上提供服务。 复制功能可以实现当一台redis服务器的数据更新后，自动将新的数据同步到其他服
务器上
主从复制就是我们常见的master/slave模式， 主数据库可以进行读写操作，当写操作导致数据发生变化时会自动将
数据同步给从数据库。而一般情况下，从数据库是只读的，并接收主数据库同步过来的数据。 一个主数据库可以有
多个从数据库
在redis中配置master/slave是非常容易的，只需要在从数据库的配置文件中加入slaveof 主数据库地址 端口。 而
master 数据库不需要做任何改变
准备两台服务器，分别安装redis ， server1 server2
- 在server2的redis.conf文件中增加 slaveof server1-ip 6379 、 同时将bindip注释掉，允许所 有ip访问
- 启动server2
- 访问server2的redis客户端，输入 INFO replication
- 通过在master机器上输入命令，比如set foo bar 、 在slave服务器就能看到该值已经同步过来了
原理
全量复制
Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤
完成上面几个步骤后就完成了slave服务器数据初始化的所有操作，savle服务器此时可以接收来自用户的读请求。
master/slave 复制策略是采用乐观复制，也就是说可以容忍在一定时间内master/slave数据的内容是不同的，但是
两者的数据会最终同步。具体来说，redis的主从同步过程本身是异步的，意味着master执行完客户端请求的命令
后会立即返回结果给客户端，然后异步的方式把命令同步给slave。
这一特征保证启用master/slave后 master的性能不会受到影响。
但是另一方面，如果在这个数据不一致的窗口期间，master/slave因为网络问题断开连接，而这个时候，master
是无法得知某个命令最终同步给了多少个slave数据库。不过redis提供了一个配置项来限制只有数据至少同步给多
少个slave的时候，master才是可写的：
min-slaves-to-write 3 表示只有当3个或以上的slave连接到master，master才是可写的
min-slaves-max-lag 10 表示允许slave最长失去连接的时间，如果10秒还没收到slave的响应，则master认为该
slave以断开
全量复制消耗
- bgsave时间
- rdb文件网络传输
- 从节点请求请求数据时间
- 从节点加载rdb的时间
- 可能的aof重写时间
缺点
1.由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
2.当主机宕机之后，将不能进行写操作，需要手动将从机升级为主机，从机需要重新制定master
简单总结：
- 一个master可以有多个Slave
- 一个slave只能有一个master
- 数据流向是单向的，只能从主到从
增量复制
从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的
地方，继续复制下去，而不是从头开始复制一份
master node会在内存中创建一个backlog，master和slave都会保存一个replica offset还有一个master id，offset
就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续
复制
但是如果没有找到对应的offset，那么就会执行一次全量同步
无硬盘复制
前面我们说过，Redis复制的工作原理基于RDB方式的持久化实现的，也就是master在后台保存RDB快照，slave接
收到rdb文件并载入，但是这种方式会存在一些问题
- 当master禁用RDB时，如果执行了复制初始化操作，Redis依然会生成RDB快照，当master下次启动时执行该
RDB文件的恢复，但是因为复制发生的时间点不确定，所以恢复的数据可能是任何时间点的。就会造成数据出现问
题 - 当硬盘性能比较慢的情况下（网络硬盘），那初始化复制过程会对性能产生影响
因此2.8.18以后的版本，Redis引入了无硬盘复制选项，可以不需要通过RDB文件去同步，直接发送数据，通过以
下配置来开启该功能
repl-diskless-sync yes
master**在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了
三. 哨兵机制
在前面讲的master/slave模式，在一个典型的一主多从的系统中，slave在整个体系中起到了数据冗余备份和读写
分离的作用。当master遇到异常终端后，需要从slave中选举一个新的master继续对外提供服务，这种机制在前面
提到过N次，比如在zk中通过leader选举、kafka中可以基于zk的节点实现master选举。所以在redis中也需要一种
机制去实现master的决策，redis并没有提供自动master选举功能，而是需要借助一个哨兵来进行监控
哨兵概述
顾名思义，哨兵的作用就是监控Redis系统的运行状况，哨兵是一个独立的进程，它的功能包括两个
- 监控(monitoring)：Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
- 自动故障转移(Automatic failover)：master出现故障时自动将slave数据库升级为master
- 提醒(Notifation)：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
为了解决master选举问题，又引出了一个单点问题，也就是哨兵的可用性如何解决，在一个一主多从的Redis系统
中，可以使用多个哨兵进行监控任务以保证系统足够稳定。此时哨兵不仅会监控master和slave，同时还会互相监
控；这种方式称为哨兵集群，哨兵集群需要解决故障发现、和master决策的协商机制问题
sentinel之间的相互感知
sentinel节点之间会因为共同监视同一个master从而产生了关联，一个新加入的sentinel节点需要和其他监视相同
master节点的sentinel相互感知，首先
- 需要相互感知的sentinel都向他们共同监视的master节点订阅channel:sentinel:hello
- 新加入的sentinel节点向这个channel发布一条消息，包含自己本身的信息，这样订阅了这个channel的sentinel
就可以发现这个新的sentinel - 新加入得sentinel和其他sentinel节点建立长连接
基本原理
关于哨兵的原理，关键是了解以下几个概念：
主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。
客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。
需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。
定时任务：每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：
- 每10秒通过向主从节点发送info命令获取最新的主从结构；
发现slave节点
确定主从关系 - 每2秒通过发布订阅功能获取其他哨兵节点的信息；SUBSCRIBE c2 PUBLISH c2 hello-redis
交互对节点的“看法”和自身情况 - 每1秒通过向其他节点发送ping命令进行心跳检测，判断是否下线（monitor）。
心跳检测，失败判断依据
选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。
监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。选举的具体过程这里不做详细描述，一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。
故障转移：选举出的领导者哨兵，开始进行故障转移操作，该操作大体可以分为3个步骤：
在从节点中选择新的主节点：选择的原则是，
- 首先过滤掉不健康的从节点；
- 然后选择优先级最高的从节点（由replica-priority指定）；如果优先级无法区分，
- 则选择复制偏移量最大的从节点；如果仍无法区分，
- 则选择runid最小的从节点。
更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。
将已经下线的主节点（即6379）保持关注，当6379从新上线后设置为新的主节点的从节点
master的故障发现
sentinel节点会定期向master节点发送心跳包来判断存活状态，一旦master节点没有正确响应，sentinel会把
master设置为“主观不可用状态”，然后它会把“主观不可用”发送给其他所有的sentinel节点去确认，当确认的
sentinel节点数大于>quorum时，则会认为master是“客观不可用”，接着就开始进入选举新的master流程；但是
这里又会遇到一个问题，就是sentinel中，本身是一个集群，如果多个节点同时发现master节点达到客观不可用状
态，那谁来决策选择哪个节点作为maste呢？这个时候就需要从sentinel集群中选择一个leader来做决策。而这里
用到了一致性算法Raft算法、它和Paxos算法类似，都是分布式一致性算法。但是它比Paxos算法要更容易理解；
Raft和Paxos算法一样，也是基于投票算法，只要保证过半数节点通过提议即可;
动画演示地址：http://thesecretlivesofdata.com/raft/
配置实现
通过在这个配置的基础上增加哨兵机制。在其中任意一台服务器上创建一个sentinel.conf文件，文件内容
sentinel monitor name ip port quorum
其中name表示要监控的master的名字，这个名字是自己定义。 ip和port表示master的ip和端口号。 最后一个1表示最低 通过票数，也就是说至少需要几个哨兵节点统一才可以，后面会具体讲解
port 6040
sentinel monitor mymaster 192.168.11.131 6379 1
sentinel down-after-milliseconds mymaster 5000 --表示如果5s内mymaster没响应，就认为SDOWN
sentinel failover-timeout mymaster 15000 --表示如果15秒后,mysater仍没活过来，则启动failover，从剩下的
slave中选一个升级为master
两种方式启动哨兵
redis-sentinel sentinel.conf
redis-server /path/to/sentinel.conf --sentinel
哨兵监控一个系统时，只需要配置监控master即可，哨兵会自动发现所有slave；
这时候，我们把master关闭，等待指定时间后（默认是30秒），会自动进行切换，会输出如下消息
img
+sdown表示哨兵主管认为master已经停止服务了，+odown表示哨兵客观认为master停止服务了。关于主观和客
观，后面会给大家讲解。接着哨兵开始进行故障恢复，挑选一个slave升级为master
+try-failover表示哨兵开始进行故障恢复
+failover-end 表示哨兵完成故障恢复
+slave表示列出新的master和slave服务器，我们仍然可以看到已经停掉的master，哨兵并没有清楚已停止的服务
的实例，这是因为已经停止的服务器有可能会在某个时间进行恢复，恢复以后会以slave角色加入到整个集群中
注：希望大家技术越来越6p
