Redis Hash 怎么给多个业务计数分别累加

做运营看板时，订单数、退款数、登录数往往属于同一组业务指标。Redis 不必为每个指标单独拼一个 key，可以用一个 Hash 保存多个 field，再用 HINCRBY 分别累加。比如 metrics:shop:20260906 是当天指标，orders、refunds、logins 是不同计数项。

先把多个指标放进同一个 Hash

Hash 的第一层是 key，第二层是 field。key 可以按租户、门店和日期划分，field 则固定为业务指标名。这样读取一组指标时只需要定位一个 key，也能避免把“订单”“退款”写到不同命名规则里。

用 HINCRBY 分别累加业务计数

HINCRBY 的语法是 HINCRBY key field increment。如果 key 不存在，Redis 会创建 Hash；如果 field 不存在，会先按 0 再执行加法。因此第一次上报订单数不需要额外的“先查再写”逻辑。

# 为同一天的三个业务指标分别累加，field 名称保持稳定
redis-cli HINCRBY metrics:shop:20260906 orders 1
redis-cli HINCRBY metrics:shop:20260906 refunds 2
redis-cli HINCRBY metrics:shop:20260906 logins 1

# 扣减时传入负数，例如撤销一笔已计入的订单
redis-cli HINCRBY metrics:shop:20260906 orders -1

每条命令返回对应 field 的新值，而不是本次增量。假设订单原值为 12，执行加 1 后返回 13；这可以直接作为接口响应中的最新计数。HINCRBY 的时间复杂度为 O(1)，但一次请求里有多个独立 field 时，是否需要批量封装要由客户端和业务一致性要求决定。

读取结果时区分单个值和整组指标

写入后只关心某个指标，可以用 HGET；需要构建看板或导出整组数据，则用 HGETALL。不要把一次 HINCRBY 的返回值误认为整个 Hash 的总和，它只代表当前 field 的新值。

# 读取单个业务计数
redis-cli HGET metrics:shop:20260906 orders

# 读取该 key 下的所有 field/value 对
redis-cli HGETALL metrics:shop:20260906

应用侧建议把允许的 field 做成常量或枚举，并让接口只接受白名单值。这样可以避免客户端把 order、orders、order_count 当成三个指标，导致看板出现“计数变少”的假象。

非整数值和溢出是最常见的两个坑

HINCRBY 不是字符串拼接命令。如果 field 当前保存的是 "unknown"、带小数的文本或超出范围的数字，命令会返回错误，应用必须记录失败并决定是否告警，不能把失败当成成功计数。写入初始化数据时，先约束字段只接受整数。

Redis 官方文档说明 HINCRBY 支持 64 位有符号整数。高频累计场景要关注接近上限的指标，并在业务层决定是否按日期、租户或分片拆分 key。需要小数时不要强行使用 HINCRBY，应评估 HINCRBYFLOAT 或改用整数最小单位。

相关问题

field 不存在时需要先 HSET 吗？

不需要。HINCRBY 会把不存在的 field 按 0 参与计算；只有需要非零初始值或初始化一整组字段时，才单独使用 HSET。

一个 Hash 能不能同时保存订单数和金额？

可以保存，但金额要统一为最小货币单位的整数，例如分；不要把带小数的金额字符串交给 HINCRBY。

HINCRBY 返回的是增加量吗？

不是。返回值是当前 field 完成本次加法后的新整数，增加量由请求中的 increment 参数决定。

参考：Redis HINCRBY 官方命令文档。