Redis实战系列(4) key的设计
我们的业务是内部微博,主要模块有 用户信息、微博信息、我关注的人、我的粉丝、我关注的人发布的微博、我发布的微博,还有类似sina微博的小黄签之类的提醒功能。
key的设计如下:
1.用户信息 用户信息是离散,因此用hashtable来存储以用户的user_id为key。实例 user:info:$user_id 其中$user_id是动态的变量 user:info:123是一个hashtable,里面的字段是每个用户的所有信息。取多个用户的信息可以用pipeline,或者是用sort命令的get参数。设置的时候用hmset命令
2.微博信息 微博信息也是离散的,所以存储于用户信息相同。实例 notice:$notice_id
3.我关注的人 这个按照关注事件倒序排列,也就是说我最后关注的将会出现在第一页,开始的时候我是用的sorted_set,member是user_id score是关注的时间戳,但是sorted_set占用的内存过多,所以后来改成list数据结构来存储,list数据结构只进行lpush和lrange的操作,删除用lrem。但是这样就无法进行相关的计算了,例如我关注的人共同关注的人。这个可以用sinter命令来处理。不过我的做法是放到redis之外进行处理。读取方法:sort by=>nosort get user:info:*->user_id get user:info:*->nickname...
4.我的粉丝与我关注的人类似。
我们的业务是内部微博,主要模块有 用户信息、微博信息、我关注的人、我的粉丝、我关注的人发布的微博、我发布的微博,还有类似sina微博的小黄签之类的提醒功能。
key的设计如下:
1.用户信息 用户信息是离散,因此用hashtable来存储以用户的user_id为key。实例 user:info:$user_id 其中$user_id是动态的变量 user:info:123是一个hashtable,里面的字段是每个用户的所有信息。取多个用户的信息可以用pipeline,或者是用sort命令的get参数。设置的时候用hmset命令
2.微博信息 微博信息也是离散的,所以存储于用户信息相同。实例 notice:$notice_id
3.我关注的人 这个按照关注事件倒序排列,也就是说我最后关注的将会出现在第一页,开始的时候我是用的sorted_set,member是user_id score是关注的时间戳,但是sorted_set占用的内存过多,所以后来改成list数据结构来存储,list数据结构只进行lpush和lrange的操作,删除用lrem。但是这样就无法进行相关的计算了,例如我关注的人共同关注的人。这个可以用sinter命令来处理。不过我的做法是放到redis之外进行处理。读取方法:sort by=>nosort get user:info:*->user_id get user:info:*->nickname...
4.我的粉丝与我关注的人类似。
5.我关注的人发布的微博 这个用list数据结构来存储,这里要保证的是微博的id大的比小的时间要晚,也就是说123产生的时间一定比122产生的时间晚,否则将无法保证顺序。当存储我关注的人发布的微博的时候。读取方法:sort by=>nosort get notice:*->content get notice:*->user_id...
6.发布的微博和我关注的人发布的微博类似。
7.小黄签只是一个数字提醒,因此与user:info放在同一个hashtable中