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

Posted 2023-04-02 全栈切图仔

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节点了。

Redis进阶之路

Redis进阶之路-快速入门-linux部署

• 1. linux部署
• 2. 安装redis
• 3.启动redis
• 4. 检查Redis是否正常工作
• 5. 保护Redis
• 6. 小试牛刀-应用程序中使用
• 7. 更正确安装
• • 7.1 使用init脚本示例
• 8.测试（确保一切正常）
• 参考链接

1. linux部署

这是一份快速入门文档，针对 没有Redis经验的人员。针对如下方面：

• 下载并编译Redis并开始
• 使用redis-cli访问服务器
• 在应用程序中使用redis
• 了解redis持久性的工作原理
• 更正确地安装redis

2. 安装redis

建议使用redis源代码进行编译。因为也很方便，且能保证更新的版本。bash命令如下 ：

wget http://download.redis.io/redis-stable.tar.gz
tar xvzf redis-stable.tar.gz
cd redis-stable
make

此时，可以输入make test测试，也可以路过。编译后，src目录有命令文件生成：

• redis-server 是server本身
• redis-sentinel 哨兵（监视和故障转移）
• redis-cli 是与redis交互的命令行工具
• redis-benchmark 检查性能
• redis-check-aof 和 redis-check-rdb日志记录 （在罕见的数据文件损坏事件中很有用）

最好使用如下 命令将redis服务器和命令行工具复制到环境变量中：

 sudo cp src/redis-server /usr/local/bin/
 sudo cp src/redis-cli /usr/local/bin/

或者使用sudo make install

3.启动redis

最简单方法是不带参数地执行redis-server

在上面的示例，在没有任务显式配置文件的情况下，用默认参数启动。对于生产环境，应该了解并使用配置文件。位于根目录中的模板配置文件 redis.conf

4. 检查Redis是否正常工作

外部程序使用TCP套接字和Redis特定协议与Redis对话。为了更方便使用，Redis提供命令行工具redis-cli。检查命令如下 ：

redis-cli 
>ping #PONG
>set mykey somevalue # cli会自动提示，方便的
>get mykey # "somevalue"

可以参考基本Redis命令可以阅读

5. 保护Redis

默认Redids绑定所有接口，并且完全不进行身份验证。如果在内网，那就很好。但是她未经任何加固就暴露在Internet上，那将是一个很大的安全隐患。可以通过以下步骤提高安全性。

1. 确认Redis用于侦听连接的接口(默认6379，集群模式下16379 、Sentinel是26379）已开户防火墙。
2. 使用bind directive 。比如本地访问Redis,则仅用回环地址（127.0.0.1)，依此类推。
3. 使用 requirepas选项，以便客户端使用AUTH命令进行身份验证。
4. 如果 环境需要加密，请使用spiped 或者其它SSL加密服务器与客户端之前通信。

6. 小试牛刀-应用程序中使用

java示例

7. 更正确安装

两种不同的选择

• 使用命令行
• 使用init脚本，自动重启

7.1 使用init脚本示例

假设已经在/usr/local/bin 下复制redis-server和redis-cli可执行文件。

• 创建目录，用于存储Redis配置文件和数据

sudo mkdir /etc/redis
sudo mkdir /vaar/redis

• 在utils目录下Redis安装 目录中找初始化脚本复制到/etc/init.d中。建议使用Redis实例的商品名称来调用。例如：

sudo cp /utils/redis_init_scritpt /etc/init.d/redis_6379

• 编辑初始化脚本

sudo vi /etc/init.d/redis_6379

• 根据使用的端口修改REDISPORT。pid文件路径和配置文件名取决于端口号。例如：

sudo cp redis.conf /etc/redis/6379.conf

• 在/var/redis中创建一个目录，它将用作Redis实例的数据 和工作目录：

sudo make /var/redis/6379

• 编辑配置文件，确保执行以下更改：
• • 将守护程序 设置为是(默认否）
• • 将pidfile设置为/var/run/redis_6379.pid(如果需要，请修改端口）
• • 设置日志级别
• • 将目录设置为==/var/redis/6379 ==
• 最后，使用以下命令将新的Redis初始化脚本添加到默认运行级别：

sudo update-rc.d redis_6379 defaults

现在可以尝试通过以下方式运行实例

sudo /etc/init.d/redis_6379 start

8.测试（确保一切正常）

• 使用redis-cli ping通
• 使用redis-cli save 进行测试保存，并检查 转储文件是否在/var/redis/6379/_{会生成dump.rdb文件}
• 检查 是否生成 对应级别的日志文件
• 在不影响其它应用的情况下，可以确保重新启动后一切仍然正常。
  ps: 以上只是最基本的配置，一些理想重要的配置参数，可以参考redis.conf中的大量注释文件

参考链接

• 官方文档
• 安装文档
• 不同语言示例大全