Redis HMGET命令性能异常原因咨询

• 哈希表O(1)是平均复杂度，非绝对开销
  哈希表查询的O(1)是平均时间复杂度，实际场景中Redis哈希表存在冲突时，会用链表（或红黑树，当链表长度超过阈值）存储冲突元素。单次HMGET请求10000个键时，每个键都可能需要遍历冲突链来确认存在性，累积下来实际开销会趋近于O(N)，N为键的数量。

• 单线程模型下的命令阻塞效应
  Redis采用单线程处理命令请求，单次HMGET处理10000个键的查询、结果组装会占用主线程大量CPU时间。高请求量下，这类大命令会在任务队列中排队，导致主线程持续处于忙碌状态，CPU使用率直接飙升——因为没有空闲时间处理其他轻量请求，所有CPU资源都被消耗在批量查询和数据处理上。

• 批量数据的内存拷贝与序列化开销
  查询到的10000个键对应的value需要从哈希表内存空间拷贝到网络缓冲区，这个拷贝过程是CPU密集型的；同时，Redis需要将这些结果序列化成RESP协议格式返回给客户端，批量数据的序列化操作会进一步消耗CPU资源，尤其是当value本身长度较大时，开销会呈指数级上升。

• 哈希表内部操作的累积开销
  每个键的查询都需要经历哈希值计算、桶定位、键存在性校验等步骤，10000次重复操作的累积开销不可忽视。如果哈希表负载因子较高，冲突概率上升，遍历冲突链的时间会进一步增加，放大CPU消耗。

• 命令参数解析的额外消耗
  HMGET命令传入10000个键参数时，Redis需要先完成参数的解析与校验，这个过程需要逐个处理每个键的字符串，在高请求量下，这类解析操作的CPU消耗会被持续放大。

内容的提问来源于stack exchange，提问作者刘大力