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就没有排序功能了。