【Redis】Redis持久化原理，主从复制，哨兵，集群

最新推荐文章于 2024-07-10 18:24:00 发布

置顶阿霖

最新推荐文章于 2024-07-10 18:24:00 发布

阅读量1.1k

点赞数

分类专栏： Redis

本文链接：https://blog.csdn.net/qq_43673818/article/details/115489562

版权

Redis 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

文章目录

Redis

Redis

Redis的高可用性

系统处于不可用

在这里插入图片描述

什么叫Redis的不可用

在这里插入图片描述

redis基于哨兵的高可用性

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LqWKjb81-1617785041700)(https://www.jianguoyun.com/c/tblv2/-S_Rz42iQLiALT8u0srBPfoEcopUbIuaoVG_bIGnjuBpPs2YQz_8gKZ6Mr108dFnNGFL-LcQ/8Y0pN6KItbB5YLQ2fgYtsw/l)]

Redis 持久化

一般企业中Redis数据保存，会通过持久化机制保存一份在磁盘上，然后定期备份到阿里云服务器上。

如果redis重启后，没有数据恢复，当大量请求过来的时候，缓存全部无法命中，在redis中找不到数据，导致缓存雪崩，请求全部到mysql源头去找，一下子mysql承接高并发，然后就挂了。mysql挂了，都没有办法将数据恢复到redis。

如果同时开启RDB，AOF，redis默认会使用AOF去恢复数据。

RDB

每隔一段时间生成redis的数据快照，保存到磁盘中。默认是dump.RDB

RDB持久化工作机制：

redis根据配置自己去生成rdb快照
fork一个子进程出来
子进程尝试将数据dump到临时的rdb快照文件
完成rdb快照文件的生成后，就会替换之前旧的快照文件

优点：

适合做冷备份，RDB会保存redis完整的数据，可以将这种完整的数据发送到一些远程的安全存储上去，比如阿里云，以预定好的备份策略来定期备份redis中的数据。
RDB对redis对外提供的写服务影响很小，可以让redis保持高性能。因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
使用RDB重启和恢复redis进程，更加快速。

缺点：

RDB可能会丢失很多数据，因此RDB不适合做第一恢复方案
RDB在fork子进程开执行RDB数据快照文件生成的时候，如果数据非常大，可能导致对客户端提供的服务暂停数秒。

AOF

redis每执行一条写命令就将这条命令追加到磁盘中的AOF文件中。

具体是先写到linux的os cache中，每隔1s调用一次操作系统的fsync操作将os cache中的数据刷入磁盘文件。

aof重写

redis中的数据不是无限量的，不可能无限增长，进而导致AOF无限增长。内存大小是一定的，到一定时间，redis就会用缓存淘汰算法LRU，自动将一部分数据从内存中清除。当AOF膨胀到一定大小，AOF就会做rewrite操作，AOF就会基于当时redis内存中的数据，来重新构造一个更小的AOF文件。

优点：

AOF可以更好的保证数据不丢失。

缺点：

AOF文件比RDB数据库快照文件更大。
AOF开启后，支持的qps比RDB更低。
AOF文件容易有bug，恢复数据的时候有时不能恢复一份一模一样的数据出来。

aof的fsync策略（appendfsync）

always：每次写一条数据，就同步到磁盘中
everysec：每秒一次，将数据同步到磁盘
no：不使用aof

RDB和AOF如何选择

Redis replication 主从复制

master持久化对主从架构安全的意义

如果采用了主从架构，就必须开启master node 持久化

不建议使用slave node做master node 的数据热备，因为那样的话，如果你关掉master的持久化，可能master宕机重启的时候数据是空的，然后一经过复制，slave node的数据也丢了。

主从复制原理

当启动一个slave node 的时候，它会先发送一个PSYNC命令给master node

如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据；否则如果是slave node第一次连接master node，那么会触发一次full resynchronization。开始full resynchronization的时候，mater会启动一个后台线程，开始生成一份rdb文件，同时还会将从客户端收到的所有写命令缓存在内存中，rdb文件生成完毕之后，master会将这个rdb发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。

在这里插入图片描述
redis的runid的作用

在这里插入图片描述

全量复制

mater会启动一个后台线程，开始生成一份rdb文件，同时还会将从客户端收到的所有写命令缓存在内存中，rdb文件生成完毕之后，master会将这个rdb发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。

增量复制

master node仅仅会复制给slave部分缺少的数据。

主从复制断点续传

从redis1.8开始就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份。

无磁盘化复制

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了。

过期key处理

slave不会过期key，只会等待master过期一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

心跳检测

slave每1秒一次，master每10s一次。主要是就检测网络连接状态和同步数据。

哨兵

介绍

sentinal，中文名叫哨兵

哨兵是redis集群架构中非常重要的一个组件，主要功能如下：

集群监控，负责监控master和slave是否正常工作。
消息通知，如果某个redis实例有故障，哨兵会发送消息作为报警通知给管理员。
故障转移，如果mater node节点挂掉了，会自动转移到slave节点上。
配置中心，如果故障发生了，通知slave新的master的地址。

哨兵本身也是分布式的，作为一个哨兵集群去工作，互相协同工作。

故障转移时，判断一个master node是否宕机了，需要大部分哨兵同意才行，涉及到了分布式选举的问题。
即使部分哨兵节点挂了，哨兵集群还是可以正常工作的。

核心知识

哨兵至少需要3个实例，来保证自己的健壮性。

最经典的3节点哨兵集群：此时有mater（sentinel 1），slave1（sentinel 2），slave2（sentinel 3）。

每一个redis实例的机器上还有一个哨兵，当master挂了，sentinel 2 和 3 可以一致认为master宕机，然后选举出一个来进行故障转移。
哨兵 + redis 主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性。

异步复制

主节点和从节点的数据复制是异步的，可能从节点还没有复制，主节点就宕机了，此时这些部分数据就丢失了。

集群脑裂

集群脑裂是指某个主节点突然脱离网络，和其他从节点以及哨兵集群不能连接，哨兵集群就认为主节点宕机了，就选举出一个从节点作为新的主节点，那么此时有两个主节点，这就是脑裂。

此时client还不知道主节点切换，会继续向老的主节点写数据，当网络恢复后，老的主节点重新连接后，会变成从节点，这就导致在老的主节点失去连接的这一段时间client向它写的数据就会丢失。

异步复制和脑裂导致的数据丢失如何降低损失

可以通过配置 min-slaves-to-wirte 和 min-slaves-max-lag来解决这个问题。

比如配置：

min-slaves-to-wirte 1
min-slaves-max-lag 10

意思是要求至少有1个slave，数据复制和同步的延迟不能超过10s。

如果一旦所有的slave，数据复制和同步的延迟都超过了10s，那么这个时候，master就不会再接收任何请求（拒绝请求），此时client就会采取客户端降级的方案。

减少异步复制的数据丢失

有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内。

减少脑裂的数据丢失

如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求。

这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失。

上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求。

因此在脑裂场景下，最多就丢失10秒的数据。

主观宕机和客观宕机

sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机

odown是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机

sdown达成的条件很简单，如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机

sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机

哨兵集群的自动发现机制

哨兵互相之间的发现，是通过redis的pub/sub（发布订阅）系统实现的，每个哨兵都会往__sentinel__:hello这个channel里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在

每隔两秒钟，每个哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hello channel里发送一个消息，内容是自己的host、ip和runid还有对这个master的监控配置

每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在

每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步

slave配置的自动纠正

哨兵会负责自动纠正slave的一些配置，比如slave如果要成为潜在的master候选人，哨兵会确保slave在复制现有master的数据; 如果slave连接到了一

个错误的master上，比如故障转移之后，那么哨兵会确保它们连接到正确的master上

slave->master选举算法

如果一个master被认为odown了，而且majority哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave。

会考虑slave的一些信息

跟master断开连接的时长
slave优先级
复制offset
run id

如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master。

接下来会对slave进行排序

按照slave优先级进行排序，slave priority越低，优先级就越高
如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset越靠后，优先级就越高
如果上面两个条件都相同，那么选择一个run id比较小的那个slave

quorum和majority

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做切换，这个哨兵还得得到majority哨兵的授权，才能正式执行切换

如果quorum < majority，比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换

但是如果quorum >= majority，那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换

Redis集群

集群架构

单Redis master架构的性能瓶颈

单Redis master架构的性能瓶颈–slave存储的数据量取决于master可以存储的数据。

如何突破瓶颈

redis集群架构

redis cluster（多master + 读写分离 + 高可用）

支撑N个redis master node，每个master node都可以挂载多个slave node

读写分离的架构，对于每个master来说，写就写到master，然后读就从mater对应的slave去读

高可用，因为每个master都有salve节点，那么如果mater挂掉，redis cluster这套机制，就会自动将某个slave切换成master

我们只要基于redis cluster去搭建redis集群即可，不需要手工去搭建replication复制+主从架构+读写分离+哨兵集群+高可用

redis cluster 对比 replication + sentinel

如果你的数据量很少，主要是承载高并发高性能的场景，比如你的缓存一般就几个G，单机足够了。

replication，一个mater，多个slave，要几个slave跟你的要求的读吞吐量有关系，然后自己搭建一个sentinal集群，去保证redis主从架构的高可用性，就可以了。

redis cluster，主要是针对海量数据+高并发+高可用的场景，海量数据，如果你的数据量很大，那么建议就用redis cluster。

cluster介绍

redis cluster

自动将数据进行分片，每个master上放一部分数据

提供内置的高可用支持，部分master不可用时，还是可以继续工作的

在redis cluster架构下，每个redis要放开两个端口号，比如一个是6379，另外一个就是加10000的端口号，比如16379

16379端口号是用来进行节点间通信的，也就是cluster bus的东西，集群总线。cluster bus的通信，用来进行故障检测，配置更新，故障转移授权

cluster bus用了另外一种二进制的协议，主要用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间

数据分布算法

分布式数据存储的核心算法，数据分布算法

hash算法 -> 一致性hash算法（memcached） -> redis cluster, hash slot 算法

hash算法：直接对节点数量capacity取模，然后到对应redis拿数据。如果此时有一个redis节点挂了，就可能导致整个缓存失效，导致所有请求打到数据库。

一致性hash算法：一个环（0 - 2^31）然后将节点的某个属性（ip，host）进行hash分布到环上，当数据来的时候只需要计算数据的hash，然后顺时针找到第一个到达的节点，就是数据存放的位置。为了避免数据分布不均匀，还引入虚拟节点的机制（实现负载均衡）。

用不同的算法，就决定了在多个master节点的时候，数据如何分布到这些节点上去。

Redis cluster的hash slot算法

redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot。

redis cluster中每个master都会持有部分slot，比如有3个master，那么可能每个master持有5000多个hash slot。

hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去。

移动hash slot的成本是非常低的。

客户端的api，可以对指定的数据，让他们走同一个hash slot，通过hash tag来实现。

执行流程

客户端向节点发送与数据库键有关的命令时，节点计算出数据库键属于的 slot—>CRC16(key)&16383，并检查该 slot 是否被指派给自己，如果正好指派给自己，直接执行，否则返回一个 moved 错误，指引客户端转向至正确的节点。如果在重新分片时，将某节点的 slot 指派给另一个节点，slot 所对应的键值对也会被移动，如果此时只迁移部分键值对，而另一部分还在在原来节点中，客户端向原来的节点发送键的命令，会先在自己数据库中查找，找到即执行，否则源节点返回 ASK 错误，指引客户端转向正在导入 slot 的目标节点。

基础通信原理

redis cluster节点间采取gossip协议进行通信

跟集中式不同，不是将集群元数据（节点信息，故障，等等）集中存储在某个节点上，而是互相之间不断通信，保持整个集群所有节点的数据是完整的

维护集群的元数据用得，集中式，一种叫做gossip

集中式：好处在于，元数据的更新和读取，时效性非常好，一旦元数据出现了变更，立即就更新到集中式的存储中，其他节点读取的时候立即就可以感知到; 不好在于，所有的元数据的跟新压力全部集中在一个地方，可能会导致元数据的存储有压力。

gossip：好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力; 缺点，元数据更新有延时，可能导致集群的一些操作会有一些滞后。

10000端口

每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口。

每隔节点每隔一段时间都会往另外几个节点发送ping消息，同时其他几点接收到ping之后返回pong。

交换的信息

故障信息，节点的增加和移除，hash slot信息，等等

gossip协议

gossip协议包含多种消息，包括ping，pong，meet，fail，等等。

meet: 某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信。
redis-trib.rb add-node
其实内部就是发送了一个gossip meet消息，给新加入的节点，通知那个节点去加入我们的集群。
ping: 每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据。
每个节点每秒都会频繁发送ping给其他的集群，ping，频繁的互相之间交换数据，互相进行元数据的更新。

ping很频繁，而且要携带一些元数据，所以可能会加重网络负担

每个节点每秒会执行10次ping，每次会选择5个最久没有通信的其他节点

当然如果发现某个节点通信延时达到了cluster_node_timeout / 2，那么立即发送ping，避免数据交换延时过长，落后的时间太长了

比如说，两个节点之间都10分钟没有交换数据了，那么整个集群处于严重的元数据不一致的情况，就会有问题
pong: 返回ping和meet，包含自己的状态和其他信息，也可以用于信息广播和更新。
fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。