之前看了唐福林 新浪微博开放平台中的Redis实践的公开视频
其中讲到存储用户粉丝信息使用的是Redis的hash类型,每个用户一张hash表来存储粉丝。为了方便对关注时间进行排序,用hash表的fields存储粉丝ID,value存储关注时间。
我想大概是这样:
key: 用户ID加前后缀
field: 粉丝ID
value:关注时间
user_1_fans
field | value |
---|---|
2 | 1483423443 |
3 | 1483423445 |
13 | 1483423440 |
... | ... |
user_2_fans
field | value |
---|---|
1 | 1483423443 |
5 | 1483423445 |
10 | 1483423440 |
... | ... |
......
但是使用这种方法时我发现hash是无序状态的,也就是每次要获取最新的几个粉丝都需要获取所有的粉丝,然后遍历按时间戳进行排序。
而我又发现了另一种数据类型 有序集合(sorted set)
如果使用Sort Set数据类型存储粉丝列表的话就方便多了。
依然使用当前用户ID加前后缀作Key,以粉丝的ID作member,关注时间作score。也一样可以用来存储用户粉丝,而且有序集合(sorted set)的命令更加灵活,根据score排序,筛选等非常方便。
key: 用户ID加前后缀
member: 粉丝ID
score:关注时间
user_1_fans
member | score |
---|---|
2 | 1483423443 |
3 | 1483423441 |
13 | 1483423440 |
... | ... |
user_2_fans
member | score |
---|---|
1 | 1483423443 |
5 | 1483423442 |
10 | 1483423440 |
... | ... |
......
那么问题来了:新浪微博为什么会采取第一种方式来存储粉丝(2011年,现在不知道了)?
第一种方式有哪些优势,第二种方式又有哪些弊端呢?
如果我说两种方式结合到一起呢?
另外hash,你的理解是错误的。
hash不像数据库或者excel,一个hash存储的虽然是多个字段,但不是多行数据且每行多个字段
你上述的应该这么去做:
假设当前用户ID为1;
首先:依靠有序集合实现好友关系(对应的score就是关注时间戳),假设与用户ID:2,3,4为好友
其次:使用hash去记录好友的具体信息(多个hash),存储规则如下: