两万字 redis.conf 7.0 配置和原理全解，生产王者必备( 六 ) _redis.

UNLINK（非阻塞删除）、(异步删除) FLUSHALL ASYNC/FLUSHDB ASYNC：后台回收内存，这些指令在常量级别时间内执行，会使用一个新的线程在后台渐进的删除并释放内存（Lazy Free 机制）。

1、lazyfree-lazy-eviction
由于 maxmemory 和 maxmemory-policy 策略配置，我会删除一些数据，防止内存爆掉。使用lazyfree-lazy-eviction yes表示使用 lazy free 机制，该场景开启 lazy free 可能会导致淘汰数据的内存释放不及时，出现内存超限。
2、lazyfree-lazy-expire
对于设置了 TTL 的键，过期后删除。如果想启用 lazy free 机制删除，则配置 lazyfree-lazy-eviction yes 。
3、lazyfree-lazy-server-del
针对有些指令在处理已存在的键时，会带有一个隐式的 DEL 键的操作。
如 rename 命令，当目标键已存在，我会先删除目标键，如果这些目标键是一个 big key，那可能会出现阻塞删除的性能问题。此参数设置就是解决这类问题，建议配置 lazyfree-lazy-server-del yes 开启。
4、replica-lazy-flush
该配置针对 slave 进行全量数据同步，在加载 master 的 RDB 内存快照文件之前，会先运行 flashall清理数据的时候是否采用异步 flush 机制。
推荐你使用 replica-lazy-flush yes配置，可减少全量同步耗时，从而减少 master 因输出缓冲区暴涨引起的内存增长。
5、lazyfree-lazy-user-del
意思是是否将 DEL 指令的默认行为替换成 lazy free 机制删除，效果就跟 UNLINK 一样，只要配置成 lazyfree-lazy-user-del yes 。
6、lazyfree-lazy-user-flush
FLUSHDB, FLUSHALL, SCRIPT FLUSH, FUNCTION FLUSH可以使用额外参数 ASYNC|SYNC 决定使用同步还是异步操作，当没有指定这个可选项，可以通过 lazyfree-lazy-user-flush yes 表示使用异步删除。
7、IO 多线程
大家知道我是单线程模型处理读写请求，但是有一些操作可以使用其他线程处理，比如 UNLINK，I/O 读写操作。
在 6.0 版本，我提供了 I/O 多线程处理 Socket 读写，利用 I/O 多线程可以提高客户端 Socket 读写性能。
默认配置是关闭的，我只建议当你的机器至少是 4 核 CPU 或者更多的情况启用，并且配置的线程数少于机器总 CPU 核数，配置超过 8 个线程对提升没什么帮助。
当你的机器是四核 CPU，那可以尝试配置使用 2~3 个 I/O 线程，如果是 8 核 CPU，一般只需要配置 6 个线程。
如下配置表示开启 I/O 线程组，线程组的 I/O 线程数量为 3 。
io-threads-do-reads yesio-threads 3七、AOF 持久化除了 RDB 内存快照文件作为持久化手段以外，还能使用 AOF(Append only file) 实现持久化，AOF 是一种可选的持久化策略提供更好数据安全性。
默认配置下，我最多只会丢失一秒的数据，你甚至可以配置更高级别，最多只丢失一次 write 操作，但这样会对损耗性能。
1、appendonly
appendonly yes 表示开启 AOF 持久化，可以同时开启 AOF 和 RDB 内存快照持久化，如果开启了 AOF ，我会先加载 AOF 用于恢复内存数据。
2、appendfilename
指定 AOF 文件名称，默认名字是 appendonly.aof 。为了方便，你可以配置 appenddirname 指定 AOF 文件存储目录。
3、appendfsync
调用操作系统的 fsync()函数告诉操作系统把输出缓冲区的数据持久化到磁盘，AOF 文件刷写的频率有三种。

no：不去主动调用 fsync()，让操作系统自己决定何时写磁盘。
always：每次 write 操作之后都调用 fsync()，非常慢，但是数据安全性最高。
everysec：每秒调用一次 fsync()，一个折中的策略，最多丢失一秒的数据。

默认配置是 appendfsync everysec，推荐大家这么设置，兼顾了速度和数据安全。
4、no-appendfsync-on-rewrite
当 appendfsync 的配置设置成 always或者 everysec ，现在有一个后台 save 进程（可能是生成 RDB 内存快照的 bgsave 进程，也有可能是 AOF rewrite 进程）正在进行大量的磁盘 I/O 操作，会造成调用 fsync()执行太长，后续其他想要调用 fsync() 的进程就会阻塞。
为了缓解这个问题，可以使用以下配置 no-appendfsync-on-rewrite yes 表示当已经有 bgsave和bgrewriteaof 后台进程在调用 fsync() 时，不再开启新进程执行 AOF 文件写入。
这样的话，就会出现当前有子进程在做 bgsave 或者其他的磁盘操作时，我就无法继续写 AOF 文件，这意味着可能会丢失更多数据。
如果有延迟问题，请将此选项改为 yes 。否则将其保留为 no 。从持久化的角度来看，no是最安全的选择。