《redis入门指南》进阶场景之用户的好友列表拉取、auto-complete实现

2019年6月9日 254次阅读 来源: selbstkennen梁晨

上文中介绍了如何使用redis实现用户的注册，以及登陆的在线状态保持。而使用redis另外常见的应用，还有好友列表的维护与拉取，以及搜索中的auto-complete的实现。需要注意的时候，redis并非这些需求的唯一实现，只是在很多情况下，是性能最为突出的实现方式。接下来，我们就看看在这两种场景中，redis如何使用强大的数据接口和易用的api，发挥作用。

用户好友列表拉取

使用redis一个非常典型的场景就是对好友列表的维护。现在社交类的产品越来越多，以QQ为鼻祖，微博为发展的又一高潮，其中对于好友列表的维护始终是一个很大的技术点。对于QQ来说，本地的维护加上与server的定时更新，即可完成任务。但是对于微博这类单纯的没有客户端的web应用而言，在服务端对于关系链的高效存储，就显得十分有挑战了。

《《redis入门指南》进阶场景之用户的好友列表拉取、auto-complete实现》 社交网络视图

我们首先来看看这个方案要解决哪些问题：

  1. 要解决对用户好友列表的维护，每个人都想看到自己有哪些自己关注的人，以及关注自己的人；
  2. 要解决给出两个用户，验证关注关系的问题
  3. 要解决能够方便的建立和去除好友关系的问题

对于每个用户而言，他必须维护至少两个集合，第一个集合就是followerSet，第二个集合就是followingSet。分别存储他关注的和他被关注的好友的userid。这两个集合自己的key都是由这个用户自己的userid规则拼装而成。

有了这两个集合之后，对于其关注者和被关注的列表拉取的问题，就可以直接通过：
SMEMBERS selfuserid-followerSet和SMEMBERS selfuserid-followingSet来解决。当拉取列表的时候，一个很现实的问题是对拉取的用户进行排序。根据新浪微博现有的做法，也只是支持实时的按照关注时间来排序，如果需要其他时间来排序的话，结果会有几个小时的延时。也就是为了支持这个新的排序特性，他们使用了异步的脚本，来专门产生了其他排序类型的集合。考虑到用户使用其他排序类型的场景比较小，这也是能够接受的一种做法。

同时在拉取的时候也需要支持到分页，这时候就可以使用之前的SORT命令，SORT selfuserid-followerSet BY selfuserid:*->followtime DESC LIMIT 0 10，我们使用一个散列selfuserid:userid来保存用户和关注用户之间的关注时间、是否密友等信息，而在排序的时候，也能够利用这个时间来实现排序。而像刚刚说的其他排序字段，也可以通过定时脚本的方式，写入到这个哈希中，从而完成排序的功能。这里一个潜在的问题是SORT命令的性能，一般而言，这个命令的性能是log(N+MlogM)，N是总数，M是要取出的数量。如果实在是N和M太大导致了性能的瓶颈，那么可以考虑使用store对结果进行短暂的存储来保证性能。

完成了对好友列表的拉取之后，接下来我们要着眼的就是用户的好友关系的变更。以用户关注为例，当A用户关注了B用户之后，需要进行如下的几个操作：

  • 将A用户加入到B用户的followerSet中
  • 将A用户加入到B用户的follower哈希表中，注明被关注时间等信息用以排序
  • 将B用户加入到A用户的followingSet中
  • 将B用户加入到A用户的following哈希表中，注明关注时间等信息用以排序

为了保证数据的一致性，可以使用redis的事务，将四种操作合在一起：

redis->multi
->sadd(B:followerSet A)
->sadd(A:followingSet B)
->hset(B:A,followertime,time)
->hset(A:B,followingtime,time)
->exec()

通过这样的结构设计，我们就能够满足基本的好友关系的存储和各类拉取、添加、删除的需求，同时也能够在一定程度上提升访问的性能。

实现auto-complete

另一种很常见的web站点的需求，是对用户搜索的内容进行auto-complete。 传统的使用数据的方案，往往依赖了数据库的like能力，效率十分的低下。而利用redis的数据结构，我们能够很高效的存储并且索引到需要自动完成的内容。

《《redis入门指南》进阶场景之用户的好友列表拉取、auto-complete实现》 自动完成实例

假定我们需要搜索的内容是网站所有的用户名，那么首先我们需要处理每个用户名的组成前缀。比如说用户名teddy，那么就需要分别的存储t、te和ted和tedd。这里只需要O(N)的遍历，即可拿到所有的前缀。

创建一个有序集合auto-complete-set，首先将每个标签名的所有前缀作为元素，同时将它们的分数作为0.

ZADD auto-complete-set t 0
ZADD auto-complete-set te 0
ZADD auto-complete-set ted 0 
ZADD auto-complete-set tedd 0

同时为了区分用户名本身，也在后面增加*之后将其存储有序集合:
ZADD auto-complete-set teddy* 0

由于所有的集合中的元素分数都是相同的，所以该有序集合键中的元素就相当于全部按照字典书序排序了。使用有序集合，在利用其排序特性的同时，也能保证元素的唯一性。当用户输入t的那时候，就会按照如下的流程获取要提示出来的用户：

  • 获取t的排名 ZRANK auto-complete-set t，在这里返回的是0
  • 获取t之后的N个元素，当N=100的时候，就是ZRANGE auto-complete-set 1 101，这里N的大小跟要auto-complete的元素的平均长度和需要返回的auto-complete结果直接相关，可以根据自己实际的业务情况灵活的调整。
  • 遍历返回的结果，找出其中以*结尾，而且以t开头的元素，此时将*去掉就是我们需要的结果了。

结语

曾经复杂的算法实现，在redis强大的数据结构面前变成了风轻云淡。不论是对好友列表的维护，还是对auto-compete功能的实现，都显示出了redis的轻盈和强劲。所以在redis特性了解的同时，无时无刻不要了解redis对应数据结构的应用场景，只有这样才能做到用时游刃有余。

    原文作者：selbstkennen梁晨
    原文地址: https://www.jianshu.com/p/a952436e38db
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞