类似微信圈子的数据设计思路

[不想离开水的鱼]

我目前的想法是：
用户一个表A
用户好友一个表B
完后用户发表的信息按照用户id做散列C1-C128
然后每个用户缓存前50个最新信息的id和时间
读取每个人的好友圈子的时候，
先去取每个人的好友，完后取到每个好友的发表信息的id，和时间，根据时间排序，做分页。

我的想法是限制每个人的好友数量。
但是我估计效果不是太好，不知道各位有没有更好的思路。

[MiceRice]

我认为反向投递的可能性更高些。 也就是当某用户X发了一个消息，则向该用户的好友消息盒中都增加一条信息；类似于群发邮件的设计，以空间换时间。 每个人消息盒子设置容量规模，效果就是近期的消息（比如100条以内）直接去消息盒子里面查，超过100条的靠查询检索。

[hemaliu]

看Twitter的文章，如果数据量小什么都好说，如果量大，那就呵呵

[不想离开水的鱼]

引用 1 楼 ldh911 的回复:

我认为反向投递的可能性更高些。 也就是当某用户X发了一个消息，则向该用户的好友消息盒中都增加一条信息；类似于群发邮件的设计，以空间换时间。 每个人消息盒子设置容量规模，效果就是近期的消息（比如100条以内）直接去消息盒子里面查，超过100条的靠查询检索。

首先抱歉一下，最近比较忙，回复晚了，但是我觉得用这种方法，会在删除消息或者添加好友等方面产生大量的操作，尤其当好友关系丰富之后，只是不知道这个代价和读的代价最终会变成谁比较大。 另外，我的数据量应该都不是很大的

[不想离开水的鱼]

我估计也没有更好的办法了，先这样吧，谢谢二位

[MiceRice]

引用 3 楼 ivyandrich 的回复:

首先抱歉一下，最近比较忙，回复晚了，但是我觉得用这种方法，会在删除消息或者添加好友等方面产生大量的操作，尤其当好友关系丰富之后，只是不知道这个代价和读的代价最终会变成谁比较大。

其实代价不算很大，大部分人的好友也就 数百级别（考虑下80/20原则吧）；只有少数明星级需要特殊优化。 删除消息和添加好友类的操作，远比你每次访问都去检索效率要高很多。而且这种更新恐怕还未必是实时性的，很可能是队列处理，也就是有个若干秒延迟。 不过必然还有更具体的一些优化操作方案，“投递”这个只能算是一个宏观方案。