Redis中Keysizes直方图在Flush后残留的问题分析

问题背景

在Redis数据库操作过程中，开发者发现了一个关于keysizes统计信息的有趣现象：当执行同步方式的flushdb/flushall命令时，keysizes直方图统计信息会异常地保留下来，而不是像预期那样被清空。这个问题在异步flush操作时不会出现，但在同步flush操作时就会显现。

技术细节解析

Redis内部使用kvstoreMetadata结构来存储keysizes的直方图统计信息。当执行flush操作时，系统会调用kvstoreEmpty函数来清空键值存储。然而，原始实现中存在一个逻辑缺陷：

1. 函数会正确清空每个字典(dict)的直方图统计
2. 但遗漏了对kvstore级别的直方图统计的清空操作

这种不一致性导致了统计信息的残留现象。特别值得注意的是，在异步flush场景下，由于会分配一个新的空kvstoreMetadata结构，这个问题反而不会显现，这使得问题更加隐蔽。

问题复现路径

开发者提供了两种复现方式：

1. 正常同步flush：

   • 设置一个键值对
   • 查看keysizes统计信息（显示有数据）
   • 执行flushdb
   • 再次查看keysizes统计信息（预期为空，但实际保留了之前的数据）

2. 事务中的同步flush：

   • 设置一个键值对
   • 查看keysizes统计信息
   • 开启事务(MULTI)
   • 在事务中执行flushdb
   • 提交事务(EXEC)
   • 查看keysizes统计信息（同样保留了之前的数据）

第二种方式通过将flush操作放入事务中，强制Redis使用同步方式执行flush，从而暴露了这个bug。

解决方案

修复方案直接而有效：在kvstoreEmpty函数中添加对kvstore级别直方图的清空逻辑。具体实现是检查KVSTORE_ALLOC_META_KEYS_HIST标志，如果设置，则获取kvstoreMetadata并通过memset清空其keysizes_hist字段。

这个修复确保了无论flush操作是同步还是异步执行，keysizes统计信息都会被正确重置，保持了系统行为的一致性。

问题启示

这个案例展示了几个值得注意的点：

1. 同步/异步路径差异：在系统设计中，同步和异步操作路径的差异可能导致隐蔽的bug，需要特别注意两者行为的一致性。

2. 统计信息的生命周期管理：对于统计类数据的清理需要格外小心，确保所有相关的数据结构都被正确处理。

3. 事务对操作模式的影响：Redis中某些操作在事务上下文中的行为可能与非事务上下文不同，这是测试时需要考虑的重要场景。

这个问题虽然影响范围不大，但很好地说明了即使是成熟如Redis这样的系统，也会存在这类边界条件的处理问题，需要开发者保持警惕。