1 redis持久化
1.1 RDB 持久化方案
1.2 AOF持久化
1.3 混合持久化
2 redis主从复制
1 redis持久化
# 把redis数据从内存保存到硬盘上的过程称之为持久化
# 所有的数据库，持久化方案
快照：某时某刻数据的一个完成备份
-mysql的Dump： mysqldump -uroot -p123456 -luffy >/data/mysqlDump/mydb.sql
-redis的RDB:
写日志：任何操作记录日志，要恢复数据，只要把日志重新走一遍即可
-mysql的 Binlog
-Redis的 AOF
1.1 RDB 持久化方案
# 三种方案触发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持久化
# 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 混合持久化
# 混合持久化原理
在开启混合持久化的情况下，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主从复制
# 主从复制是什么？
机器故障；容量瓶颈；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
