《Redis 五种数据结构：什么场景选哪一个》

前言

上一篇讲了缓存穿透、击穿与雪崩的区别和解法，那篇是从“出问题了怎么办”出发的。这篇换个角度，从“存数据时怎么选”出发：Redis 的五种基本数据结构，场景不同，选错了要么难用，要么慢。

一、String：最简单的键值对

一个 key 对应一个值，存字符串、数字、简单 JSON 都行。计数器、验证码、缓存单个对象是最常见的用法。需要对数字加减时直接用自增命令，不用先读出来再写回去。

二、Hash：一个对象拆成多个字段

一个 key 下面挂多个字段，适合存“一个对象”的场景，比如用户信息、商品详情。只改其中一个字段时不用把整个对象读出来重写，省流量也省事。字段太多时留意单个 key 别无限膨胀。

三、List：有序队列

按插入顺序排列，适合消息队列、最新动态、任务列表。两端都能进出：左边进右边出就是队列，同一端进出就是栈。取最新 N 条时很方便，但按下标随机查中间元素不是它的强项。

四、Set：不重复的集合

元素不重复、无序，适合做去重、共同好友、标签集合。交集、并集、差集这几个集合运算是它独有的本事：算共同关注、共同标签时直接用集合运算，比在应用层循环比对省事得多。

五、Sorted Set：带分数的有序集合

每个元素带一个分数，按分数排序，适合排行榜、按时间排序的动态流、延迟任务。按分数区间取前 N 名、查某个元素的排名，都是它的主场。分数可以是时间戳，也可以是热度分，设计时先定好分数的含义。

六、一张对照表

七、选型时先问的三个问题

1. 数据有没有重复？ 要去重就往 Set 想。
2. 顺序重不重要？ 要按时间或分数排，就往 List 或 Sorted Set 想。
3. 是不是一个整体对象？ 一个对象多个字段，Hash 比拆成多个 String 干净。

先回答这三个问题，再选结构，比先选结构再硬套场景少走弯路。

结语

五种结构没有哪一个是万能的：String 胜在简单，Hash 胜在字段管理，List 胜在顺序，Set 胜在去重和集合运算，Sorted Set 胜在排序。选型先看场景，再看结构，这和上一篇“先分清现象再选解法”是一个道理。

备注：本文整理自公开资料与作者在华为云开发者论坛的相关回答背景；未涉及任何生产环境实测数据，不作实测结论表述。