2021-10-16

Redis持久化，主从，哨兵搭建就这么简单

如果对redis的数据结构不是很清晰的，可以查看我写的第一节课文章

https://blog.csdn.net/weixin_43823156/article/details/120733512?spm=1001.2014.3001.5501

Redis是一种高级的kye-value数据结构，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务 器。
Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)

如果在redis中没有做持久化，机器重启，数据就会全部丢失，于是需要开启redis的持久化功能

RDB快照
在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。
你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次
数据集。
比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次
数据集：

save 60 1000 //关闭RDB只需要将所有的save保存策略注释掉即可

RDB（默认开启，只有触发到redis.conf中的save命令条件就会自动生成）

还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件，
每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。

bgsave写时复制（COW）机制
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入到内存中，实际上时操作过程中fork一个子进程，先将数据集写入一个临时文件，写入成功后，再替换之前的文件，用二进制压缩存储

AOF持久化(默认配置不开启，需要自己开启)将修改的每一条指令记录进文件appendonly.aof中(先写入os cashe,每隔一段时间fsync到磁盘中)
修改配置文件打开AOF功能

appendonly yes
appendfilename “appendonly.aof”

你可以再redis多久才将数据fsyn到磁盘中

1 appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。 2
appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。 3
appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

如下两个配置可以控制AOF自动重写频率

1 # auto‐aof‐rewrite‐min‐size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就
很快，重写的意义不大 2 # auto‐aof‐rewrite‐percentage 100
//aof文件自上一次重写后文件大小增长了100%则再次触发重写 当然

AOF还可以手动重写，进入redis客户端执行命令
bgrewriteaof重写AOF
注意，AOF重写redis会fork出一个子进程去做(与bgsave命令类似)，不会对redis正常命令处理有太多
影响
3、二者优缺点
RDB存在哪些优劣势呢？
1.一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。
2.对于灾难恢复而言，RDB是非常不错的选择，是二进制恢复非常快
3.性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
4.相比于AOF机制，如果数据集很大，RDB的启动效率会更高
RDB有那些劣势
当服务宕机时，还没有进行数据备份，会导致数据丢失。

AOF的优劣势
1.该机制更好的数据安全性，Redis提供了三种同步策略，既，每秒同步，每修改同步，不同步
2.由于该机制对日志文件的写入操作采用的是append模式
3.由于该机制对日志文件的写入操作采用的是append模式
AOF的劣势有哪些呢？
1。对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快
2。二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能

Redis主从架构

redis的主从架构搭建非常的简单，只需要配置节点的步骤
再redis.conf配置文件中

上一节有我按照redis的步骤
这里我直接配置从节点

1、复制一份redis.conf文件

2、将相关配置修改为如下值： port 6380 pidfile /var/run/redis_6380.pid #
把pid进程号写入pidfile配置的文件 logfile “6380.log” dir
/usr/local/redis‐5.0.3/data/6380 # 指定数据存放目录 # 需要注释掉bind # bind
127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通 过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）

3、配置主从复制 replicaof 192.168.247.156 6379 # 从本机6379的redis实例复制数据，Redis
5.0之前使用slaveof replica‐read‐only yes # 配置从节点只读

4、启动从节点 redis‐server redis.conf

5、连接从节点 redis‐cli ‐p 6380

6、测试在6379实例上写数据，6380实例是否能及时同步新修改数据

7、可以自己再配置一个6381的从节点

Redis的主从工作原理
如果你为master配置了一个salve节点,不管这个salve是否时第一次连接master,他都会发送一次pysnc命令给master请求开始进行复制数据。
master收到了salve发送过来的命令，会在后台进行数据持久化通过bgsave生成最新的rdb快照文件，持久化期间，master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完
毕以后，master会把这份rdb文件数据集发送给slave，slave会把接收到的数据进行持久化生成rdb，然后
再加载到内存中。然后，master再将之前缓存在内存中的命令发送给slave。
当master与slave之间的连接由于某些原因而断开时，slave能够自动重连Master，如果master收到了多
个slave并发连接请求，它只会进行一次持久化，而不是一个连接一次，然后再把这一份持久化的数据发送
给多个并发连接的slave。

数据部分复制
当master和slave断开重连后，一般都会对整份数据进行复制。但从redis2.8版本开始，redis改用可以支
持部分数据复制的命令PSYNC去master同步数据，slave与master能够在网络连接断开重连后只进行部分
数据复制(断点续传)。
master会在其内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，master和它所有的
slave都维护了复制的数据下标offset和master的进程id，因此，当网络连接断开后，slave会请求master
继续进行未完成的复制，从所记录的数据下标开始。如果master进程id变化了，或者从节点数据下标
offset太旧，已经不在master的缓存队列里了，那么将会进行一次全量数据的复制。
主从复制(部分复制，断点续传)流程图

如果有很多节点，防止主从风暴（多个从节点同时复制主节点导致主节点压力过大），一般把从节点再挂主节点

Redis哨兵搭建高可用

sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。
哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过
sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis
主节点通知给client端(这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)

redis哨兵架构搭建步骤

复制一份sentinel.conf文件 cp sentinel.conf sentinel‐26379.conf
2、将相关配置修改为如下值： port 26379 daemonize yes pidfile
“/var/run/redis‐sentinel‐26379.pid” logfile “26379.log” dir
“/usr/local/redis‐5.0.3/data” # sentinel monitor <master‐redis‐name>
<master‐redis‐ip> <master‐redis‐port> #
quorum是一个数字，指明当有多少个sentinel认为一个master失效时(值一般为：sentinel总数/2
+1)，master才算真正失效 sentinel monitor mymaster 192.168.247.156 6379 2 # mymaster这个名字随便取，客户端访问时会用到

3、启动sentinel哨兵实例 src/redis‐sentinel sentinel‐26379.conf

4、查看sentinel的info信息 src/redis‐cli ‐p 26379
127.0.0.1:26379>info 可以看到Sentinel的info里已经识别出了redis的主从

5、可以自己再配置两个sentinel，端口26380和26381，注意上述配置文件里的对应数字都要修改

哨兵搭建非常的简单，记在redis.conf如果是搭建作为主节点的话，replicaof不要配置，删除当前行，不然不会出现主节点的