用Redis搞定摇一摇功能，边玩边学redis怎么实现的那些事儿

那天我跟朋友闲聊，说起以前微信摇一摇刚出来的时候，觉得特别神奇，隔那么远的人怎么能一下子摇到一起，朋友突然问我：“哎，你不是搞技术的吗，这东西要是让你用Redis做，该怎么做？” 这一下把我问乐了，我说：“嘿，你还真问对人了，这玩意儿用Redis来做，那简直是杀鸡用牛刀——大材小用，但特别合适！”

为啥说合适呢？你想啊，摇一摇的核心是啥？就是一瞬间，成千上万的人同时拿起手机“咔嚓”一摇，服务器要在极短的时间里，把同一时刻摇手机的人快速配对起来，这个过程要求速度极快，而且数据可能下一秒就过期没用了，这不正好撞到Redis的枪口上了嘛！Redis这东西，数据都放在内存里，读写速度飞快，而且自带好多种能设置过期时间的数据结构，天生就是干这种“快闪”业务的料。

那具体怎么搞呢？咱们一步步边玩边想。

第一步：每个人摇一摇，得先有个“签到”的地方。

想象一下，Redis里咱们开辟一个地方，就像一个大礼堂，每个用户摇一摇的这个动作，就相当于他在这个礼堂里喊了一声“我到啦！”，在Redis里，我们用一种叫Set（集合） 的数据结构来当这个礼堂最合适不过了，Set的最大特点就是里面的元素都是唯一的，同一个用户短时间内重复摇,我们也只算一次。

关键点来了，我们怎么标记“同一时刻”呢？总不能把一天24小时都算作同一时刻吧，这里有个小技巧，我们可以用时间戳，但直接用精确到毫秒的时间戳太细了，配对成功率低，通常的做法是，以“秒”为单位，比如我们把每2秒或3秒划分为一个时间窗口，用户摇一摇时，服务器取当前时间，然后算出他属于哪个时间窗口（timestamp // 3，取整），这个时间窗口就是我们的“礼堂编号”。

用户摇一摇时，我们执行一个简单的Redis命令：SADD shake:hall:时间窗口编号 用户ID，这个命令的意思就是，向名为“shake:hall:时间窗口编号”的这个集合里，添加这个用户的ID。SADD命令很智能，如果用户ID已经存在，它就不会重复添加,这正好避免了用户连续狂摇的作弊行为。

第二步：礼堂人齐了，开始“配对”。

同一个时间窗口里，所有摇一摇的用户ID都躺在那个Set里了，下一步就是给他们配对，这个配对的过程，可以放在后台一个单独的任务（比如一个微服务）里异步执行，这样就不会阻塞用户摇一摇的瞬间操作,体验更流畅。

这个配对任务干啥呢？它每隔一两秒（根据你设置的时间窗口来定）就跑一次，去找上一个时间窗口的Set，当前是第10号时间窗口，配对任务就去处理第9号时间窗口的Set，为啥是上一个？因为要确保这个窗口已经关闭了，不会再有人加进来，我们处理的是已经“定格”的那一批人。

任务找到这个Set后，执行一个命令：SMEMBERS shake:hall:9，把里面所有的用户ID都取出来,你得到了一个在时间窗口9里所有摇一摇的用户列表。

第三步：怎么配对？这里有学问。

最简单的配对就是“随机配对”，从列表里随机抽两个人，把他们配成一对，在Redis里，有一个超级好用的命令叫 SPOP。SPOP key [count] 的作用是从一个Set中随机移除并返回一个或多个元素，这太完美了！我们可以不断地执行 SPOP shake:hall:9 2，每次弹出两个用户ID，直到集合里的用户数少于2个为止，弹出的每一对ID，我们就认为他们配对成功了，我们可以把配对结果（比如一个配对成功的ID对）存到另一个地方（比如另一个Redis键或者数据库里），并给这两个用户发推送消息：“恭喜你，摇到了一个朋友！”

那如果最后集合里剩下一个落单的人怎么办？也好办，把他放回池子里，比如把他再加入到当前的时间窗口Set中，让他和下一批人继续配对,这样就不会有人被遗忘。

第四步：别忘了“打扫卫生”。

Redis内存很宝贵，我们不能让这些一次性的数据一直占着地方，配对任务在处理完一个时间窗口的Set后，应该把这个Set删除掉（用DEL命令），或者更优雅一点，我们在创建这个Set的时候，就给它设置一个过期时间（TTL），比如60秒，让Redis自动回收，这样即使配对任务出问题了,数据也不会永久堆积。

你看，就这么几步，一个高并发、实时的摇一摇核心功能就搞定了，整个过程几乎全在内存里完成，速度飞快，我们用了Redis的Set数据结构来做快速的人群归集，用了SPOP命令来实现高效的随机配对,还用了过期时间来自动清理数据。

这只是一个最核心的模型，真实的产品里可能还要加上很多别的东西，比如地理位置过滤（只配对附近的人）、防作弊逻辑、配对历史记录等等，但万变不离其宗，这个用Redis集合和时间窗口的基本思路，就像房子的地基一样，又稳又扎实，朋友听完直说：“原来这么复杂的功能，背后的原理可以这么清晰！” 所以说，边玩边学，Redis的那些事儿还真挺有意思的。 参考和融合了普遍的技术社区讨论，如CSDN、博客园、开源中国等平台上关于实时匹配、秒杀、抽奖等场景下Redis应用的常见思路，并非特指某一篇文章。）