这次彻底读透 Redis ！( 四 ) _小知识

缺点

如果备份间隔时间较长，RDB 会丢失较多的数据。比如 8 点备份一次，8 点半服务器宕机，那么这半小时内的数据就会丢失了

AOF
AOF 持久化是通过日志的方式，记录每次 Redis 的写操作。当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF 命令以Redis 协议追加保存每次写的操作到文件末尾。Redis 还能对 AOF 文件进行后台重写，使得 AOF 文件的体积不至于过大
AOF 持久化配置

# 是否开启 aof no：关闭；yes: 开启 Appendonly no # aof 文件名 appendfilename "appendonly.aof" # aof 同步策略 # appendfsync always # 每个命令都写入磁盘，性能较差 appendfsync everysec # 每秒写一次磁盘，Redis 默认配置 # appendfsync no # 由操作系统执行，默认linux配置最多丢失30秒 # aof 重写期间是否同步 no-appendfsync-on-rewrite no # 重写触发策略 auto-aof-rewrite-percentage 100 # 触发重写百分比 （指定百分比为0，将禁用aof自动重写功能） auto-aof-rewrite-min-size 64mb # 触发自动重写的最低文件体积（小于64mb不自动重写） # 加载aof时如果有错如何处理 # 如果该配置启用，在加载时发现aof尾部不正确是，会向客户端写入一个log，但是会继续执行，如果设置为 no ，发现错误就会停止，必须修复后才能重新加载 。aof-load-truncated yes # aof 中是否使用 rdb # 开启该选项，触发AOF重写将不再是根据当前内容生成写命令 。而是先生成RDB文件写到开头，再将RDB生成期间的发生的增量写命令附加到文件末尾 。aof-use-rdb-preamble yes

AOF 文件写入
aof 文件是命令追加的方式，先将命令写入缓冲区，时间到了再写如磁盘中

appendfsync always # 每个命令都写入磁盘，性能较差 appendfsync everysec # 每秒写一次磁盘，Redis 默认配置 appendfsync no # 由操作系统执行，默认Linux配置最多丢失30秒

上面配置就是何时写入磁盘中
AOF 重写
aof 文件虽然丢失的数据少，但是随着时间的增加，aof 文件体积越来越大，占用磁盘空间越来越大，恢复时间长。所以 redis 会对 aof 文件进行重写，以减少 aof 文件体积
下面以一个例子说明

-- 重写前的 aof set k1 20 set k2 40 set k1 35 set k3 34 set k2 19 -- 这里 k1 最终的值为 35，k2 最终值为 19，所以不需要写入两个命令 -- 重写后 set k1 35 set k3 34 set k2 19

混合持久化
从 Redis 4.0 版本开始，引入了混合持久化机制，纯AOF方式、RDB+AOF方式，这一策略由配置参数aof-use-rdb-preamble（使用RDB作为AOF文件的前半段）控制，默认关闭(no)，设置为yes可开启

no：按照AOF格式写入命令，与4.0前版本无差别；
yes：先按照RDB格式写入数据状态，然后把重写期间AOF缓冲区的内容以AOF格式写入，文件前半部分为RDB格式，后半部分为AOF格式。

混合持久化优点如下：

大大减少了 aof 文件体积
加快了 aof 文件恢复速度，前面是 rdb ，恢复速度快

AOF 数据恢复
第一种：纯 AOF
恢复时，取出 AOF 中命令，一条条执行恢复
第二种：RDB+AOF
先执行 RDB 加载流程，执行完毕后，再取出余下命令，开始一条条执行
AOF 优缺点
优点

AOF 实时性更好，丢失数据更少
AOF 已经支持混合持久化，文件大小可以有效控制，并提高了数据加载时的效率

缺点

对于相同的数据集合，AOF 文件通常会比 RDB 文件大
在特定的 fsync 策略下，AOF 会比 RDB 略慢
AOF 恢复速度比 RDB 慢

Redis 分布式锁分布式锁介绍
学习过 JAVA 的同学，应该对锁都不陌生。Java 中多个线程访问共享资源时，会出现并发问题，我们通常利用 synchronized 或者 Lock 锁来解决多线程并发访问从而出现的安全问题。细心的同学可能已经发现了，synchronized 或者 Lock 锁解决线程安全问题在单节点情况下是可行的，但是如果服务部署在多台服务器上，本地锁就失效了。
分布式场景下，需要采用新的解决方案，就是今天要说的 Redis 分布式锁。日常业务中，类似抢红包，秒杀等场景都可以使用 Redis 分布式锁来解决并发问题。
分布式锁特点
分布式在保障安全、高可用的情况下需要具备以下特性