Redis持久化、主从架构和哨兵架构

Redis数据持久化的三种方式，基本的架构模型，主从架构和哨兵架构。主从架构是哨兵架构以及后续的分布式集群架构的基础。

Redis持久化

RDB（Redis DataBase）快照（snapShot）

基本设置

1
2
3
4

# 在redis配置文件中做如下配置即可，redis在满足配置时就会自动进行持久化到本地文件中
# 60秒内至少改动1000个键值对，就会触发
save 60 1000 
# 保存的为二进制内容

save和bgsave

优点

1、整个Redis数据库将只包含一个文件 dump.rdb，方便持久化。

2、容灾性好，方便备份。

3、性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO 最大化。使用单独子进 程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能

4、相对于数据集大时，比 AOF 的启动效率更高。

缺点

1、数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢 失。所以这种方式更适合数据要求不严谨的时候)

2、由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导 致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF(append-only file)

基本配置

1
2
3
4
5

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

aof保存的是最新的set操作命令

AOF（Append Only File）重写

以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以 打开文件看到详细的操作记录。

基本配置

1
2
3
4
5

# aof重写会将一些无用命令重新合并，最终数据肯定还是和原先的一致
# aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大
auto-aof-rewrite-min-size 64mb   
# aof文件自上一次重写后文件大小增长了100%则再次触发重写
auto-aof-rewrite-percentage 100

AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF

注意，AOF重写redis会fork出一个子进程去做(与bgsave命令类似)，不会对redis正常命令处理有太多影响

RDB和AOF对比

优点

1、数据安全，Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也 是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据 将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁 盘中。

2、通过 append 模式写文件，即使中途服务器宕机也不会破坏已经存在的内容，可以通过 redis-check-aof 工具解决数据一致性问题。

3、AOF 机制的 rewrite 模式。定期对AOF文件进行重写，以达到压缩的目的

缺点

1、AOF 文件比 RDB 文件大，且恢复速度慢。

2、数据集大的时候，比 rdb 启动效率低。

3、运行效率没有RDB高

AOF文件比RDB更新频率高，优先使用AOF还原数据。

AOF比RDB更安全也更大

RDB性能比AOF好

如果两个都配了优先加载AOF

Redis4.0后的混合持久化

基本配置

1
2

# 混合持久化是基于aof持久化的优化，使用混合持久化必须先开启aof
aof-use-rdb-preamble yes

Redis数据备份策略

1. 写crontab定时脚本，每个小时复制一份Redis持久化文件
2. 每天都保留一份数据，保留最新一月或根据需求保存，方便可随时恢复至任意日期
3. 每天复制数据时，删除最早数据，以免浪费内存
4. 多机备份，定期将备份文件复制只不同数据备份机器

Redis数据恢复

将Reids备份文件，放在Redis对应的备份文件路径下重启服务即可

Redis主从架构

基本配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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  # 指定数据存放目录
3、配置主从复制
replicaof 192.168.0.60 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的从节点

全量复制

从节点首次同步数据或长时间断开链接，主节点和从节点之前数据差超过了master节点缓存队列中的数据时会采用全量复制

部分复制

master会在其内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，master和它所有的slave都维护了复制的数据下标offset和master的进程id，因此，当网络连接断开后，slave会请求master继续进行未完成的复制，从所记录的数据下标开始。如果master进程id变化了，或者从节点数据下标offset太旧，已经不在master的缓存队列里了，那么将会进行一次全量数据的复制。

主从复制风暴

Redis哨兵高可用架构

基本配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

1、复制一份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>
# quorum是一个数字，指明当有多少个sentinel认为一个master失效时(值一般为：sentinel总数/2 + 1)，master才算真正失效
sentinel monitor mymaster 192.168.0.60 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，注意上述配置文件里的对应数字都要修改

操作中遇到的问题

1. 配置主从模式时，要注意主节点不能配置replicaof
2. bind 0.0.0.0

• ← Previous Post
• Next Post →

...

...

00:00

00:00