类似于新浪微博和人人网首页 新鲜事的表结构如何设计？？？

用 Redis 之类的 NoSQL 来存吧

[这是我尝试解答Fenng提出问题二， 欢迎拍砖]

尝试回答一下第二问题：
这个问题其实可以拆成三个， 1、朋友圈的feeds是如何存的， 2、朋友圈的权鉴是如何做的
3、timeline怎么做的（结合1、2）

1、feeds的话我猜测和空间feeds类似在内存数据库里面存放了最近的10条feeds， 其余的全部存在内存里面。虽然目前微信这个小儿子很受老爹重视也不至于把全部内容都扔到内存里面存放。
具体是怎么存放又要分成两种情况 A、腾讯内部实现， B、外部实现

A、我猜测应该是挂在了某个”uin“下面，并且根据这个“uin”进行了分库，当然这个分库和平时数据库的还不太一样，这个分库尺度更加大一些， 这些库分布在多地， “uin”有一定的区域特征。 腾讯里面有一个组件叫做Tmem， 这个组件是改至memcache， 它比memcache好的地方就是可以做到平滑扩容并且实现了分布式， 所以某个地区应该有一个非常庞大的分布式内存系统。

B、外部的人员就有点蛋疼了，没得Tmem这么好的东西，如何设计一个分布式集群并且能够实现自动化扩容。 既然我们是外部人员，我们就可以预先假设uin是64位整数， 我们提前预估好单台机器的储存， 比如说我们单台机器64G，那么memcache可以用内存保持在60%比较合适，也就是说memcache的内存分配最好在64G*60%=38G左右， 假设单挑feeds是1k， 那么10挑feeds就是10K数据， 38G/10k = 400W用户 这样我们大致可以按照uin/400W用户来进行分库，不过最好的数值还是业务上线后观察数据，然后进行调整。

2、权鉴系统分成两种 A、我不看别人的朋友圈 B、别人不让我看她的朋友圈
A、我自己保存一个不看的uin列表、当数据从服务器拉下来以后客户端过滤掉即可
B、我自己保存一个别人不让我看的uin列表，拉完热点用户数据以后把相应的数据在服务器端过滤掉

3、timeline模块要做到 A、小红点（好友有新feeds） B、拉去到好友的最新数据 C、不能重复拉取好友最新的消息
A、这个应该是一个bitmap服务， 每当一个用户发了feeds以后，就就把他的好友列表发送到这个服务，然后这个服务置位， 手机客户端定期刷新或者在某些时机刷新（比如从锁机界面到微信界面），确定是否点亮小红点。写bitmap之前这个服务应该会做去重的工作来避免大量的写bitmap。
去重工作主要是堆机器和hash的利用没有什么难点。（把好友的uin位置位，通知好友有小红点）

B、这也应该是一个bitmap服务， 当用户发送了消息以后， 把这个用户的标志位位置（把自己uin置位）优化点1、这个可能对于热衷于刷朋友圈的用户会做缓存 2、对于好友数多得用户做缓存 来避免大量的访问bitmap, 这里还需要额外的存储记录还有多少好友需要更新朋友圈，以及feeds的seq

C、每个用户的feeds都有一个序列号（seq）微信初始化的时候每个好友的seq都为0，随着不断获取信息这个序列号逐渐变大，这也方式重复拉去或者显示feeds。 （从微信重新安装以后要拉去很多数据就可以能验证出来）