Redis CMS.MERGE 怎样给计数草图设置合并权重

如果要把多个 Count-Min Sketch 合成一个目标草图，并让不同来源对结果的贡献不同，直接给 CMS.MERGE 加上 WEIGHTS 即可。权重按来源草图的顺序对应，未写权重时每个来源默认按 1 处理；但目标草图和所有来源草图必须使用相同的 width 与 depth。

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

本文只围绕一个任务展开：把 2026 年 9 月和 10 月的两份计数草图合并，其中 10 月数据按 3 倍贡献计算。这个能力适合做分批统计、历史窗口汇总或不同采集批次的加权汇总，不适合拿来修正尺寸不一致的草图。

Redis CMS.MERGE 的命令结构和权重位置

命令骨架是 CMS.MERGE destination numKeys source [source ...] [WEIGHTS weight [weight ...]]。第一项是已经初始化的目标草图，第二项是来源草图数量，后面紧跟对应数量的来源键；WEIGHTS 是可选部分，权重列表按来源出现顺序匹配。

# 目标草图必须先存在，source-a 和 source-b 是两份来源草图
redis-cli CMS.MERGE destination 2 source-a source-b WEIGHTS 1 3

# 命令成功时返回 OK；这里的 3 只表示第二份来源的贡献倍率

这里的权重不是给某个 item 单独加分，而是对整份来源草图的计数贡献做倍乘。因此要先确认来源键的顺序，再让权重列表与它一一对应。

先让来源草图具备相同的 width 和 depth

Redis 官方文档明确要求，参与合并的草图必须具有相同的宽度和深度，目标草图也必须按同样的尺寸初始化。尺寸不一致时，命令会返回错误，而不是自动扩容或重新映射。

# 三个草图使用同一组尺寸，避免 CMS.MERGE 因结构不同拒绝请求
redis-cli CMS.INITBYDIM source-a 2000 7
redis-cli CMS.INITBYDIM source-b 2000 7
redis-cli CMS.INITBYDIM destination 2000 7

# 初始化后再写入样本计数；CMS.INCRBY 的增量是整数
redis-cli CMS.INCRBY source-a api/login 10 order/create 4
redis-cli CMS.INCRBY source-b api/login 6 order/create 9

实际项目中，width 和 depth 应在数据模型设计阶段固定，而不是在合并失败后临时猜一个值。不同批次如果来自不同参数的草图，应该先分开保存或重新按统一参数采集。

用 WEIGHTS 表达来源数据的合并比例

假设 source-a 是较早批次，source-b 是较新的批次，并希望新批次在合并结果中的影响更大，可以写成 WEIGHTS 1 3。这表示第一份来源按 1 倍计算，第二份来源按 3 倍计算；它不是把最终查询值简单乘以 3。

# source-a 对应 1，source-b 对应 3，顺序必须保持一致
redis-cli CMS.MERGE destination 2 source-a source-b WEIGHTS 1 3

# 查询合并后的近似计数，验证读取的是目标草图
redis-cli CMS.QUERY destination api/login order/create

如果省略 WEIGHTS，每个来源的默认权重都是 1；如果传入权重，则应让权重个数与来源数量匹配。为了让配置可读，建议把来源键和权重放在同一份批次元数据中保存，避免日后只改键名却忘记同步倍率。

权重结果如何影响计数解释

CMS.QUERY 返回的是 Count-Min Sketch 的近似计数，不是精确明细表。合并时给 source-b 设置 3 倍权重，意味着它在目标草图各计数位置上的贡献被放大；因此查询结果要解释为“带来源权重的近似计数”，不能与未加权的历史结果直接横向比较。

这项能力与旧的“先查询、再在业务代码里相加”方案相比，优点是合并动作集中在 Redis 端，目标草图作为一个新键保存，后续查询路径更简单；代价是权重语义会进入草图数据本身，若批次权重没有记录，之后很难仅凭目标键还原业务口径。

生产采用前重点留意三件事：第一，目标键必须提前初始化；第二，来源键不能缺失，且尺寸必须一致；第三，权重的含义要和时间窗口、数据覆盖范围或采样策略绑定。官方文档给出的复杂度是按草图数量计算的 O(n)，批次很多时仍要控制单次合并规模。

常见问题

不写 WEIGHTS 时会怎样？ 每个来源默认按 1 倍贡献，命令仍然可以合并。

WEIGHTS 能解决尺寸不一致吗？ 不能。width 或 depth 不同仍会导致合并错误，需要从统一参数重新创建或采集草图。

为什么要查询 destination？ CMS.MERGE 的结果写入目标键，后续应使用 CMS.QUERY destination item 读取合并草图，而不是继续把来源键当作最终结果。

记住一条实用规则：先统一草图尺寸，再按来源顺序写 WEIGHTS，最后把权重口径和目标键一起记录。这样既能完成加权合并，也能让后续查询结果保持可解释。