Redis Hash 字段体积怎么巡检：HSCAN NOVALUES 与超长字段告警

Redis 的 Hash 一旦被当成“属性袋”长期追加，内存上涨往往不是整个 key 一起变大，而是少数字段的 value 悄悄膨胀：某个用户画像塞进了完整JSON，某个订单备注被重复拼接，最终让读写延迟和 RDB 体积一起变难看。巡检时不必先把整份 Hash 搬到应用进程，先用 HSCAN 的 NOVALUES 只找字段名，再对候选字段按需回读长度，更容易控制成本。

先把“Hash 变大”拆成可验证的问题

假设业务 key 是 profile:10086，里面有 nickname、labels、preferences 等字段。MEMORY USAGE profile:10086 只能告诉你整个 key 占了多少内存，却不能直接指出哪个字段最可疑。巡检目标可以拆成三件事：

• 字段数量是否超过设计范围；
• 是否存在明显超长的字段名或 value；
• 异常字段是否集中在某个业务写入路径。

这里不建议先用 HGETALL 把所有值读回应用。大 Hash 的问题恰恰是“值可能很大”，把诊断动作设计成全量读取，会把内存风险扩大成网络和进程内存风险。

第一步：用 HSCAN NOVALUES 只定位字段

redis-cli HSCAN profile:10086 0 NOVALUES COUNT 100

Redis 官方命令文档将 HSCAN 定义为对 Hash 字段和值进行增量迭代；使用 NOVALUES 后，返回结果只保留字段名。这里的 COUNT 是工作量提示，不是严格的每页数量，脚本不能把一次响应当成完整结果。

一个只收集字段名的 Python 片段如下。变量名使用业务含义，避免把巡检程序写成一次性全量搬运工具：

from redis import Redis

client = Redis.from_url("redis://127.0.0.1:6379/0", decode_responses=True)

def field_names(key: str, page_hint: int = 100):
    cursor = 0
    while True:
        cursor, fields = client.hscan(key, cursor=cursor,
                                      count=page_hint, novalues=True)
        for field in fields:
            yield field
        if cursor == 0:
            break

for field in field_names("profile:10086"):
    print(field)

检查点只有一个：循环必须持续到游标回到 0。如果巡检只看第一批字段，得到的只是一个局部样本，不能据此宣布“没有异常字段”。

第二步：只回读候选字段的 value 长度

拿到字段名后，再按规则挑选需要回读的字段。例如画像 Hash 只关心 preferences、labels 和 remark，就不必对每个字段都做字符串长度计算：

WATCH_FIELDS = {"preferences", "labels", "remark"}
MAX_VALUE_BYTES = 16 * 1024

def inspect_hash(key: str):
    findings = []
    for field in field_names(key):
        if field not in WATCH_FIELDS:
            continue
        value = client.hget(key, field)
        if value is None:
            continue
        size = len(value.encode("utf-8"))
        if size > MAX_VALUE_BYTES:
            findings.append({"field": field, "bytes": size})
    return findings

阈值不是 Redis 的通用答案，而是业务契约。JSON 画像、短标签和自由文本的合理大小不同，最好在写入端同时保留字段级限制，并把巡检告警当作写入约束失效的证据。

让告警能回到写入路径

告警内容至少要包含 Hash key、字段名、value 字节数、阈值和巡检时间。只报“Redis 内存过高”很难定位；报出 profile:10086.preferences=48320B，开发者才有机会回看是哪一次画像合并把内容放大。

def format_alert(key: str, finding: dict) -> str:
    return (f"redis_hash_field_oversize key={key} "
            f"field={finding['field']} bytes={finding['bytes']} "
            f"limit={MAX_VALUE_BYTES}")

如果 Hash 字段数量本身也在异常增长，可用 HLEN 做一个便宜的总量核对：

field_total = client.hlen("profile:10086")
print({"key": "profile:10086", "field_total": field_total})

字段总数和字段体积要分开看：前者适合发现模型失控或字段名动态化，后者适合发现单个 value 膨胀。两者混成一个“Hash 太大”指标，后续动作容易走偏。

巡检频率与边界怎么定

• 在线高峰只检查预先登记的业务 key，并限制每轮 key 数量。
• 低峰再扩大范围，仍然让 HSCAN 分批推进，记录开始游标和结束游标。
• 字段回读优先走白名单；确需扩大范围时，先做采样并观察 Redis 网络流量。
• 发现超长字段先保留证据，再处理写入逻辑，不要直接截断线上数据。

HSCAN 本身是增量操作，但“增量”不等于“没有成本”。巡检脚本的并发度、回读字段数和运行时段，都应纳入 Redis 的容量评估。

常见问题

HSCAN NOVALUES 会不会检查到完整 Hash？

会，只要脚本持续使用返回的游标，直到游标回到 0。NOVALUES 只改变返回内容，不改变需要完成一轮迭代的事实。

为什么 COUNT 设成 100，返回字段却不是 100 个？

COUNT 是提示值，实际返回数量受 Hash 的内部编码和当前工作量影响，不能当成分页大小或总量估计。

为什么不用 HGETALL 直接统计所有 value？

HGETALL 会把所有字段和值一次性返回。对大 Hash 或异常膨胀的 value，这会放大网络传输和应用内存压力；先定位、再回读更稳妥。

超长字段应该立刻删除吗？

不应该。先确认字段来源、业务可恢复性和最近写入记录，再通过修复写入、迁移数据或经过审批的清理流程处理。

把一次巡检变成持续的容量信号

HSCAN NOVALUES 适合做第一层筛查，HGET 和 HLEN 负责补充证据，告警记录则把 Redis 的现象带回业务写入路径。这个组合的价值不在于找出某一个“神奇命令”，而在于让字段数量、字段体积和异常来源分别可见，后续容量治理才有抓手。