哨兵（Sentinel）：
- 监控主服务器和从服务器的健康状态。
- 在主服务器发生故障时，自动选举新的主服务器，并将其中一个从服务器提升为新的主。
- 通知客户端新的主服务器位置。
- 可以设置多个哨兵，提高冗余性和可用性。
工作流程：
- 哨兵通过定期发送PING 命令监测主机和从机的健康状况。
- 当哨兵发现主服务器不可用时，会启动故障转移过程：
  - 选择一个合适的从服务器提升为新主服务器。
  - 更新其他从服务器的配置，将它们指向新的主服务器。
- 客户端可以通过哨兵获取当前的主服务器地址。

Redis 集群模式（Cluster Mode）

Redis 集群模式是为了解决水平扩展性的问题。与主从复制不同，集群模式允许将数据分散到多个 Redis 实例中，实现数据的分片（sharding）。

数据分片：
- 使用哈希槽（hash slot）机制来实现数据的分片。Redis 集群有 16384 个哈希槽，所有的键通过哈希函数映射到这些槽上。
- 每个 Redis 实例负责一部分哈希槽。
主从模式：
- 每个主节点可以有多个从节点，主节点负责写操作，从节点负责读操作。
节点通信：
- 每个节点通过 Gossip 协议与其他节点进行通信，以便通知它们的状态。
- 节点可以自动发现其他节点的信息。
故障转移：
- 如果一个主节点失败，其对应的从节点可以被提升为新主节点，确保集群的可用性。

工作流程

客户端的操作会基于键的哈希值，将数据指向特定的哈希槽和相应的节点。
客户端从任意节点开始连接，通过自身的集群信息，决定发送请求的节点。
如果一个主节点不可用，集群将自动选举一个新的主节点来接管。

适用场景

总结比较

主从复制与哨兵模式：
- 适用于需要高可用性和故障转移的场景，但数据仍然存储在单机上。
- 哨兵提供监控和故障转移功能。
- 易于设置和管理。
Redis 集群模式：
- 适用于需要高可扩展性和高性能的场景。
- 允许将数据分割到多个节点上，提供更大的容量和并发处理能力。
- 需要更多的维护和监控。

如果应用需要的主要是高可用性和数据的冗余备份，主从复制结合哨兵模式是一个较好的选择。
如果希望处理更大规模的数据集，并且需要更高的写入和读取性能，Redis 集群是更合适的方案。

一主两从三哨兵模式

概念介绍：

在主从复制模式下，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址，对于很多应用场景这种故障处理的方式是无法接受的。从Redis2.8开始正式提供Redis Sentinel（哨兵）架构来解决这个问题。

监控（Monitoring）：
Sentinel会不断地检查主节点和从节点是否运作正常。

提醒（Notification）：
当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知。

自动故障迁移（Automaticfailover）：
当一个主服务器不能正常工作时，Sentinel会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

发现并连接主节点
Sentinel会与被监视的主节点创建两个网络连接：
命令连接用于向主节点发送命令;
订阅连接用于订阅指定的频道，从而发现监视同一主节点的其他Sentinel;

发现并连接从服务器
Sentinel通过向主节点发送info命令(默认每隔10s)来自动获得所有从节点的地址。跟主节点一样，Sentinel会与每个被发现的从服务器创建命令连接和订阅连接。

发现其他Sentinel

Sentinel会通过命令连接向被监视的主从服务器发送“HELLO”信息，该消息包含Sentinel的IP、端口号、ID等内容，以此来向其他Sentinel宣告自己的存在。与此同时Sentinel会通过订阅连接接收其他Sentinel的“HELLO”信息，以此来发现监视同一个主服务器的其他Sentinel。

每个Sentinel都订阅了被它监视的所有主节点与从节点的sentinel:hello频道，查找之前未出现过的Sentinel。当一个Sentinel发现一个新的Sentinel时，它会将新的Sentinel添加到一个列表中，这个列表保存了已知并且监视同一个主节点的所有其他Sentinel。Sentinel发送的信息中还包括完整的主节点当前配置（configuration）。如果一个Sentinel包含的主服务器配置比另一个Sentinel发送的配置要旧，那么这个Sentinel会立即升级到新配置上。
Sentinel之间只会互相创建命令连接，用于进行通信。因为已经有主从服务器作为发送和接收HELLO信息的中介，所以Sentinel之间不会创建订阅连接。

Sentinel使用以下规则来选择新的主服务器：

1）在失效主服务器属下的从服务器当中，那些被标记为主观下线、已断线、或者最后一次回复PING命令的时间大于五秒钟的从服务器都会被淘汰。
2）在失效主服务器属下的从服务器当中，那些与失效主服务器连接断开的时长超过down-after选项指定的时长十倍的从服务器都会被淘汰。
3）在经历了以上两轮淘汰之后剩下来的从服务器中，我们选出复制偏移量（replicationoffset）最大的那个从服务器作为新的主服务器；如果复制偏移量不可用，或者从服务器的复制偏移量相同，那么带有最小运行ID的那个从节点成为新的节点。

Sentinel自动故障转移的一致性特质：
1）Sentinel自动故障迁移使用Raft算法来选举领头（leader）Sentinel，从而确保在一个给定的周期（epoch）里，只有一个领头产生。
2）这表示在同一个周期中，不会有两个Sentinel同时被选中为领头，并且各个Sentinel在同一个节点中只会对一个领头进行投票。
3）更高的配置节点总是优于较低的节点，因此每个Sentinel都会主动使用更新的节点来代替自己的配置。
简单来说，我们可以将Sentinel配置看作是一个带有版本号的状态。一个状态会以最后写入者胜出（last-write-wins）的方式（也即是，最新的配置总是胜出）传播至所有其他Sentinel。

实验：

为了提高系统的可用性，通常推荐将哨兵节点部署在与 Redis 主节点和从节点不同的物理或虚拟机上(实验中为了节省机器，三哨兵部署在了主从节点上)

三哨兵的具体配置

实验准备：
主：192.168.1.10:6379
从1：192.168.1.11:6379
主2：192.168.1.12:6379
哨兵1：192.168.1.10:26379
哨兵2：192.168.1.11:26379
哨兵3：192.168.1.12:26379

单个配置sentinel哨兵实现高可用

vim /etc/redis-sentinel.conf

systemctl start redis-sentinel.service

netstat -anput | grep 26379

检测：
redis-cli -h 192.168.1.10 -p 26379

info sentinel

配置三哨兵

基本配置

vim /etc/redis.conf

指定主库

vim /etc/redis.conf

11端

12端

配置哨兵（10 11 12）

vim /etc/redis-sentinel.conf

systemctl start redis-sentinel.service

netstat -anput | grep 26379

redis-cli -h 192.168.1.10 -p 26379

info sentinel

sentinel masters

redis-cli

info replication

测试：宕机主库，查看主从变化

sentinel集群实现主从高可用

简介

当遇到单机、内存、并发、流量等瓶颈时，可以采用Cluster架构方案达到负载均衡目的。

数据分布
分布式数据库首先要解决把整个数据库集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整体数据的一个子集，需要关注的是数据分片规则，Redis Cluster 采用
哈希分片规则。（任务分配，共同完成）

这个图中，每一个蓝色的圈都代表着一个redis的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。

实现原理
在redis的每一个节点上，都有这么两个东西，一个是插槽（slot）可以理解为是一个可以存储两个数值的一个变量这个变量的取值范围是：0-16383。还有一个就是cluster我个人把这个cluster理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作

实验：

为了实现高可用性，推荐的配置确实是至少需要六个实例，具体配置如下：

最佳实践配置

3 个主节点 (Masters)：这些节点负责处理写入和一部分读取请求。这些主节点会将数据分片并分配到哈希槽中。
3 个从节点 (Replicas)：每个主节点有一个对应的从节点。这些从节点主要负责备份主节点的数据，并可以处理读请求（实验为了节省机器，仅和 master部署在一台机器中）。

为什么需要这样的配置？

高可用性：如果某个主节点发生故障，其对应的从节点可以被提升为新的主节点，以确保服务的连续性。如果只使用三个节点（其中某一个主节点挂掉），那么如果没有从节点备份，该节点的哈希槽内数据将丢失。
故障转移：在 Redis 集群中，故障转移是通过选举新的主节点来实现的。如果希望确保在某个节点不可用时数据仍能被访问，必须有从节点作为后备。
数据冗余：从节点的存在允许 Redis 复制数据，以防止数据丢失，并在主节点发生故障时保持高可用性。
网络隔离和降低风险：将主节点和从节点分布到不同的物理或虚拟机上可以降低单点故障的风险。当一组节点故障时，另一组仍可以保持服务。

下载aliyun镜像源和安装包

wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo
sed -i -e '/mirrors.cloud.aliyuncs.com/d' -e '/mirrors.aliyuncs.com/d' /etc/yum.repos.d/CentOS-Base.repo
wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
yum makecache
yum -y install redis

后台执行和允许其他服务器登录

vim /etc/redis.conf

创建文件

mkdir -pv /etc/redis/6380

将配置文件复制到创建的目录下

cp -a /etc/redis.conf /etc/redis/6380/redis.conf

vim /etc/redis/6380/redis.conf

10端配置：

端口号修改

pid文件位置

日志目录

数据目录

开启集群模式，指定配置文件和节点的超时时间

传送给11端和12端

scp /etc/redis/6380/redis.conf 192.168.1.11:/etc/redis/6380/redis.conf
scp /etc/redis/6380/redis.conf 192.168.1.12:/etc/redis/6380/redis.conf

创建指定的目录，并修改配置文件节点目录权限

cp -a /var/lib/redis /var/lib/redis2

开启redis主节点和从节点实例

systemctl start redis
redis-server /etc/redis/6380/redis.conf

高可用：

下载环境包
下载ruby包
wget ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/takehironet/CentOS_CentOS-7/x86_64/ruby-2.3.6-2.2.x86_64.rpm
安装rpm包
yum -y localinstall ruby-2.3.6-2.2.x86_64.rpm

把阿里云镜像的ruby源拉下来
查找默认源
gem sources

#移除默认源
gem sources --remove https://rubygems.org/
#添加新源
gem sources -a https://mirrors.aliyun.com/rubygems/

查看安装后的ruby源

安装redis运行ruby的环境
gem install redis

如果想要使用ruby脚本，需要在装一个源码包的redis

wget http://download.redis.io/releases/redis-3.2.12.tar.gz   
tar xf redis-3.2.12.tar.gz
mv  /root/redis-3.2.12/src/redis-trib.rb /root

开启所有节点

systemctl start redis
redis-server /etc/redis/6380/redis.conf

执行脚本并指定参数

./redis-trib.rb create --replicas 192.168.1.10:6379 192.168.1.11:6379 192.168.1.12:6379 192.168.1.11:6380 192.168.1.12:6380 192.168.1.10:6380

执行结果

测试主从复制

redis-cli -p 6379 -h 192.168.1.10 -c

创建一个键值对

set a 1

去从节点查看

redis-cli -p 6380 -h 192.168.1.11 -c

测试：关闭sentinel

info sentinel

6380成为了主库

也可以去6380看一下

redis-cli -p 6380

info replication

当我们重新开启6379时

systemctl start redis

在6380查看一下

info replication

6379成为了从库

在sentinel查看

redis-cli -h 192.168.1.10 -p 26379

发布者：LJH，转发请注明出处：https://www.ljh.cool/5311.html

基于哨兵和集群方式分别实现redis高可用

Redis 的高可用性和扩展性概念

主从复制（Master-Slave）与哨兵（Sentinel）模式

1、主从复制

2、哨兵模式

Redis 集群模式（Cluster Mode）

工作流程

适用场景

一主两从三哨兵模式

概念介绍：

实验：

三哨兵的具体配置

单个配置sentinel哨兵实现高可用

配置三哨兵

sentinel集群实现主从高可用

简介

实验：

发表回复

基于哨兵和集群方式分别实现redis高可用

Redis 的高可用性和扩展性概念

主从复制（Master-Slave）与哨兵（Sentinel）模式

1、主从复制

2、哨兵模式

Redis 集群模式（Cluster Mode）

工作流程

适用场景

一主两从三哨兵模式

概念介绍：

实验：

三哨兵的具体配置

单个配置sentinel哨兵实现高可用

配置三哨兵

sentinel集群实现主从高可用

简介

实验：

相关推荐

tomcat、redis+tomcat session共享配置

Redis基础概念

发表回复