Redis集群

最新推荐文章于 2024-08-28 22:18:40 发布

zhangphh

最新推荐文章于 2024-08-28 22:18:40 发布

阅读量101

点赞数

分类专栏：分布式文章标签： redis 分布式

本文链接：https://blog.csdn.net/qq_43060759/article/details/105240609

版权

分布式专栏收录该内容

3 篇文章 0 订阅

订阅专栏

1、主从模式

①、主从模式的优点：

为数据提供多个副本，实现高可用；
实现读写分离，主节点负责写，从节点负责读，主节点定期把数据同步到从节点实现数据的一致性；
避免了当单个节点损坏时数据丢失

②、主从模式的特点

数据流是单向的，只能是从master流向slave；
一个maste可以有多个slave，master可读可写，slave只能读，不要修改配置让slave可写，因为slave写之后不会同步到其他节点，而且master写之后会覆盖slave之前的内容；
slave节点挂掉后不会影响其他slave节点的读和master节点的写。master节点挂掉后不会影响slave的读，但不会再提供写服务；
master节点挂掉后不会重新选master节点；
master下的slave还可以接受同一架构中其他slave的连接与同步请求，实现数据的级联，即master->slave->slave；
master会以非阻塞的方式处理同步数据至slave，这意味着master在复制数据的同时可以完成client的读写，slave也可以修改为非阻塞方式，在slave同步数据的时候可以使用原来的数据进行读操作；
可以通过配置禁止master写操作，从而将数据的持久化操作交给master，避免了master中有独立的进程完成此操作。

③、主从复制的缺点：

最主要的是当master挂掉后不能重新自动选用新的master，也就不能对外提供写操作了。

④、实现主从复制的步骤
只需将redis的所有文件拷贝到新的文件夹中，修改redis.windows.conf文件的port，然后再加上slaveof 127.0.0.1 6379即可。

⑤、redis主从复制原理
redis的主从复制可以根据是否全量分为全量复制和部分复制

全量复制
全量复制一般发生在slave的初始化阶段，将主节点中的数据全部发送给从节点，是一个非常重性的操作，当数据量比较大时，会对主从节点和网络造成很大的开销。

全量复制的步骤如下：

slave连接到master并向master发送sync命令；
master接收到sync命令后执行bgsave命令生成RDB快照文件，并使用缓冲区记录此时在此期间的所有写命令；
master执行完bgsave命令后将RDB快照文件发送给slave，并在发送期间继续记录写操作；
从服务器收到快照文件后丢掉所有旧数据，加载RDB快照文件；
master发送完快照文件后将缓冲区中的命令发送给slave；
slave完成加载快照文件后接收来自master发送的缓冲区中的命令；

全量复制的开销

主节点bgsave生成快照；
发送快照文件的网络传输占用网络IO；
slave清除旧数据；
slave加载RDB文件；
全量复制会引发slave的AOF重写

部分复制
部分复制用于处理在主从复制的过程中由于网络等原因造成主从节点断开连接进而导致数据丢失的情况，当从节点再次连接上主节点时，主节点会补发丢失数据给从节点，因为补发的数据远远小于全量数据，所以可以有效的避免全量复制的高额开销。

部分复制的过程如下：

从节点断开连接；
主节点将命令写入复制缓冲区；
slave继续尝试连接master；
slave连接到master后将自己的run_id(用来标识唯一一个redis节点)和偏移量offset发送给master，并执行psync命令完成同步；
如果master发现offset在缓冲区的范围内就返回continue命令；
同步了offset的部分数据，所以关键就在于offset

推荐阅读：Redis主从复制的原理

2、哨兵机制

哨兵模式是对主从复制模式的一个优化，既然主从复制模式master挂掉之后无法再次选举新的master，那么就安排一个或多个sentinel来做这件事，当master挂掉后，色不停饿了就从slave中选出一个新的master。

①、哨兵机制的特点

sentinel机制是建立在主从模式的基础上的，如果只有一个节点，则sentinel就没有意义；
当sentinel模式的master挂掉了以后，sentinel会从slave中选出一个新的master，并修改其配置文件，相应的其他slave配置文件也会被修改，slaveof将指向新的master；
当master节点重启后，将不再是master，而是作为slave接收当前master的同步数据；
sentinel最好不要和Redis部署在同一机器上，因为redis挂掉之后sentinel也会挂掉；
一般会为sentinel监控的集群命名一个master名字，这个名字代表Redis集群的master名字

②、实现sentinel模式的步骤(一主二从三哨兵为例)：

复制redis目录下的全部文件到三个文件夹中分别命名为master6393、slave6394、slave6395；
修改三个文件夹中的redis.windows.conf的port分别为6393、6394、6395，在slave6394中添加slaveof 127.0.0.1 6393，在slave6395添加slaveof 127.0.0.1 6393；
在三个文件夹中添加startup.cmd，内容为：redis-server.exe redis.windows.conf；
在master6393目录下添加sentinel.conf，内容如下：

#当前Sentinel服务运行的端口
port 26379
#master
#Sentinel去监视一个名为mymaster的主redis实例，这个主实例的IP地址为本机地址127.0.0.1，端口号为6393，
#而将这个主实例判断为失效至少需要2个 Sentinel进程的同意，只要同意Sentinel的数量不达标，自动failover就不会执行
sentinel monitor mymaster 127.0.0.1 6393 1
#指定了Sentinel认为Redis实例已经失效所需的毫秒数。当 实例超过该时间没有返回PING，或者直接返回错误，那么Sentinel将这个实例标记为主观下线。
#只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移：只有在足够数量的Sentinel都将一个实例标记为主观下线之后，实例才会被标记为客观下线，这时自动故障迁移才会执行
sentinel down-after-milliseconds mymaster 5000
#指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
sentinel config-epoch mymaster 16
#如果在该时间（ms）内未能完成failover操作，则认为该failover失败
sentinel leader-epoch mymaster 16

在slave6394目录下添加文件sentinel.conf，内容为：

#当前Sentine2服务运行的端口
port 26479
#slave1
sentinel monitor mymaster 127.0.0.1 6395 1
sentinel down-after-milliseconds mymaster 5000
sentinel config-epoch mymaster 16
sentinel leader-epoch mymaster 17

slave6395目录下的sentinel.conf和slave6395目录下的类似；

启动三个redis服务，分别启动master和slave，执行三个startup.cmd即可；
启动三个sentinel，命令为：redis-server.exe sentinel.conf --sentinel
查看三个节点redis状态：
master如下
查看sentinel的状态：
master如下：
测试发现符合主从复制特点。
redis主从自动failover测试：
关闭master，观察slave

发现原来的slave6395变成了master，重启master6393后发现master6393变成了slave，如下所示：

关于sentinel的配置推荐阅读：redis sentinel（哨兵机制）部署(Windows下实现)

③、哨兵机制原理

哨兵的作用有两个：一是监视master和slave是否正常；二是当master出现故障时通过投票机制将其中一个slave升级为master，哨兵不仅会监视master和slave还会监视其他哨兵，一般哨兵至少部署三个，建议使用奇数个哨兵。

Redis的哨兵系统执行一下三个任务：

监控，哨兵会一直监控master和slave是否正常运行；
提醒，哨兵会在被监视的Redis出现故障的时候通过API向管理员或者应用程序发送提醒；
自动故障迁移，当一个master出现故障时，哨兵会开始一次自动故障迁移操作，将失效的master中的一个slave升级为新的master，其他原来的slave复制新的master，当客户端连接失效的master的时候，集群会向客户端返回新的master的地址，是集群可以使用新的master代替失效的master。

哨兵机制工作原理
多个哨兵采用流言协议来判定master是否下线，并采用投票协议决定是否执行自动故障迁移和选举哪一个slave为新的的master。

每一个哨兵会定时向其他的master、slave、哨兵发送消息以确定对方是否还活着，如果对方在短时间(可设定)内未回应，则主观判断其死亡，即Subjective Down(简称 sdown)；若哨兵群中的多数哨兵都判定master未响应，则系统认为master真正死亡，即Objective Down(简称 odown)，同时通过一定的vote算法选举一个slave作为新的master，并修改相关配置。

监控，哨兵会以每秒一次的频率向与之相创建了命令连接的实例发送PING，包括主服务器、从服务器和sentinel实例，以此来判断当前实例的状态，down-after-milliseconds时间内PING连接无效，则将该实例视为主观下线。之后该sentinel会向其他监控同一主服务器的sentinel实例询问是否也将该服务器视为主观下线状态，当超过某quorum后将其视为客观下线状态。

当一个主服务器被某sentinel视为客观下线状态后，该sentinel会与其他sentinel协商选出零头sentinel进行故障转移工作。每个发现主服务器进入客观下线的sentinel都可以要求其他sentinel选自己为领头sentinel，选举是先到先得。同时每个sentinel每次选举都会自增配置纪元，每个纪元中只会选择一个领头sentinel。如果所有超过一半的sentinel选举某sentinel领头sentinel。之后该sentinel进行故障转移操作。

故障转移，首先是从主服务器的从服务器中选出一个从服务器作为新的主服务器。选点的依据依次是：网络连接正常->5秒内回复过INFO命令->10*down-after-milliseconds内与主连接过的->从服务器优先级->复制偏移量->运行id较小的。选出之后通过slaveif no ont将该从服务器升为新主服务器。

通过slaveof ip port命令让其他从服务器复制该信主服务器。

最后当旧主重新连接后将其变为新主的从服务器。注意如果客户端与就主服务器分隔在一起，写入的数据在恢复后由于旧主会复制新主的数据会造成数据丢失。

故障转移成功后会通过发布订阅连接广播新的配置信息，其他sentinel收到后依据配置纪元更大来更新主服务器信息。Sentinel保证第二个活性属性：一个可以相互通信的Sentinel集合会统一到一个拥有更高版本号的相同配置上。
在这里插入图片描述

哨兵机制是有缺点的：

主从服务器的数据要经常进行主从复制，这样造成性能下降。
当主服务器宕机后，从服务器切换成主服务器的那段时间，服务是不能用的

4、cluster方式

①、cluster的具体实现方式参见：Windows下搭建RedisCluster集群
测试如果出现类似127.0.0.1:6380> get name (error) MOVED 5798 127.0.0.1:6381的情况参见：redis集群报错：(error) MOVED 5798 127.0.0.1:7001

②、cluster方式的分区实现原理：
推荐阅读：
Redis Cluster分区实现原理
 redis主从复制下哨兵模式—选举原理