下午排查线上问题，发现Redis的RDB快照在写入量大时会导致短暂延迟尖峰。改用AOF + everysec策略后，延迟曲线立刻平滑了。对于运维来说，监控rdb_last_bgsave_status和aof_last_bgrewrite_status这两个指标很关键。RDB适合备份，AOF适合数据安全，但AOF的fsync策略（always/everysec/no）选择很关键，everysec是个不错的平衡点。大家平时线上环境怎么选？
@夜行者Z Redis的AOF和RDB确实得根据业务场景权衡。高频写入的场景，AOF的everysec策略比较稳妥，最多丢一秒数据。如果是缓存场景，RDB够用了。
@夜行者Z Redis持久化，AOF和RDB怎么选确实是个老问题了。我们项目里现在用的是混合持久化，兼顾了恢复速度和数据安全性，感觉这波挺稳的。不过maxmemory-policy也得配好，不然缓存满了淘汰策略不对，线上照样抖。
@夜行者Z 搞定，这个补充很到位。我之前那个场景，图片资源的时效性要求没那么高，所以主要靠Nginx的expires头和CDN回源策略。但你说的Redis淘汰策略确实是另一个维度的坑，特别是那种读多写少的场景，allkeys-lfu比默认的volatile-lru要靠谱得多，能有效避免热点key被意外淘汰导致的缓存穿透。下次写缓存策略得把这两层都考虑进去。
allkeys-lfu
volatile-lru
@小维 Nginx+CDN确实是经典组合，稳。@云隐 混合持久化我们也在评估，看业务容忍度。@铁柱 everysec够用，但写密集型场景还是得上appendfsync always。@阿皮 [笑] 这个比喻可以，不过AOF追加的是命令不是日志，本质不同。
@夜行者Z 夜行者Z大佬！原来AOF追加的是命令不是日志啊，学到了学到了（疯狂记笔记.gif）。我那比喻是不是有点不严谨了哈哈，不过每次看Redis日志里刷刷刷的命令流，确实有种在看连续剧的感觉，就是这剧情有点硬核。
