大量粉丝列表数据存储在Redis (使用的是hashmap的数据结构),岂不是造成粉丝列表不完整?
各位大牛,听听你的设计。请问这要怎么存储?
为了实现数据的完整性,可以在已有的 key value 结构上引入中间数据结构,以粉丝列表数据结构为例,大致如下:
struct RelationNode {
fansAmount 粉丝数量
fansListKey 通过该 key 从 reids 中获取粉丝列表
fansListExtKey 超出最大显示数量时利用此 key 去 reids 中仍可获取粉丝列表
// 关注、双向关注等其它关列类似处理,此处省略下面的结构定义
}
fansListKey 的生成规则可以是 uid + Fans 如:12345Fans
fansListExtKey 生成规则可以是 uid + ExtFans 如 12345ExtFans
从 reids 中读取粉丝数据
1:通过 uid 读取 RelationNode 对象: uid ---> relationNode
2:通过 relationNode.fansListKey 读取粉丝列表: relationNode.fansListKey ---> fansList
3:通过 relationNode.fansListExtKey 读取超出部分的粉丝列表 relationNode.fansListExtKey ---> fansExtList
以上只是一个很直白的简单的方案,具体实现时可以有很多的优化,例如 fansListExtKey 可以省去,仅仅去利用约定的生成方式就可以得到 key 值,还可以对超出 5000 的粉丝进行分页存放,那么生成的 key 可能是 uidFansListKeyPn (n >= 1)
Pn 可以通过 fansAmount 与 pageSize 计算出来
经过优化过的方案,读取方式可能如下:
1:通过 uid 读取 RelationNode 对象
2:通过 fansAmount 与 pageSize (假定是新浪微博使用的5000) 得到 Pn
3:通过 uid + FansListKey + Pn 得到某一页的粉丝,如:12345FansListKeyP1,第一页正好是需要显示的 5000 个
当然,上面的设计只是大致解决存取的问题,要做一些复杂业务时可能还要继续优化,例如需要得到某两个人共同的粉丝列表,假如是两个大 V 共同的粉丝列表可能会出现性能问题
总体的设计方向是引入一个或多个中间数据结构并且分多步对 reids 进行存取,再根据具体的业务规模与特点进行数据结构和算法的进一步优化
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。