小李同学参加了美团的面试，结果看起来并不理想。他在面试中遇到了一道难题，要求他总结出哪些情况可能导致Redis阻塞。正好我最近在研究Redis，因此我决定整理一下相关内容，分享给大家。

命令导致的阻塞

不当使用某些命令会导致客户端出现阻塞：

  • keys *：这个命令会获取所有的key；
  • Hgetall：用于返回哈希表中所有字段的值；
  • smembers：返回集合中的所有成员。

这些命令的时间复杂度为O(n)，在处理较大数据集时，可能需要全表扫描，导致耗时加长，从而造成客户端阻塞。

SAVE命令引发的阻塞

我们都知道，Redis在进行RDB快照时，会使用系统函数fork()来创建子线程以完成临时文件的写入。这一过程由配置文件中的save配置启动。若达到设定条件，则会触发bgsave命令以创建快照，此方式不会阻塞主线程；然而，手动执行save命令则会在主线程中执行，这将导致阻塞。

同步持久化造成的阻塞

当Redis直接记录AOF日志，并且配置为同步持久化时：

appendfsync always

每次数据更改都会立即写入磁盘，这会花费较长时间，导致性能下降，从而引发主线程阻塞。

AOF重写过程中的阻塞

  1. 在执行BGREWRITEAOF命令时，Redis会fork出一个子线程来重写AOF文件，并维护一个重写缓冲区，记录所有写命令。
  2. 子线程完成新AOF文件后，服务器将重写缓冲区内容添加到新文件末尾，以确保新文件与数据库状态一致。
  3. 最后，服务器用新的AOF文件替换旧文件，从而完成重写。

在第2步中，将数据写入新文件的过程可能会导致阻塞。

AOF日志的特点

AOF日志记录方式为先执行命令后记录日志，而非事务型数据库的方式。这种方式避免了对命令的语法检查，从而减少了额外开销。尽管这可以避免对当前命令的执行造成阻塞，但在写日志文件时，若磁盘写入压力过大，仍有可能导致后续操作被阻塞。

大Key问题

“大Key”指的是与其对应的value非常大的情况，造成的阻塞问题包括：

  • 客户端超时阻塞：Redis使用单线程处理命令，操作大Key时耗时较长，导致阻塞，客户端可能会长时间无响应。
  • 网络阻塞：获取大Key所产生的网络流量较大，例如，一个1MB大小的Key每秒访问1000次，每秒流量可达1000MB。
  • 阻塞工作线程：使用del命令删除大Key时，可能会阻塞工作线程，从而影响后续命令的处理。

查找大Key的建议

使用Redis的--bigkeys参数查找大Key时，建议在从节点上执行，以免阻塞主节点。也可以使用SCAN命令或分析RDB文件的方法查找大Key，工具包括：

  • redis-rdb-tools：用于分析Redis RDB快照文件的Python工具；
  • rdb_bigkeys：性能更佳的Go语言工具。

删除大Key的影响

删除操作不仅仅是释放键值对占用的内存，操作系统还需将释放的内存块插入空闲内存块链表中以便后续管理和再分配。这一过程会花费时间，若一次性释放大量内存，可能导致Redis主线程阻塞，从而影响所有请求的处理，造成连接耗尽等异常。

对于删除大Key，建议采用分批次和异步删除的方式，以减轻影响。

清空数据库的影响

清空操作如flushdb、flushall将涉及删除和释放所有键值对，因此也可能成为Redis的阻塞点。

集群扩容的挑战

Redis集群支持节点的动态扩容和缩容，但这一过程仍需一定的人工介入，且数据迁移是同步操作。在迁移期间，Redis会进入阻塞状态，尤其是在处理大Key时，可能导致集群故障转移，造成不必要的服务切换。