我会先交代项目背景和选型结论。从底层编码、复杂度和典型业务理解 String、Hash、List、Set、ZSet 与高级结构。Redis 不只是 Key-Value 缓存，它提供 String、Hash、List、Set、Sorted Set、Bitmap、HyperLogLog、Geo、Stream 等结构。选型要同时考虑访问模式、时间复杂度、元素数量、单元素大小、持久化成本和集群分片限制。

具体落地时，我会沿着实际调用链来讲。 src/thash.c/tzset.c：Hash/ZSet 编码与命令。 OBJECT ENCODING/MEMORY USAGE：实际编码与字节。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

参数和容量不能靠默认值，我会结合业务量来定。对相同业务数据使用 Hash、JSON String、ZSet，比较字节、命令时延与超过编码阈值后的突变。

效果要用数据证明，线上问题也要能闭环。固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「Value P99」为主基线，记录值应满足「<业务上限」；同时保存 每类 Key 数量、Value 大小分位值，使后续变化能够回到同一时间轴比较。 ZSet 保存所有历史用户且从不淘汰，成员数增长到数千万，备份与故障恢复都变慢。按赛季分 Key、只保留活跃窗口并把历史落到持久存储后，实时榜才保持可控。 用 KEYS 扫描生产全库：每类 Key 数量：按访问模式换结构。 集合无上限演变为大 Key：Value 大小分位值：Key 加版本与 TTL。

最后我会主动说明这个方案不适合什么场景。数据结构选择要同时满足操作语义和生命周期；能用 Redis 表达不代表应把无界历史或复杂分析长期放在 Redis。