用Redis的Set集合存数据其实没那么难，分享点简单实用的方法和思路

今天咱们来聊聊怎么用Redis里的Set集合来存数据，你可能听过Redis，也知道它很快，但一说到里面的数据结构，比如Set，可能就觉得有点复杂，不知道从哪儿下手，别担心，其实用Set来处理一些问题，特别顺手，而且想法很简单，我就分享几个平时用得上的方法和思路,保证不扯那些难懂的专业词儿。

得搞清楚Redis的Set是个啥，你可以把它想象成一个大大的、自动去重的袋子，你往里面扔东西，不管扔多少次相同的，袋子里最终只留一个，它不讲究顺序，就是单纯的一堆不重复的元素集合，这个特性，正好可以用来解决很多需要“唯一性”的场景。

第一个超实用的场景：给用户打标签。

比如你运营一个内容平台，用户可以有多个标签，科技爱好者”、“电影迷”、“吃货”，一个用户肯定不能有重复的标签吧？用Set就太合适了，你可以为每个用户创建一个Set，名字就叫 user:123:tags（123是用户ID），当用户添加标签时，你就用 SADD 命令往里加：

SADD user:123:tags "科技爱好者" "电影迷"

你看，即使用户手滑，多次添加“科技爱好者”，Set里也只会有一个，你想知道用户有哪些标签？用 SMEMBERS user:123:tags 一下就全取出来了，你想判断用户是不是“吃货”？用 SISMEMBER user:123:tags "吃货"，Redis立马告诉你“是”或“否”，哪天用户想删掉“电影迷”这个标签，一个 SREM user:123:tags "电影迷" 就搞定了，是不是特别直观、方便？

第二个场景：搞抽奖或者秒杀时，防止用户重复参与。

这个需求太常见了，比如一个抽奖活动，每个用户只能参与一次，你可以在活动开始时，创建一个Set，叫 activity:double11:participants，每当有一个用户点击参与，在处理业务逻辑之前，先执行 SADD activity:double11:participants user_id，这个命令有个好处是，它会返回一个值告诉你，这个元素是刚刚新加进去的（返回1），还是本来就已经存在了（返回0）。

这样，你的程序就可以根据这个返回值来判断：如果返回1，说明用户是第一次参与，OK，让他继续完成抽奖流程，如果返回0，说明他已经参与过了，直接提示“您已经参与过啦！”，这种方法比你去查数据库快得多，而且能顶住高并发的请求，因为Redis速度非常快,思路来源其实就是利用Set的自动去重和快速判断成员存在的特性。

第三个场景：找共同点，也就是求集合之间的交集、并集什么的。

这个听起来高级，但例子一看就懂，有两个用户，小明和小红，小明关注了标签A、B、C，小红关注了标签B、C、D，他们的Set分别是 user:xm:tags 和 user:xh:tags。

现在你想知道他俩的共同兴趣是什么？也就是找他俩都喜欢的标签，Redis直接给你一个命令搞定：SINTER user:xm:tags user:xh:tags，命令一执行，结果就是 B 和 C,这比你自己写程序去两个列表里比对高效多了。

再比如，你想看看所有被用户关注过的、不重复的标签有哪些（即小明和小红所有标签的合集），那就用 SUNION user:xm:tags user:xh:tags，得到 A, B, C, D。

甚至你还可以玩点花的，比如想知道小明有而小红没有的标签（差集），命令是 SDIFF user:xm:tags user:xh:tags，结果就是 A，这些操作在做推荐系统或者社交关系的“共同关注”等功能时，非常有用，这个思路的来源是数学上的集合运算,Redis帮我们轻松实现了。

聊聊怎么选Set和其他的数据结构。

有时候你可能纠结，用Set还是用List（列表）或者Hash（哈希）？记住一个简单的原则：当你特别关心数据的唯一性，或者需要做上面说的那种找共同点（交集并集）的操作时，优先考虑Set。 如果你需要保持数据的插入顺序，那应该用List，如果你存储的是一个对象的多个字段（比如用户的姓名、年龄、邮箱）,那用Hash更合适。

用Redis的Set，核心就是抓住它“自动去重”和“高效集合运算”这两个法宝，从给物品打标签、防止重复提交，到发现共同好友、共同兴趣，Set都能用非常简单的命令帮你优雅地解决，一开始不用想得太复杂，就从上面这些小的、实用的场景开始尝试，慢慢你就会发现，这个“袋子”真好用,希望这点简单的分享能给你带来一些启发。