Redis集合查询那些事儿，挖掘隐藏的潜力和技巧分享

今天咱们来聊聊Redis里的集合，这个看似简单却藏着不少好东西的数据结构，很多人可能就觉得，集合嘛，不就是存一堆不重复的元素，能做个交集、并集什么的，但其实用好了，它能在很多场景下帮你省大力气，甚至做出一些很巧妙的设计，咱们就抛开那些复杂的术语,用大白话讲讲它那些实用的潜力和技巧。

得搞清楚Redis的集合是个啥，你可以把它想象成一个麻袋，你往里面扔东西，但同一个东西你扔多少次，麻袋里也只会有一份，它最基础的操作就是添加元素、删除元素、判断某个元素在不在，这个“判断在不在”的操作非常快，不管你的集合有多大，它几乎都能在常数时间内给你结果,这个特性是很多强大功能的基础。

去重计数器。 比如你运营一个论坛，想知道一篇文章到底有多少个独立的IP地址访问过，你不可能让同一个IP反复刷新就无限增加阅读数吧？这时候集合就派上用场了，每个IP来了，你就用SADD命令把它塞进以文章ID为键的集合里，塞进去成功就是新IP，失败就是重复IP，最后你用SCARD命令看一下这个集合的大小，独立的访问数就出来了，精准无比,这比你自己写逻辑去判断要简单和可靠多了。

标签系统。 这是集合最经典的应用之一，比如给用户打标签，或者给文章打标签，你可以为每个标签建立一个集合，里面存放所有拥有这个标签的用户ID，比如说，有一个“篮球爱好者”的标签，它的集合里就装着所有喜欢篮球的用户ID，反过来，你也可以为每个用户建立一个集合，存放他所有的标签，这样做有什么好处呢？查询会变得异常灵活，你想知道同时喜欢“篮球”和“编程”的人有哪些？直接用SINTER命令，对“篮球”集合和“编程”集合求个交集，结果立马就出来了，你想给某个用户推荐可能感兴趣的标签？看看和他标签相似的其他用户还喜欢什么标签，用SDIFF（差集）或者SUNION（并集）就能算出来，这种多维度查询的能力，用传统的关系型数据库实现起来可能要写复杂的SQL语句,但用Redis集合就是一行命令的事。

随机抽奖。 公司年会搞抽奖，怎么保证公平随机且不重复中奖？把全体员工的工号都放进一个集合里，抽三等奖时，用SRANDMEMBER key [count]命令，随机弹出指定数量的工号，注意，这里用SRANDMEMBER，它只是随机取，不删除元素，适合“抽出来展示一下再放回去”的场景，但如果是抽一等奖，每人只能中一次，那就用SPOP key [count]命令，这个命令是随机弹出并移除元素，完美保证不会有人中两次，这种方式既简单又公平,代码写起来也非常清爽。

好友关系与社交网络。 模仿一下微博或者Twitter的关注模型，每个用户都有两个重要的集合：一个是“我关注的人”（following），另一个是“关注我的人”（followers），当用户A关注用户B时，就用SADD命令把B的ID加到A的“following”集合里，同时把A的ID加到B的“followers”集合里，取消关注就用SREM移除，如何快速找出A和B的共同关注呢？就是求A的“following”和B的“following”的交集，你想推荐可能认识的人？可以计算“我关注的人”所关注的人，和我未关注的人之间的差集或者并集，这些操作都是用SINTER、SDIFF、SUNION这些命令轻松搞定,性能极高。

潜力挖掘：限制集合大小应对内存问题。 集合虽好，但如果无限制地往里面加元素，比如一个热门帖子的独立IP集合可能有几百万个，这就会占用很大内存，Redis虽然快，但内存是宝贵的，怎么办呢？这时候可以考虑使用一种叫做“HyperLogLog”的数据结构（来源：Redis官方文档），它不是集合，但它专门用来做唯一性计数，特点是极其节省空间，每个HyperLogLog只需要最多12KB内存，就能统计接近2^64个不重复元素，代价是它有个小于1%的误差率，并且你无法获取具体的元素内容，如果你的场景是“只需要知道大概有多少个独立访客，而不需要知道具体是哪些IP”，比如统计网站的UV（独立访客），那么用HyperLogLog代替集合会节省海量内存,这就体现了在合适场景下选择合适数据结构的重要性。

最后提醒一个需要注意的地方，集合的交集（SINTER）和并集（SUNION）操作，如果参与运算的集合非常大，可能会导致Redis服务器卡顿一段时间，因为它是单线程的，所以对于大集合的运算，要谨慎考虑,最好在从库上执行或者对集合大小有一个预估。

Redis的集合远不止存几个数那么简单，把它理解成一个高速的、能进行数学集合运算的“唯一值容器”，然后结合你的业务场景去琢磨，比如投票系统、共同喜好、随机选择、黑白名单等等，往往能发现很多意想不到的巧妙用法,极大地提升程序的效率和设计的简洁性。