redis存储微博点赞的人，如何存储？

Question

比如说有一个微博的TID是1。UID为1,2,3,4,5,6，7,8,9的用户都给这个微博点赞了。用redis缓存框架存储的话如何存储。微博可能有几十万个。如果用key->set(value)这种形式的话key是微博ID的标示value是[1,2,3,4,5,6，7,8,9]这种形式，这样的话有多少个微博就有多少个K-V存储。我想知道这样会有什么弊端吗？或者有什么更好的方法吗？

Answer 1

可以采用多个HashSet存储。每一条微博只是HashSet内的一个子key。增加赞的数量可以采用HIncrBy命令。把TID分块，使得每个HashSet内的key不超过100个。官方文档表示HashSet在内部元素小于一百个的时候采用线性存储与扫描，跟同数据规模下树形结构相比效率更高，更省内存。
例如：TID为123456的微博存在z:1234的HashSet中，其key为56。假设最新的微博活跃程度也较高，那么绝大多数情况下被调用的HashSet只有区区几个，对CPU的缓存很友好。
如果要管理赞的用户，可以自定义数据格式。在用户数量少的时候把用户列表整个内嵌到HashSet的值域中。用户超过比如50人后将其单独整理出一个Set，在HashSet里保存Set的key。例：
bash#内嵌UID的情况
hgetz:123456
>"1,2,3,4"...
#使用set的情况
hgetz:123456
>"UIDlist:10"
smembersUIDlist:10
>1)"1"
>2)"2"
>...
由于绝大多数微博赞的用户均比较少，HashSet可以节省出不少全局空间的key（全局key比HashSet的key更耗内存）。
关于@卖掉内裤去上网的回答：
若采用in-placequicksort，50个用户的手动排序效率非常高，因为在这个数据规模下数据紧密存放带来的缓存友好性远胜于RedisZSet相对于手动排序带来的提升。而赞的用户升上去后就会自动适应成set或者zset，保证算法时间复杂度。如果还担心效率，可以把排序好的UID列表重新写回HashSet的一个value中，以后没有数据改变的话直接使用。
究竟采用set还是zset还是要看楼主的需求。set加入一个成员的复杂度为O(1)，zset是O(logN)，但set就没有排序功能了。