【Redis 进阶之路】3. Redis 主从 以及哨兵

Redis 主从 以及哨兵

单实例Redis 不足：

上述的是一个单实例的Redis。 我们可以先分析下有哪些不足：

1. 单点故障 （是每个单实例必须面对的问题）
2. 容量有限 （Redis毕竟是缓存型数据库，容量取决于服务器分配的容量，但容量毕竟是有限的）
3. 压力大（如果出现高并发的场景，所有查询的压力都集中在Redis上）

所以我们的目的就是针对每个不足进行修复。

我们先来了解下 一些前置知识。

Redis 主备 认识

以上示意图就是主备 大致含义。

• 从一定程度上主备解决了单实例的单点故障。因为如果主Redis 如果因为某些原因停止提供服务，可以启动备Redis 继续工作。

• 但是依旧无法解决容量有限 以及压力大 的问题。因为从始至终都是一台Redis实例在工作。

Redis 主从 认识

以上示意图就是主从的大致含义

• 因为一旦master Redis停止服务后，slave Redis可以晋升为master，继续提供服务。所以给单点故障提供了保障
• 部署主从后，一般来说master 节点负责写数据。slave 节点服务读数据。这样可以有效的避免所有socket请求，都访问一个节点，从而降低了压力。

一般我们生产环境中会部署主从。所以我们会以主从来做详细的讲解

数据的一致性

保证数据的一致性是分布式部署的通病。按主从部署来讲，虽然数据已经写入到master 节点，但是需要master节点往slave 节点同步数据。在这个同步的过程中可能因为网络等种种原因，无法正常的同步。这就面临着数据一致性的问题。

接下来我们分析几种数据一致性的方案：

强一致性

如果想要实现数据的强一致性，master节点必须等待slave节点返回正确的结果。但是实际的业务场景中，会遇到各种问题导致slave节点延迟 或是 无法返回正确的数据，所以相当于master节点写数据失败。使用这种方式会破坏高可用

弱一致性

其实弱一致性的本质就是：通过异步的形式给slave节点发送数据。如果数据发送失败了，会导致主从数据不一致。

最终一致性

其实最终一致性是在弱一致性的基础上做了升级。我们可以利用一些特殊的手段，最大可能性保证数据完整的传输。

比如：master节点可以将数据以同步阻塞的方式，传递给kafka. 由kafka给每个slave节点发送数据。有可能在某一个时点数据是不一致的，但是最终数据是一致性的。

因为kafka给slave节点传递数据是需要时间的，如果此时间段内，数据的查询是高并发的，有可能出现部分用户拿到的数据不一致，分别是同步前 以及同步后的数据。

主从配置过程

接下俩我们实操下主从的配置过程：

步骤1：关闭Redis

也许服务器上启动了redis，如果再配置相同的端口，会出现一些意想不到的情况，所以我们先将redis关闭掉。

通过上述截图中我们会发现仍然有redis 占用6379端口。所以我们需要将其关闭掉，下面列举出两种方式任意选择：

方案 1

直接通过kill命令杀死进程。

kill -9 19191

通过cli 关闭redis

[root@VM-8-3-centos bin]# pwd
/opt/redis/bin
[root@VM-8-3-centos bin]# ./redis-cli shutdown
[root@VM-8-3-centos bin]# ps aux | grep redis
root     20135  0.0  0.0 112812   980 pts/0    S+   15:40   0:00 grep --color=auto redis
[root@VM-8-3-centos bin]#

步骤2：配置主从的前置工作

创建文件

cd /opt
mkdir -p redis-replica/master
mkdir -p redis-replica/slave1
mkdir -p redis-replica/slave2

复制redis 配置文件

这里我们直接使用shell 来移动文件

1. 创建并编辑 sh文件

vi mv-redis.sh

2. 直接将下面的内容复制到sh中

#!/bin/bash

cp -r /opt/redis/bin/* /opt/redis-replica/master
cp -r /opt/redis/bin/* /opt/redis-replica/slave1
cp -r /opt/redis/bin/* /opt/redis-replica/slave2

3. 通过命令执行shell

/bin/bash mv-redis.sh

步骤3：修改配置文件

为了不影响我们之前的单机版Redis，我们修改主从的配置

修改master 节点配置

修改前

# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6379

修改后

# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6380

修改slave1 节点配置

修改前

# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6379

修改后

# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6381

指定 master节点：我们需要在slave 配置文件中指定master节点

修改前

# 3) Replication is automatic and does not need user intervention. After a
#    network partition replicas automatically try to reconnect to masters
#    and resynchronize with them.
#
# replicaof <masterip> <masterport>

修改后

# 3) Replication is automatic and does not need user intervention. After a
#    network partition replicas automatically try to reconnect to masters
#    and resynchronize with them.
#
replicaof 127.0.0.1 6380

如果是不同的服务器。此处的127.0.0.1 可以修改为 指定的IP。 但是如果服务器上有密码就需要指定字段masterauth

修改slave2 配置文件

跟slave1 修改方式保持一致。只不过端口为6382

步骤4：启动服务

这次我们还是通过shell 进行启动以及关闭

#!/bin/bash

cd /opt/redis-replica/master
./redis-server ./redis.conf


cd /opt/redis-replica/slave1
./redis-server ./redis.conf


cd /opt/redis-replica/slave2
./redis-server ./redis.conf

执行shell

cd /opt/redis-replica
/bin/bash setup.sh

通过上述截图中我们看到，我们的多个redis 实例是启动成功的。

步骤5：查看 启动状态

步骤6：查看 主从信息

我们是可以通过命令info replication 来查看在master节点中 追随了几个slave节点。

主节点设置值

从节点可以读取

步骤7：主从配置总结

如果看到这里，以为主从配置就结束了吗？不不不，如果以为就这样结束了， 那就大错特错了。上述步骤虽然进行了主从部署，但是master节点负责写数据，slave 节点负责读数据。如果master节点宕机了，也就是意味着Redis就不具备写的功能，基本算是废了。

如果是人工发现master节点宕机了，会将slave节点升级为master节点，其他的slave节点跟随新的master节点。

那么我们接下来分析的哨兵，就实现了该功能。应该由人做的事情，将其交给第三方插件做

哨兵

在主从部署中默认是只有主节点具备写的能力，而从节点只能读。如果主宕机，整个节点不具备写能力。但是如果这是让一个从变成主，整个节点就可以继续工作。即使之前的主恢复过来也当做这个节点的从即可。

Redis的哨兵就是帮助监控master 节点的，当节点出现宕机等情况，帮助重新选取主。

Redis中哨兵支持单哨兵和多哨兵。单哨兵是只要这个哨兵发现master宕机了，就直接选取另一个master。而多哨兵是根据我们设定，达到一定数量哨兵认为master宕机后才会进行重新选取主。我们以多哨兵演示

多哨兵模式下，选择几个合适呢？？？

此时我们的多哨兵节点有5个

全部哨兵节点

当master节点因为某种原因停止服务，可能所有的哨兵都检测到了。但是因为网络原因无法进行汇总，导致4个哨兵认为master宕机了，一个哨兵迟迟没有回应。

这种部署方式 有点类似于 数据强一致性。会破坏可用性。

一个哨兵节点

1. 如果是一个哨兵就可以判断master 节点是否宕机的话，会造成判断结果不精准，因为会有很多原因造成哨兵判断失误，例如：网络
2. 但是如果每个哨兵结果都不同的话，会发生一种情况：脑裂。

n/2+1 节点

1. 为了增加结果的准确性，我们建议是过半的哨兵如果判断master 节点宕机的话，那master 节点就是宕机了
2. 这种方式也避免了脑裂的情况发生。

如果是部署4台哨兵的话，>=3台认为master宕机了，我们就认为宕机
如果是部署5台哨兵的话，>=3台认为master宕机了，我们就认为宕机

所以为了更好的分区容忍性，我们是建议部署奇数台哨兵。

哨兵配置过程

创建目录

mkdir -p /opt/redis-replica/sentinel
cp /opt/redis-replica/master/redis-sentinel /opt/redis-replica/sentinel

从之前的解压目录 复制配置文件

cp /tmp/soft/redis-5.0.14/sentinel.conf /opt/redis-replica/sentinel/

复制多份配置文件，修改配置文件

三个配置文件 修改内容类似，如下内容：

port 26379
daemonize yes
logfile "/opt/redis-replica/sentinel/26379.log"
sentinel monitor mymaster 127.0.0.1 6380 2

启动sentinel

杀死master节点，主动自动切换

等杀死master节点后，等待一段时间后，通过哨兵，第一个从节点升级为master节点了。