Redis的同步（主从复制）和Redis Sentinel

　　Redis的同步可以让其他服务器拥有一个不断更新的数据副本，从而使拥有数据副本的服务器可以处理客户端发出的读请求。

1.Redis同步的方法：

　　我们可以通过发送SLAVEOF host port命令来让服务器开始同步一个新的主服务器（需要注意的一点是，当一个从服务器连接至主服务器的时候，从服务器原有的所有数据将被清空）。

redis 127.0.0.1:6380> slaveof 127.0.0.1 6379
OK

　　上述方式中，如果从服务器重启之后，它们之间的主从关系将终止。如果想要长期保持两个服务器之间的主从关系，可以使用下面的方法。

　　如果我们在启动Redis的时候，指定了一个包含slaveof host port的配置文件，那么Redis服务器将根据该配置指定的IP地址和端口号来连接主服务器。　　

slaveof <masterip> <masterport>    指定master的ip和port
masterauth <master-password>       master有验证的情况下
slave-read-only yes                设置slave为只读模式

　　Redis2.8以后，可以在配置文件中设置，主服务器只有当有N个从服务器处于连接状态时，接受写操作。

min-slaves-to-write 3
min-slaves-max-lag 10

　　最后，如果想要让从服务器断开与主服务器的连接，可以通过向从服务器发送SLAVEOF no one来实现。　　

redis 127.0.0.1:6380> slaveof no one

　　

2.Redis同步的过程：

　　从服务器连接一个主服务器的时候，主服务器会创建一个快照文件并将其发送至从服务器，下表中详细介绍了当一个从服务器连接至主服务器的过程。　　

从服务器连接主服务器时的步骤

步骤	主服务器操作	从服务器操作
1	（等待进入命令）	连接（或者重连接）主服务器，发送SYNC命令
2	开始执行BGSAVE，并使用缓冲区记录BGSAVE之后执行的所有写命令	根据配置选项来决定是继续使用现有数据（如果有的话）来处理客户端的请求，还是向发送请求的客户端发送错误
3	BGSAVE执行完毕，向从服务器发送快照文件，并在发送期间继续使用缓冲区记录被执行的写命令	丢弃所有的旧数据（如果有的话），开始载入主服务器发来的快照文件
4	快照文件发送完毕，开始向从服务器发送存储在缓冲区里面的写命令	完成对快照文件的载入操作，想往常一样开始接受客户端命令请求
5	缓冲区存储的写命令发送完毕，从现在开始，每执行一个写命令，就向从服务器发送相同的写命令	执行主服务器发送来的所有存储在缓冲区的写命令，从现在开始，接收并执行主服务器传来的每个写命令

　　通过上表所示的办法，Redis在同步进行期间也会尽可能的处理接收到的命令请求。

　　当有多个从服务器连接（或者重连接）主服务器的时候，主服务器会创建一个快照文件并发送给这些从服务器，从效率的角度来说这种做法非常好，因为它可以避免创建多个快照，但是同时向多个从服务器发送快照文件，可能会使主服务器的延迟变高，甚至导致主从关系断开。解决这个问题的其中一个方法是通过树状结构的主从同步方式来完成同步。

　　

 

3.Redis Sentinel

　　3.1 简介：

　　Redis-Sentinel是Redis官方推荐的高可用性(High Availability)解决方案，sentinel是用于监控Redis集群中master状态的工具，已被集成在Redis2.4及以后的版本当中，当用Redis-Sentinel做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主从切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动的主从切换。

　　3.2 支持集群：

　　我们可以使用单个sentinel来监控Redis，但是这样的话，当sentinel进程宕掉后Redis将失去监控。可以通过运行sentinel集群来解决这个问题，这样有几个好处：

• 即使有一些sentinel进程宕掉了，依然可以进行Redis集群的主从切换；
• 如果只有一个sentinel进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现Redis集群的主备切换。
• 如果有多个sentinel，Redis的客户端可以随意地连接任意一个sentinel来获得关于Redis集群中的信息。

　　3.3 版本：　　

　　Sentinel当前最新的稳定版本称为Sentinel 2(与之前的Sentinel 1区分开来）。随着redis2.8的安装包一起发行。安装完Redis2.8后，可以在redis2.8/src/里面找到Redis-sentinel的启动程序。

如果你使用的是redis2.6(sentinel版本为sentinel 1)，你最好应该使用redis2.8版本的sentinel 2，因为sentinel 1有很多的Bug，已经被官方弃用，所以强烈建议使用redis2.8（或以上）以及sentinel 2。 

 　　3.4 运行sentinel有两种方式：

• 第一种

  redis-sentinel /path/to/sentinel.conf

• 第二种

  redis-server /path/to/sentinel.conf --sentinel

　　以上两种方式，都必须指定一个sentinel的配置文件sentinel.conf，如果不指定，将无法启动sentinel。sentinel默认监听26379端口，所以运行前必须确定该端口没有被别的进程占用。

　　3.5 配置sentinel：

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel parallel-syncs mymaster 1

　　第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。

　　不过需要注意的是，无论你设置要多少个 Sentinel 同意才能判断一个服务器失效，一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持，才能发起一次自动故障迁移，也就是说，如果只有少数（minority）Sentinel 进程正常运作的情况下，是不能执行自动故障迁移的。

　　down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数（判定为主观下线SDOWN）。
　　parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长，但越大就意味着越多的从服务器因为复制而不可用。可以通过将这个值设为 1 来保证每次只有一个从服务器处于不能处理命令请求的状态。

　　3.6 主观下线和客观下线：

　　主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
　　客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。

　　客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商， 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。
　　只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。

　　3.7 Sentinel的工作方式：

　　1. 每个 Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。

　　2. 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 那么这个实例会被 Sentinel 标记为主观下线。 一个有效回复可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。
　　3. 如果一个主服务器被标记为主观下线， 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。
　　4. 如果一个主服务器被标记为主观下线， 并且有足够数量的 Sentinel （至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断， 那么这个主服务器被标记为客观下线。
　　5. 在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。 当一个主服务器被 Sentinel 标记为客观下线时， Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
　　6. 当没有足够数量的 Sentinel 同意主服务器已经下线， 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时， 主服务器的主管下线状态就会被移除。　　

　　3.8 Sentinel命令：

　　PING ：返回 PONG 。

　　SENTINEL masters ：列出所有被监视的主服务器，以及这些主服务器的当前状态；

　　SENTINEL slaves <master name> ：列出给定主服务器的所有从服务器，以及这些从服务器的当前状态；

　　SENTINEL get-master-addr-by-name <master name> ： 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作， 或者针对这个主服务器的故障转移操作已经完成， 那么这个                     命令返回新的主服务器的 IP 地址和端口号；
　　SENTINEL reset <pattern> ： 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清楚主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel ；
　　SENTINEL failover <master name> ： 当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移。　 

　　3.9 Sentinel状态持久化： 

　　snetinel的状态会被持久化地写入sentinel的配置文件中。每次当收到一个新的配置时，或者新创建一个配置时，配置会被持久化到硬盘中，并带上配置的版本戳（配置文件中的sentinel current-epoch选项）。这意味着，可以安全的停止和重启sentinel进程。

 　　

　　参考：

　　http://www.cnblogs.com/linjiqin/p/3568677.html

　　http://www.cnblogs.com/Xrinehart/p/3501372.html

　　https://segmentfault.com/a/1190000002680804

 

　　转载请注明出处