基于Sentinel模式部署高可用Redis

最新推荐文章于 2024-04-30 09:56:30 发布

yield-bytes

最新推荐文章于 2024-04-30 09:56:30 发布

阅读量926

点赞数 1

分类专栏： Redis

本文链接：https://blog.csdn.net/pysense/article/details/103623768

版权

文章目录

在本博客前面的文章给出redis-cluster模式的配置和测试《一篇文章掌握redis-cluster原理及其部署、测试》，redis还有另外一种failover自动切换的部署方式，也即是本文给出的——Sentinel模式（哨兵模式），这两种方式部署的redis服务其实在普通的项目完全够用，例如个人在Django项目使用的Sentinel模式保证了”查询缓存服务以及一些频繁读取配置参数服务“的高可用。对于并发量大的需求，可以使用国内知名Codis——分布式Redis集群代理中间件，可配置规模更大的redis集群服务。

1、安装redis

为保持文章内容完整，这里给出redis的安装过程。两种方式，一种为yum 安装，另外一种下载包安装。这里选择bin包下载安装。目前redis稳定版为5.0.7，tar包为仅为1.7M，不愧为缓冲界的宠儿。安装包放在opt下，个人喜好将所有关开发的相关组件安装包放置于/opt目录，例如前面大数据各个组件的安装包，还是为了方便记忆、管理和查找。

[root@nn redis-5.0.7]# pwd
/opt/redis-5.0.7

$ wget http://download.redis.io/releases/redis-5.0.7.tar.gz
$ tar xzf redis-5.0.7.tar.gz
$ cd redis-5.0.7
$ make

将redis启动命令所在的src路径加入系统变量

[root@nn redis-5.0.7]# source ~/.bash_profile  
PATH=$PATH:$HOME/bin:/opt/redis-5.0.7/src/

查看版本

[root@nn opt]# redis-server -v
Redis server v=5.0.7 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=864a7319aeb56c9b

启动redis-server后台进程：

[root@nn opt]# redis-server &
[root@nn opt]# ps -ef |grep redis
root      91054  60098  0 11:47 pts/0    00:00:00 redis-server *:6379

[root@nn opt]# redis-cli 
127.0.0.1:6379> set msg 1
OK
127.0.0.1:6379> get msg
"1"

2、Sentinel 的配置说明

2.1 官网有关Sentinel模式的基本信息

The current version of Sentinel is called Sentinel 2，A stable release of Redis Sentinel is shipped since Redis 2.8.
Sentinels by default run listening for connections to TCP port 26379,
If you are using the redis-sentinel executable， you can run Sentinel
with the following command line:
redis-sentinel /path/to/sentinel.conf

redis要求启动Sentinel服务时必须带上其配置文件，否则直接返回启动失败。
启动Sentinel模式前的基本要求：

You need at least three Sentinel instances for a robust deployment.（至少3个Sentinel实例，多数票选举）
最好在不同物理机上或者虚拟机上启动每个Sentinel 实例（在测试环境下，当然也可在同一台服务器里面，启动不同端口的多个实例也可完成测试。）
Sentinel + Redis distributed system does not guarantee that acknowledged writes are retained during failures，since Redis uses asynchronous replication.（Sentinel+redis分布式集群环境下，节点出现故障时，不保证写一致性，因redis异步复制方式实现集群数据同步）

2.2 redis官网Sentinel模式说明

有些缩写需要说明：

Masters are called M1, M2, M3, …, Mn.
replicas are called R1, R2, R3, …, Rn (R stands for replica).（replica也就是slave角色，因为slave有歧视语义，很多中间件不再使用该词描述副角色，例如kafka备份分区的：replica）
Sentinels are called S1, S2, S3, …, Sn.
Clients are called C1, C2, C3, …, Cn.

首先看官方首推的 basic setup with three boxes:It is based on three boxes, each box running both a Redis process and a Sentinel process. 每个box代表一个redis节点，确认master失败的选票数为2

       +----+
       | M1 |
       | S1 |
       +----+
          |
+----+    |    +----+
| R2 |----+----| R3 |
| S2 |         | S3 |
+----+         +----+

Configuration: quorum = 2

If the master M1 fails, S2 and S3 will agree about the failure and will
be able to authorize a failover, making clients able to continue.

如果主redis M1宕机（哨兵S1当然也会挂掉），那么其他节点上哨兵S2和哨兵S3发现与S1心跳失败，两者一致同意此时进入故障转移，选举R2为新的master M2。

redis sentinel实现高可用，但也会在某种程度下有丢失有些写数据。例如下面的情况：客户端C1原来与M1连接，写入M1，当M1挂了，到M2起来的这个过程，C1在这一过程写的部分数据会丢失。

         +----+
         | M1 |
         | S1 | <- C1 (writes will be lost)
         +----+
            |
            /
            /
+------+    |    +----+
| [M2] |----+----| R3 |
| S2   |         | S3 |
+------+         +----+

以上情况可通过以下两个配置实现数据丢失最小化。that allows to stop accepting writes if a master detects thatit is no longer able to transfer its writes to the specified number of replicas。
这里用到replica关键字单词，在本博客前面kafka文章里面，kafka也有自己的replica名词，不过kafka的replica是指top 分区后的副本，redis这里replica是从服务器（开源界不建议使用slave这个带有歧视的单词）。通过以下设置，只有当前master主机至少还有一个alive的replica才准许外部客户端写入数据。

min-replicas-to-write 1
min-replicas-max-lag 10

3、一主两从的redis架构配置

第2部分的sentinel 2 高可用的前提是基于1主2两从的架构基础上实现的，如下架构，故首先得让一主两从的redis小集群跑起来

       +----+
       | M1 |
       | S1 |
       +----+
          |
+----+    |    +----+
| R2 |----+----| R3 |
| S2 |         | S3 |
+----+         +----+

Configuration: quorum = 2

M1为1主，两从：R2、R3，在此基础上，每个节点运行sentinel进程，即可实现redis高可用架构。

3.1 配置主从的redis.conf文件

redis的配置文件的注释有分段说明，这里列出仅需修改的地方：
”一主redis“的配置说明：

################################## NETWORK 
# 绑定本机IP
bind 182.0.0.10
################################# GENERAL
# 后台守护进程运行
daemonize yes
################################ SNAPSHOTTING 
# 存放快照（数据日志文件的目录）dump.rdb
dir /opt/redis-5.0.7/data

################################# REPLICATION
# 1主两从架构里，至少一个有个从服务器在线且在10秒以内延迟，主redis才能对外提供写服务器，否则客户端无法写
min-replicas-to-write 1
min-replicas-max-lag 10
#这里也需设置，因为当该master挂了再重启，变成replica后，需要密码去认证新的master
masterauth foo123
################################## SECURITY 
# 为master设置认证密码
requirepass foo123

################################### CLIENTS 
# 按默认
############################## MEMORY MANAGEMENT
# 按默认

”2个replica“节点的redis.conf配置

################################## NETWORK 
# 绑定本机IP
bind 182.0.0.11
# 另外一台从的IP为182.0.0.12
################################# GENERAL

# 后台守护进程运行
daemonize yes

################################ SNAPSHOTTING 
# 存放快照（数据日志文件的目录）dump.rdb
dir /opt/redis-5.0.7/data

################################# REPLICATION
# 告诉从服务器主服务器的认证密码以及IP端口号，新版redis不再使用slave争议词，原版是slaveof
replicaof 182.0.0.10 6379
masterauth foo123

# 1主两从架构里，至少一个有个从服务器在线且在10秒以内延迟，主redis才能对外提供写服务器，否则客户端无法写
min-replicas-to-write 1
min-replicas-max-lag 10
################################## SECURITY 
# 从redis需要密码认证
requirepass foo123

################################### CLIENTS 
# 按默认
############################## MEMORY MANAGEMENT
# 按默认

3.2 启动和测试主从

启动所有主从redis-server，后台守护进程运行

[root@p1 opt]# redis-server /opt/redis-5.0.7/redis.conf

注意：
如果只启动master，从服务器还未启动，提示没有足够的从服务器在线，无法对外提供写服务。

127.0.0.1:6379> set test 1
(error) NOREPLICAS Not enough good replicas to write.

这是因为min-replicas-to-write 1 要求最少1个从redis在线后master才能接收客户端写数据。
在master set一个key

[root@p1 opt]# redis-cli -a foo123
127.0.0.1:6379> set foo 1
```shell
在两个从服务器get key
```shell
[root@p2 redis-5.0.7]# redis-cli -a foo123
127.0.0.1:6379> get foo
"1"

[root@p3 redis-5.0.7]# redis-cli -a foo123
127.0.0.1:6379> get foo
"1"

通过在master 查看主从信息：

127.0.0.1:6379> INFO Replication
# Replication
role:master
connected_slaves:2
min_slaves_good_slaves:2
slave0:ip=182.0.0.11,port=6379,state=online,offset=1958,lag=0
slave1:ip=182.0.0.12,port=6379,state=online,offset=1958,lag=1
master_replid:1f69dd42ecea58d245859fd716c4eaee83a6e753
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1958
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1958

注：INFO [section]命令可以查看多个部分信息，也可指定查看某个section的信息
以上说明1主两从redis架构已经构建，该模式下，只有master才能写数据，replica只能get数据。如果尝试在replica上写数据，将提示readonly：

127.0.0.1:6379> set bar 2
(error) READONLY You can't write against a read only replica.

4、sentinel 高可用配置

sentinel 高可用是基于主-从-从正常运行情况下配置，经过前面2.3点，相信很容易理解该sentinel的逻辑，

4.1 配置sentinel.conf

主、从的sentinel.conf都一样，而且也很简单，更改两项属性即可，其他可以按默认值，如果需要调优，可自行参考conf的说明设置相应值。

bind 0.0.0.0
port 26379
daemonize yes
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor  mymaster  182.0.0.10 6379 2
# 如果master设置了密码，那么也告诉sentinel密码
sentinel auth-pass mymaster foo123

#  <master-name> 自行定义名称，这里使用mymaster默认值，后面的配置项都用了mymaster这个名，在django项目的settings，redis缓存设置也需要用到该master-name，无特殊需求不用改。
#  <quorum> 裁定master挂了的最低通过票数

# Tells Sentinel to monitor this master, and to consider it in O_DOWN
# (Objectively Down) state only if a