一篇文章教你学会Redis的持久化，读写分离和缓存过期与内存淘汰机制
文章目录
-
-
-
- Redis的持久化机制
-
- RDB
-
- 优点
- 缺点
- RDB配置
- 总结：RDB适合大量数据的恢复，但是数据的完整性和一致性可能会不足。
- AOF
-
- 优点
- 缺点
- AOF配置
- 到底采用RDB还是AOF呢？
- aof重写机制
- Redis的主从复制，读写分离
-
- 主从复制原理解析
- Redis主从复制配置
- Redis缓存过期机制（清理过期的缓存）
-
- （主动）定期删除
-
- hz配置
- （被动）惰性删除
- 内存淘汰机制(清理没有过期的缓存)
-
-
Redis的持久化机制
RDB
每隔一段时间，把内存中的数据写入磁盘的临时文件，作为快照，恢复的时候把快照文件读进内存。如果宕机重启，那么内存里的数据肯定会没有的，那么再次启动redis后，则会恢复。
优点
1.可以存放不同的版本
2.非常方便的存放和恢复，可以远程传输
3.备份文件完整
4.迅速的恢复
缺点
1.如果在备份的过程中出现问题，备份文件会丢失，有可能有数据的不一致性
2.如果数据集比较大，可能对CPU影响比较大
3.不能实时备份
RDB配置
RDB配置路径：/usr/local/redis/6379.connf注：每个人的路径可能不一样，就是redis的核心配置文件中。
配置文件都在这个SNAPSHOTTING下面：
- 首先第一个：save
保存机制
save 900 1 *如果一个缓存更新，则900秒后备份
save 300 10 *如果10个缓存更新，则300秒后备份
save 60 10000 *如果10000个缓存更新，则60秒后备份
- 第二个：stop-writes-on-bgsave-error
设置如果save的过程出错，是否停止写操作（用来保证备份文件的稳定）
yes：如果save过程出错，则停止写操作
no：可能造成数据不一致
- 第三个：rdbcompression
是否开启压缩备份文件
yes：开启rdb压缩模式
no：关闭，会节约cpu损耗，但是文件会大
- 第四个：rdbchecksum
是否使用CRC64算法校验对rdb进行数据校验
yes：使用CRC64算法校验对rdb进行数据校验，有10%性能损耗
no：不校验
- 第五个：dbfilename
备份文件名称
第六个：dir
备份文件存放路径
总结：RDB适合大量数据的恢复，但是数据的完整性和一致性可能会不足。
AOF
以日志的形式来记录用户请求的写操作。读操作不会记录，因为写操作才会存存储。文件以追加的形式而不是修改的形式。redis的aof恢复其实就是把追加的文件从开始到结尾读取执行写操作。
优点
1.AOF更加耐用，可以以秒级别为单位备份，如果发生问题，也只会丢失最后一秒的数据，大大增加了可靠性和数据完整性。所以AOF可以每秒备份一次，使用fsync操作。
2.以log日志形式追加，如果磁盘满了，会执行 redis-check-aof 工具当数据太大的时候，redis可以在后台自动重写aof。
3.当redis继续把日志追加到老的文件中去时，重写也是非常安全的，不会影响客户端的读写操作。
AOF 日志包含的所有写操作，会更加便于redis的解析恢复。
缺点
1.相同的数据，同一份数据，AOF比RDB大针对不同的同步机制，AOF会比RDB慢，因为AOF每秒都会备份做写操作，这样相对与RDB来说就略低。
2.每秒备份fsync没毛病，但是如果客户端的每次写入就做一次备份fsync的话，那么redis的性能就会下降。
3.AOF发生过bug，就是数据恢复的时候数据不完整，这样显得AOF会比较脆弱，容易出现bug，因为AOF没有RDB那么简单，但是呢为了防止bug的产生，AOF就不会根据旧的指令去重构，而是根据当时缓存中存在的数据指令去做重构，这样就更加健壮和可靠了。
AOF配置
AOF配置路径：/usr/local/redis/6379.connf注：每个人的路径可能不一样，就是redis的核心配置文件中。
配置文件都在这个APPEND ONLY MODE下面：
- 第一个appendonly
是否开启AOF
yes 开启
no 不开启
- 第二个appendfilename
备份文件名称
- 第三个appendfsync
备份模式
# no：不同步
# everysec：每秒备份，推荐使用
# always：每次操作都会备份，安全并且数据完整，但是慢性能差
- 第四个no-appendfsync-on-rewrite
重写的时候是否要同步
yes 同步
no 不同步，推荐这个，安全
- 第五个auto-aof-rewrite-percentage和auto-aof-rewrite-min-size
重写机制：避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时旧的aof文件不会被读取使用，类似rdb
# 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
到底采用RDB还是AOF呢？
1.如果你能接受一段时间的缓存丢失，那么可以使用RDB
2.如果你对实时性的数据比较care，那么就用AOF
3.使用RDB和AOF结合一起做持久化，RDB做冷备，可以在不同时期对不同版本做恢复，AOF做热备，保证数据仅仅只有1秒的损失。当AOF破损不可用了，那么再用RDB恢复，这样就做到了两者的相互结合，也就是说Redis恢复会先加载AOF，如果AOF有问题会再加载RDB，这样就达到冷热备份的目的了。
aof重写机制
aof的重写虽然叫做重写，但其实是以一种更省内存的方式去存储备份文件。
Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多。
具体可以看这篇文章：Redis之AOF重写及其实现原理
Redis的主从复制，读写分离
主从复制原理解析
首先我们会有两种节点，一种master主节点，一种slave从节点也就是奴隶节点，主要是用来处理一些读的请求，首先我们会启动master，然后我们会配置master配置到slave节点里面，然后我们配置并启动slave节点，当slave节点启动后会ping我们的master节点，告诉master节点，我启动了给我点事情做吧，这个时候master节点会把自己的RDB文件先拷贝到自己的磁盘里面然后传递到slave节点中，slave先把这个RDB文件下载到本地，然后在加载到内存里面去，这样就完成复制过程，这个过程是第一次初始话的过程，在第一次以后，第二次第三次每次master写一条都会同步的传递到slave节点下面，如此就做到了同步。
Redis主从复制配置
需要那台Redis当从机，就修改那台机器的配置文件
配置路径：/usr/local/redis/6379.connf注：每个人的路径可能不一样，就是redis的核心配置文件中。
配置文件都在这个REPLICATION下面：
- 第一步配置主节点replicaof
# masterip 主节点内网ip
# masterport 主节点redis端口
replicaof
- 第二步配置主节点的密码masterauth
masterauth root
- 第三步 设置从节点只读replica-read-only
replica-read-only yes
- 最后实现效果
# 查看redis信息
info replication
这样就实现了redis的读写分离
Redis缓存过期机制（清理过期的缓存）
（主动）定期删除
redis定期定时的做一个检查，抽查随机一批key，key的多少可以进行设置，一旦发现key过期了就会给他删掉
hz配置
#设置一次抽查多少个kye
hz 10
（被动）惰性删除
当客户端请求一个已经过期的key的时候，那么redis会检查这个key是否过期，如果过期了，则删除，然后返回一个nil。这种策略对cpu比较友好，不会有太多的损耗，但是内存占用会比较高。
内存淘汰机制(清理没有过期的缓存)
内存占满了，可以使用硬盘，来保存，但是没意义，因为硬盘没有内存快，会影响redis性能。所以，当内存占用满了以后，redis提供了一套缓存淘汰机制：MEMORY MANAGEMENT，清理的放到内存中没有过期的key，这个在配置文件中也可以配置，有几种清理机制
maxmemory：当内存已使用率到达，则开始清理缓存
maxmemory-policy:可以在这块选择清理机制
清理机制解读：
* noeviction：旧缓存永不过期，新缓存设置不了，返回错误
* allkeys-lru：清除最少用的旧缓存，然后保存新的缓存（推荐使用）
* allkeys-random：在所有的缓存中随机删除（不推荐）
* volatile-lru：在那些设置了expire过期时间的缓存中，清除最少用的旧缓存，然后保存新的缓存
* volatile-random：在那些设置了expire过期时间的缓存中，随机删除缓存
* volatile-ttl：在那些设置了expire过期时间的缓存中，删除即将过期的
如果觉得写得还可以，希望可以给我赞，您的赞是我前进的最大动力！！！