Redis在延迟问题上的那些突破，聊聊它到底怎么解决卡顿的

Redis之所以快,核心在于其内存存储和单线程架构，但“快”不代表没有延迟，随着数据量增长、网络环境复杂化和使用场景的严苛，延迟（也就是我们感觉到的“卡顿”）就成了必须面对的问题，Redis在发展过程中，针对不同来源的延迟，做出了一系列关键的突破。

应对自身操作引发的延迟：把“大活儿”化整为零

早期Redis一个典型的延迟陷阱是某些命令本身就很“重”，要删除一个包含数百万个元素的超大集合（Key），DEL命令会一次性在内存中清理所有数据，这个操作会独占Redis的单线程很久，导致期间所有其他命令都得排队等着，整个服务就像卡住了一样。

突破点：惰性删除（Lazy Free）机制。 （来源：Redis 4.0版本特性） Redis 4.0引入了惰性删除，它不再傻乎乎地当场执行繁重的删除任务，当你使用UNLINK命令（替代DEL）删除大Key时，Redis只是先把Key从键空间里“摘掉”，让客户端立刻无法访问，然后把这个耗时的内存释放任务丢给后台的特定线程去慢慢处理，这样，执行命令的主线程就能迅速返回，去处理接下来的请求，卡顿感就消失了，除了删除，类似的思想也用在了FLUSHDB和FLUSHALL这些清空数据库的命令上，提供了异步选项。

应对持久化带来的延迟：找到速度与安全的平衡点

Redis把数据存在内存,但为了故障恢复，需要把数据写入硬盘（持久化），写硬盘的速度比写内存慢好几个数量级，这是延迟的主要来源之一。

突破点1：AOF日志的优化——从“每次都刷盘”到“让操作系统决定”。 （来源：Redis不同版本的AOF策略演进） Redis的AOF持久化像写日记，记录每一个写命令，最安全的方式是每执行一个命令就强制刷到硬盘（appendfsync always），但这太慢了，于是Redis提供了折衷方案：appendfsync everysec（每秒刷一次盘），这平衡了性能和数据安全，成为默认配置，但即使这样，每秒一次的峰值延迟也可能波动，更进一步的优化是appendfsync no，完全交由操作系统决定何时刷盘，性能最好，但可能丢失最近几秒的数据。

突破点2：AOF重写机制。 （来源：Redis持久化设计核心机制） AOF文件会越来越大，而且里面可能有很多重复操作（比如某个值被改了100次，前99次记录都是多余的），重写AOF就是 fork 出一个子进程，根据当前内存中的数据快照，重建一个更精简的AOF文件，这个过程由后台进程完成，不影响主线程服务，但fork操作本身，在数据量巨大时，可能会因为复制父进程内存页表而产生短暂的延迟，针对这点，Redis在后继版本中持续优化fork的效率。

应对庞大内存管理的延迟：让分配和回收更高效

当Redis占用内存很大时,哪怕只是单纯的内存分配与回收，也可能引起卡顿。

突破点： Jemalloc内存分配器的引入与持续优化。 （来源：Redis官方文档关于内存优化的说明） Redis很早就从默认的libc内存分配器切换到了Jemalloc。Jemalloc能更有效地减少内存碎片，并且在大内存场景下，分配和释放内存的性能更好、更可预测，这从底层减少了因内存管理不当而引发的延迟毛刺，Redis团队会随着Jemalloc版本的更新而跟进，确保使用最优的分配器。

应对网络与多租户的干扰：隔离与卸载

突破点1：多线程IO（I/O Threads）. （来源：Redis 6.0版本特性） 这是里程碑式的突破，Redis的核心执行命令逻辑仍是单线程，这避免了锁竞争，保证了简单性，但在Redis 6.0之前，连读取客户端请求数据和写回响应数据这个网络IO的活儿，也是主线程亲力亲为，当有大量慢速客户端时，主线程会耗费大量时间在IO上。 Redis 6.0引入了多线程IO，主线程只负责最核心的命令执行，而读取请求和发送响应这些IO任务，可以交给一组后台IO线程并行处理，这样，主线程就能更专注、更快速地处理命令计算，极大缓解了在高并发场景下因网络IO堆积造成的延迟。

突破点2：Redis Cluster与代理（Proxy）模式。 （来源：Redis分布式架构的演进） 当单个Redis实例的性能达到瓶颈时，延迟必然上升，Redis Cluster通过分片（Sharding）将数据分布到多个实例上，每个实例只负责一部分数据，从而分散了压力和数据量，从根本上降低了单个节点的延迟，像Twemproxy、Codis这类代理方案，以及Redis自身在发展的Redis Cluster Proxy，帮助客户端屏蔽了分片的复杂性，同时也能够整合连接，减轻Redis服务器的连接管理压力，间接优化了延迟。

Redis解决延迟问题，不是一个“银弹”，而是一个系统工程，它的思路非常清晰：首先守住单线程执行模型的简单性优势，然后将任何可能引起延迟的、繁重的、可剥离的任务，尽可能地“卸载”到后台异步执行或并行处理。 从惰性删除到多线程IO，再到通过集群分片进行水平扩展，无一不是这一思想的体现，这些突破使得Redis在保持“快”的初心的同时，能够适应越来越复杂和苛刻的应用环境，有效地解决“卡顿”问题。