用Redis来管理数据集缓存，集合数据存取其实也没那么复杂

（引用来源：Redis官方文档对数据类型的概述） Redis之所以好用，很大程度上是因为它提供的数据类型非常贴近我们实际开发中的需求，它不像传统的关系型数据库，需要你先设计复杂的表结构，Redis的数据类型直接、简单,比如这个用来存储集合的Set类型。

（引用来源：实际开发中常见的集合应用场景） 想象一下，你正在开发一个社交应用，一个很基本的功能就是用户的关注列表和粉丝列表，用Redis的Set来存这些东西就特别合适，每个用户都有一个唯一的ID，比如用户12345的关注集合，在Redis里就可以直接用一个键来表示，user:12345:following，当用户关注了另一个人，比如用户67890，你只需要执行一条简单的命令 SADD user:12345:following 67890，就把67890这个成员添加到了12345的关注集合里，同样，取消关注就是 SREM user:12345:following 67890，你想查看这个用户的所有关注列表？一条 SMEMBERS user:12345:following 命令，Redis就把所有他关注的人的ID都返回给你了，这个过程非常直观，就是对一个集合进行加减和查看的操作,和我们脑子里的想法是完全一致的。

（引用来源：Redis集合的天然去重特性） Set有一个天生的优点，就是自动去重，你往同一个集合里多次添加同一个成员，最终这个集合里也只会有一个存在，这个特性可以用来做很多事，统计一个热门话题下所有参与讨论的独立用户数，每当有一个用户发表了一条关于该话题的帖子，就把他的用户ID塞进这个话题对应的Set里，因为你可能只关心有多少个不同的人参与了，而不是他参与了多少次，只需要用 SCARD topic:hot:users 命令，就能立刻得到独立用户数，如果你用数据库去重统计，可能还得写个 SELECT DISTINCT 的SQL语句，数据量一大，查询速度就慢下来了，Redis直接在内存里计算,速度极快。

（引用来源：集合间的交并差操作） 更厉害的是，Redis的Set还支持多个集合之间的运算，求两个集合的交集、并集或差集，回到社交应用的例子，你想知道用户A和用户B的共同关注有哪些，该怎么做？你不需要把A的关注列表和B的关注列表都取到程序里，再用循环去比对，直接使用 SINTER user:A:following user:B:following 命令，Redis瞬间就能帮你算出两个集合的交集，并把共同关注的人的ID返回，这个操作是在Redis服务端完成的，非常高效，同样，你可以用 SUNION 求并集（比如合并两个人的兴趣标签），用 SDIFF 求差集（比如找出A关注了但B没关注的人），这些操作如果交给应用程序自己处理，当集合数据量很大时，网络传输和计算压力都会很大,而Redis帮你优雅地解决了。

（引用来源：随机读取和弹出操作） Set还有一些很方便的小功能，你有时候并不需要获取整个集合，只是想随机从里面挑一个或者几个成员出来看看，有个命令叫 SRANDMEMBER，它可以让你从指定集合中随机返回一个或多个成员，而且不会破坏原来的集合，这很适合做一些抽奖或者随机推荐的功能，还有一个命令叫 SPOP，它是随机地从集合中取出一个成员并移除它，这就像是从一个牌堆里抽走最上面那张牌,可以用来实现任务队列或者轮询机制。

（引用来源：使用集合进行存在性判断） 还有一个非常高频的使用场景，就是判断某个成员是否存在于集合中，命令是 SISMEMBER，你要检查一个用户是否已经给某篇文章点过赞，以防止他重复点赞，你可以把点赞用户的ID存在一个Set里，当用户点击点赞按钮时，先 SISMEMBER article:1001:likes 12345 查一下，如果返回1，说明已经点过了，就提示他不能重复点赞；如果返回0，说明没点过，就执行点赞逻辑并把他的ID添加进去，这个检查操作的速度是常数时间的，非常快,几乎感觉不到延迟。

（引用来源：对集合操作的总结） 所以你看，用Redis来管理集合数据，真的没有想象中那么复杂，它就是把我们平时在代码里经常要用到的那些关于集合的操作，比如添加、删除、判断是否存在、求交集并集等等，变成了一条条简单的命令，你不需要考虑底层是怎么实现的，只需要知道你想对哪个集合（用Key来指定）做什么操作（用命令来指定）就行了，这种直接、高效的方式，让开发人员可以把精力更多地放在业务逻辑上，而不是数据存储和处理的细节上，在使用过程中也要注意，因为Redis的数据都在内存里，所以太大的集合会消耗很多内存，要根据实际情况来决定是否适合用Redis的Set来存储，对于中小规模且需要快速读写的集合数据,Redis的Set是一个非常得力的工具。