[1 redis持久化](#1 redis持久化)
[1.1 RDB 持久化方案](#1.1 RDB 持久化方案)
[1.2 AOF持久化](#1.2 AOF持久化)
[1.3 混合持久化](#1.3 混合持久化)
[2 redis主从复制](#2 redis主从复制)
1 redis持久化
python
# 把redis数据从内存保存到硬盘上的过程称之为持久化
# 所有的数据库,持久化方案
快照:某时某刻数据的一个完成备份
-mysql的Dump: mysqldump -uroot -p123456 -luffy >/data/mysqlDump/mydb.sql
-redis的RDB:
写日志:任何操作记录日志,要恢复数据,只要把日志重新走一遍即可
-mysql的 Binlog
-Redis的 AOF
1.1 RDB 持久化方案
python
# 三种方案触发rdb
### 方案一:同步方案--》敲save命令---》会阻塞redis--》如果数据量很大--》会导致其他命令都执行不了
reids客户端敲一个命令 : save
### 方案二:异步方案
reids客户端敲一个命令 : bgsave
### 方案三:配置文件方案---》只要符合条件,会自动生成rdb文件
save 900 1
save 300 10
save 60 10000
如果60s中改变了1w条数据,自动生成rdb
如果300s中改变了10条数据,自动生成rdb
如果900s中改变了1条数据,自动生成rdb
## 最佳配置
save 900 1
save 300 10
save 60 10000
dbfilename dump-6379.rdb #以端口号作为文件名,可能一台机器上很多reids,不会乱
dir /bigdiskpath #保存路径放到一个大硬盘位置目录
stop-writes-on-bgsave-error yes #出现错误停止
rdbcompression yes #压缩
rdbchecksum yes #校验
# 只要在工作目录下有rdb文件,redis重启,就会加载,整个load到内存中
1.2 AOF持久化
python
# RDB问题
耗时,耗性能,不可控,可能会丢失数据
# aof 方案
客户端每写入一条命令,都记录一条日志,放到日志文件中,如果出现宕机,可以将数据完全恢复
# AOF的三种策略
# 日志不是直接写到硬盘上,而是先放在缓冲区,缓冲区根据一些策略,写到硬盘上
always:redis--》写命令刷新的缓冲区---》每条命令fsync到硬盘---》AOF文件
everysec(默认值):redis------》写命令刷新的缓冲区---》每秒把缓冲区fsync到硬盘--》AOF文件
no:redis------》写命令刷新的缓冲区---》操作系统决定,缓冲区fsync到硬盘--》AOF文件
# AOF 重写
set hello world
set hello java set hello hehe
set hello hehe
incr counter
incr counter ======>>> incryby counter 2
rpush mylist a
rpush mylist b rpush myslist a b c
rpush mylist c
过期数据
# 本质就是把过期的,无用的,重复的,可以优化的命令,来优化 这样可以减少磁盘占用量,加速恢复速度
# 咱们只需要做好配置,触发aof重写后,redis会自动开启aof重写,优化 日志
# 配置
auto-aof-rewrite-min-size AOF文件重写需要尺寸
auto-aof-rewrite-percentage AOF文件增长率
# aof持久化方案 --配置方案
appendonly yes #将该选项设置为yes,打开
appendfilename "appendonly-6379.aof" #文件保存的名字
dir /bigdiskpath #保存路径放到一个大硬盘位置目录
appendfsync everysec #采用第二种策略
no-appendfsync-on-rewrite yes #在aof重写的时候,是否要做aof的append操作,因为aof重写消耗性能,磁盘消耗,正常aof写磁盘有一定的冲突,这段期间的数据,允许丢失
appendonly yes
appendfilename "appendonly-6379.aof"
appendfsync everysec
no-appendfsync-on-rewrite yes
## aof和rdb能同时开启吗?
完全可以
# 你们用了那种?
取决于公司业务:对数据要求高,不允许丢失---》就必须使用aof方案
如果允许丢失,就使用rdb方案
1.3 混合持久化
python
# 混合持久化原理
在开启混合持久化的情况下,AOF 重写时会把 Redis 的持久化数据,以 RDB 的格式写入到 AOF 文件的开头,之后的数据再以 AOF 的格式化追加的文件的末尾
# 配置是:
appendonly yes
appendfilename "appendonly-6379.aof"
appendfsync everysec
no-appendfsync-on-rewrite yes
aof-use-rdb-preamble yes #开启了混合持久化
2 redis主从复制
python
# 主从复制是什么?
机器故障;容量瓶颈;QPS瓶颈---》redis进行扩展---》主从复制---》集群
一主一从,一主多从
做读写分离
做数据副本
扩展数据性能
一个master可以有多个slave
一个slave只能有一个master
数据流向是单向的,从master到slave
# 主从复制原理
1. 副本库通过slaveof 127.0.0.1 6379命令,连接主库,并发送SYNC给主库
2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库
3. 副本库接收后会应用RDB快照
4. 主库会陆续将中间产生的新的操作,保存并发送给副本库
5. 到此,我们主复制集就正常工作了
6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库.
7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在.
8. 如果发生主从关系断开时,从库数据没有任何损坏,在下次重连之后,从库发送PSYNC给主库
9. 主库只会将从库缺失部分的数据同步给从库应用,达到快速恢复主从的目的
# 主库是否要开启持久化
如果不开,有可能,主库重启操作,造成所有主从数据丢失!
# 主从搭建
-两台机器---》只有一台机器---》启动两个redis-server 监听不同端口
-从库辅助配置(可以不配)
min-slaves-to-write 1
min-slaves-max-lag 3
#在从服务器的数量少于1个,或者三个从服务器的延迟(lag)值都大于或等于3秒时,主服务器将拒绝执行写命令
-开启两个redis
-从库写
slaveof 127.0.0.1 6379 #异步
slaveof no one #取消复制,不会把之前的数据清除
-通过配置文件
slaveof 127.0.0.1 6379
slave-read-only yes