4-redis高级-redis持久化(RDB 持久化方案、AOF持久化、RDB和AOF混合持久化)、redis主从复制

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