本文系统解析Redis五大数据结构的核心差异，通过电商库存扣减、社交关系存储等实战案例，揭示String/Hash/Sorted Set等类型的适用场景。提供数据结构选择的四维评估模型，帮助开发者避免内存浪费和响应延迟，实现系统性能跃升。
Redis五种数据类型用错场景怎么办？
新手常犯的错误是将所有数据塞进String类型。某生鲜电商曾因用String存储商品库存，导致扣减操作出现并发问题。实际上：
- Hash类型更适合存储对象属性（如用户资料）
- Sorted Set天然支持排行榜场景
- HyperLogLog在统计UV时节省98%内存
关键决策点：数据读写模式、原子性需求、内存效率之间的平衡。比如订单状态变更更适合用Hash的hincrby命令实现原子操作。
高并发场景如何选择数据结构？
某社交App在消息推送场景中，用List结构导致读取性能骤降。优化方案：
- 热点数据用ZSet实现时间线排序
- 关系链存储改用Graph模块（需Redis 5.0+）
- 计数器场景用String+incr命令
实测数据显示，将200万用户关系从Set迁移到Graph结构后，共同好友查询耗时从32ms降至6ms。注意评估数据规模，小数据量时Set更节省内存。
内存优化必知的存储技巧
某金融系统用String存储10万条交易记录，内存占用达3.2GB。改造方案：
原结构 优化结构 节省比例 String存储JSON Hash存储字段 41% ZSet存储时序数据 Stream数据结构 58% 使用redis-memory-analyzer工具分析发现，将固定前缀的Key改用Hash存储后，内存碎片减少73%。注意控制Hash的field数量，单个Hash建议不超过1000个字段。
数据结构组合使用的进阶方案
复杂业务场景往往需要多结构配合：
电商库存管理组合拳 1. Hash存储sku基础信息 hmset sku:1001 name "手机" stock 500 2. Bitmap记录秒杀资格 setbit flashsale:2023 1001 1 3. Stream处理订单流水 xadd orders sku 1001 userid 90210这种组合方案在618大促中成功支撑10万QPS的库存查询，相比纯String方案降低32%的Redis节点数量。
数据结构选型四维评估模型
建立系统化的决策框架：
- 数据特征维度：数据长度/更新频率/有效期
- 操作维度：读写比例/是否需要事务
- 性能维度：响应延迟要求/QPS峰值
- 成本维度：内存占用/集群扩展成本
某视频平台运用该模型后，将热门视频缓存结构从String调整为ZSet，使得排行榜更新耗时从120ms降至17ms，同时内存使用量仅增加8%。
常见问题解答
Q：Set和ZSet主要区别是什么？
A：Set存储无序唯一值，ZSet额外维护score排序。社交场景粉丝列表用Set，游戏排行榜必须用ZSet。Q：List结构被官方建议替代了吗？
A：在Redis5.0+版本，Stream结构更适合消息队列场景。但少量数据的FIFO场景仍可用List。Q：如何评估不同结构的内存消耗？
A：使用memory usage命令，或采用redis-rdb-tools分析离线数据。注意不同编码格式的影响，如ziplist和hashtable的转换阈值。
