Redis主从复制+哨兵环境搭建

一、文章摘要

本文用于记录Redis主从复制+哨兵环境的搭建的整个过程

二、主从复制

1、主从复制介绍

在 Redis 复制的基础上，使用和配置主从复制非常简单，能使得从 Redis 服务器（下文称 slave）能精确得复制主 Redis 服务器（下文称 master）的内容。每次当 slave 和 master 之间的连接断开时， slave 会自动重连到 master 上，并且无论这期间 master 发生了什么， slave 都将尝试让自身成为 master 的精确副本。这个系统的运行依靠三个主要的机制：

• 当一个 master 实例和一个 slave 实例连接正常时， master 会发送一连串的命令流来保持对 slave 的更新，以便于将自身数据集的改变复制给 slave ：包括客户端的写入、key 的过期或被逐出等等。
• 当 master 和 slave 之间的连接断开之后，因为网络问题、或者是主从意识到连接超时， slave 重新连接上 master 并会尝试进行部分重同步：这意味着它会尝试只获取在断开连接期间内丢失的命令流。
• 当无法进行部分重同步时， slave 会请求进行全量重同步。这会涉及到一个更复杂的过程，例如 master 需要创建所有数据的快照，将之发送给 slave ，之后在数据集更改时持续发送命令流到 slave。
  

2、环境搭建

1、配置

节点	IP
节点1（Master节点）	192.168.111.139
节点2（Salve节点）	192.168.111.140
节点3（Salve节点）	192.168.111.141

2、安装Redis

3、搭建主从复制有两种方式
第一种：命令行形式
（1）首先启动Master节点，先以前台形式进行启动方便之后查看对应的日志输出。


（2）以命令形式启动节点2和3
命令如下： redis-server --replicaof 192.168.111.139 6379


可以看到输入命令后，Salve节点会开始连接Master节点，当连接成功之后Master会把数据同步给Salve节点
我们在回过头来看看Master节点，Master节点接到连接之后，把数据同步给Salve节点。


方式二：通过配置文件
通过修改配置文件里的replicaof（低版本可能叫salveof）

3、插入数据

上文说了搭建了主从复制的集群后，Master节点即可以读也可以写而Salve节点则只能读。时间是检验真理的唯一标准，现在让我们尝试一下；首先我们在Master节点进行读写。

1、Master节点

可以看到在Master节点（192.168.111.139）上即可以读也可以写。

2、Salve节点

接下来我们试在Salve节点，Redis在连接远程服务器的时候可能会出现在这个错误 No route to host


此时需要检查一下远程的Redis是否开起来protect模式，同时注释掉bind；（如果还是不行可以在远程服务器上执行sudo iptables -F 用于删除过滤规则，当然实际工作中不要这么用）


我们先尝试查询，可以看到可以正常查询。


接下来我们尝试新增数据，可以看到Redis直接报错了。不能再只读的节点进行写操作；当然这也是可以配置的，在配置文件里有**replica-read-only yes，**这么一行参数，默认是开启Salve节点只读。

4、小结

在这一节中我们搭建了一个最简的1主2从的模式，当然还有其他的模式多主多从。整体流程相对简单，有两种方式，一种是命令行形式一种是配置文件的的形式，当然实际工作中更推荐使用配置文件的形式。
到目前为止我们知道了Master节点会把数据全量同步到Salve节点，但是仔细想来这个集群还是很脆弱的。比如如果Master节点挂了怎么办？那其他两个节点只能干瞪眼啥都干不了，此时就需要引入另一个技术Sentinel（哨兵）。

三、Sentinel

1、Sentinel简介

Redis Sentinel provides high availability for Redis when not using Redis Cluster.
Redis Sentinel also provides other collateral tasks such as monitoring, notifications and acts as a configuration provider for clients.
This is the full list of Sentinel capabilities at a macroscopic level (i.e. the big picture):

• Monitoring. Sentinel constantly checks if your master and replica instances are working as expected.
• Notification. Sentinel can notify the system administrator, or other computer programs, via an API, that something is wrong with one of the monitored Redis instances.
• Automatic failover. If a master is not working as expected, Sentinel can start a failover process where a replica is promoted to master, the other additional replicas are reconfigured to use the new master, and the applications using the Redis server are informed about the new address to use when connecting.
• Configuration provider. Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redis master responsible for a given service. If a failover occurs, Sentinels will report the new address.

译文：当不使用Redis Cluster时，Redis Sentinel为Redis提供了高可用性。

Redis Sentinel还提供其他附加任务，如监控、通知，并充当客户端的配置提供者。
以下是《哨兵》在宏观层面(即大局)的完整功能列表:
监控。Sentinel经常检查主实例和副本实例是否按预期工作。
通知。Sentinel可以通过API通知系统管理员或其他计算机程序，被监视的某个Redis实例出了问题。
自动故障转移。如果一个主服务器没有像预期的那样工作，Sentinel可以启动一个故障转移过程，其中一个副本被提升为主服务器，其他附加的副本被重新配置以使用新的主服务器，并且使用Redis服务器的应用程序在连接时被告知要使用的新地址。
配置提供者。Sentinel充当了客户端服务发现的权限来源:客户端连接到Sentinel以请求负责给定服务的当前Redis主服务器的地址。如果发生故障转移，Sentinels将报告新地址。

简单来在使用Redis Cluster的情况下，可以使用哨兵来保证Redis主从复制的可用性，当然为保证哨兵的高可用一般来说哨兵也会搭建集群。

2、简介

注意点：（摘自官网）
部署前需要了解的关于Sentinel的基本事项
要实现健壮的部署，您至少需要三个Sentinel实例。
这三个Sentinel实例应该被放置在被认为以独立方式失败的计算机或虚拟机中。例如，在不同的可用性分区上执行不同的物理服务器或虚拟机。
Sentinel + Redis分布式系统不保证在故障期间保留已确认的写，因为Redis使用异步复制。然而，也有一些方法可以部署Sentinel，使丢失写的窗口限制在某些时刻，同时也有其他不太安全的部署方法。
你的客户需要哨兵的支持。流行的客户端库有Sentinel支持，但不是全部。
如果您不经常在开发环境中进行测试，那么就不存在安全的HA设置，如果能够在生产环境中进行测试，则更好。您可能有一个错误配置，只有在太晚的时候才会显现出来(在凌晨3点，当您的主机停止工作时)。

3、环境搭建

本文打算搭建一个1主2从+3个哨兵的高可用Redis，开启哨兵也有两种方式，第一是将Redis本身作为哨兵，另一种是单独创建一个进程来充当哨兵，一般来说我们会选择第二种，因为使用第一种的话Redis本身就没有办法当数据库使用了。
步骤：
1、修改Sentinel配置文件，位于Redis解压目录下sentinel.conf


配置解析：
：mater节点的名称，可以任意但是不能包含特殊字符或者空格。
：要监控的节点所在的IP
：端口号
：master下线所需要的最少投票数，加入配置为2则当2个哨兵认为Master出故障后，就会下线，然后进行故障转移。
2、启动3个哨兵：（为了方便观察，这里不做后台启动）

命令：redis-sentinel /path/to/sentinel.conf

3、测试：此时3个哨兵已经搭建完成，此时我们把Master节点关闭并查看结果

从哨兵的日志中可以看出，哨兵已经检测出原来的主节点（192.168.111.139）已经宕机，并重新选举曾经某一个Salve（192.168.111.140）作为Master节点。
4、校验Salve节点是会否变为Master节点，可以看到当我们连到140这台服务器的时候，已经开读写了说明此时Salve节点已经升级为Master节点。


5、重启曾经的Master节点，曾经的Master节点在重新连接后变成了Salve节点

四、总结

今天的文章更多在于实操，我们着手搭建了一个1主2从+3个哨兵的高可用Redis。当然了这个模式只是实现了高可用，当发生错误时的故障转移。不过这个模式也是存在一定的局限性
（1）并没有解决单点Redis的容量问题，因为Slave节点是全量复制Master节点
（2）如果流量过大，并没有把流量分散到不同的Redis上，单机压力过大的问题也没有解决。
这几个问题也会在后续的文章中给出解决方案，希望对你有所帮助。

未完待续