Redis CMS.MERGE怎样合并多个频次统计

在分站点、分机房或分时间窗口保存频次统计时，最后通常要把多个 Count-Min Sketch 汇总成一个查询入口。Redis 的 CMS.MERGE 负责这件事：它把多个来源 sketch 合并到一个已经初始化的目标 key，成功时返回 OK。真正容易出问题的地方不在命令格式，而在目标参数、来源参数和权重是否对应。

官方地址：https://redis.io/docs/latest/commands/cms.merge/

先把合并现场拆成目标、来源和查询

一次合并可以理解为三组对象：目标 key 用来接收结果，来源 key 保存各自的频次草图，查询 key 负责读取合并后的估算值。目标不是普通字符串，也不是一个可以临时创建的空 key；它要先用相同的 width、depth 初始化。下面用两个站点统计说明最小路径：

# 先用固定 width 和 depth 创建目标与两个来源 sketch
redis-cli CMS.INITBYDIM orders:all 2000 7
redis-cli CMS.INITBYDIM orders:north 2000 7
redis-cli CMS.INITBYDIM orders:south 2000 7

# 分别写入来源统计，INCRBY 的数值是本次增加量
redis-cli CMS.INCRBY orders:north sku:1001 4 sku:1002 2
redis-cli CMS.INCRBY orders:south sku:1001 3 sku:1003 5

# numKeys=2，后面正好跟两个来源 key
redis-cli CMS.MERGE orders:all 2 orders:north orders:south

# 从合并结果读取指定商品的估算频次
redis-cli CMS.QUERY orders:all sku:1001 sku:1003

这里的关键不是把三个 key 写在同一行，而是三个 sketch 的结构参数一致。官方命令说明要求所有 sketch 具有相同的 width 和 depth；如果目标 key 不存在，或目标与来源的参数不一致，命令会返回错误而不是部分合并。

多个频次统计按 source 顺序合并

CMS.MERGE destination numKeys source [source ...] 的读取顺序很固定：先写目标，再写来源数量，再列出来源 key。numKeys 不是目标容量，也不是要合并的元素数量，而是 source sketch 的数量。三地统计就写 3，并在后面列出三个来源。

# 三个来源使用同一组初始化参数，避免结构不兼容
redis-cli CMS.MERGE orders:all 3 orders:north orders:south orders:west

# 成功时 Redis 返回 OK；然后再按业务 key 查询合并值
redis-cli CMS.QUERY orders:all sku:1001

# 只读结构信息，确认目标的 width、depth 和总计数
redis-cli CMS.INFO orders:all

命令的时间复杂度是 O(n)，这里的 n 指参与合并的 sketch 数量。它不是按每个商品逐个遍历，因此适合把分片统计做一次汇总；但大量来源 key 仍会增加单条命令的处理时间，生产环境可以按区域或时间窗口分层合并，避免一次塞入过长的 source 列表。

权重解决的是倍乘，不是修复参数差异

当不同来源代表不同采样比例、批次数量或业务折算系数时，可以追加 WEIGHTS。权重按 source 的位置对应，默认每个来源都是 1。例如北区数据保持原值，南区数据按 3 倍计入：

# 两个权重分别对应 orders:north 和 orders:south
redis-cli CMS.MERGE orders:weighted 2 orders:north orders:south WEIGHTS 1 3

# 读取加权后的估算值；它仍然是 CMS 的近似计数
redis-cli CMS.QUERY orders:weighted sku:1001

权重不会改变 sketch 的 width/depth，也不会把两个不同尺寸的 sketch 变成兼容结构。它只是把来源的计数贡献按倍数加入目标，所以权重列表要和 source 一一对应。若只是普通汇总，不要为了“更准确”随意填大于 1 的数字。

失败与结果偏大按这张清单排查

还要注意集群部署：官方命令页特别提示，集群环境下多 key 操作的行为需要结合集群多 key 规则判断。也就是说，单机上格式正确，不代表跨槽的多个 key 在集群里就能直接执行；部署形态应在上线前单独确认。

相关问题

CMS.MERGE 会把来源 key 删除吗？

命令用途是把多个 sketch 合并到目标 key，文章中的来源仍作为独立统计保留。是否清理来源应由业务的归档周期决定，不要把合并和删除绑定成一个假设。

为什么合并后的 CMS.QUERY 不是精确总和？

Count-Min Sketch 用有限宽度和多行哈希估算频次，碰撞可能让结果偏大。CMS.MERGE 只合并这些估算结构，不会把它变成精确计数表。

能不能用不同 width 的来源做加权合并？

不能。权重只表示来源贡献的倍乘关系，所有参与合并的 sketch 仍必须使用相同的 width 和 depth。

落地时可以先把每个来源的初始化参数和采样比例写入配置，再由程序生成 source 与 weights 列表。这样出现“命令成功但数值偏大”时，能区分结构兼容问题、权重配置问题和 CMS 固有误差。