新浪微博，腾讯微博mysql数据库主表猜想

用户信息表（t_user_info）

备注：以User_id取模分表

用户之间关系表（t_user_relation）,必须有关注与被关注的关系

备注：关系是单向的，以User_id取模分表

用户消息索引表（t_uer_msg_index）

备注：此表就是当我们点击“我的首页”时拉取的消息列表，只是索引，Time_t对这些消息进行排序

消息与消息关系表（t_msg_msg_relation）

备注：以Reference_id取模分表。

腾讯微博比新浪微博好的一点是一个消息的所有评论和转发都是被固定页码，这样在点击看评论的时候搜索效率更高，因为多了一个where Page_index的定位条件，当然带来的问题就是可能看到有些页的评论排版并不是满页，这就是因为标识为这个Page_index的评论有删除操作。

消息元数据表（t_msg_info）

 备注：消息元数据中，content像可能存在图片，这部分可以在分布式文件系统中存储。在2011年数据库大会上听杨海潮的演讲，对于nosql 也有涉及，本人能力有限，对这部分的职责还不清楚，希望高人指点。

非常推崇杨海潮ppt中的归档做法，因为微博是有时间轴线的，对于一定时间之前的记录可以分层次归档，这样在前端的最新的数据表的压力就会减轻很多。

业务逻辑：

1.A关注B

1）在t_user_relation_A中添加

2）在t_user_relation_B中添加

2.原创发消息

1）在t_msg_info_A中添加这条元消息，type为0

2）更新t_user_info_A中Msg_count

3）在t_uer_msg_index_A中插入A发的这条消息的索引（A的编号和消息编号）

4）在t_user_relation_A中找到所有关注A的人，比如B,C,D,E,F等等，并发在这些用户的t_uer_msg_index中插入A的这条信息索引，比如名人微博可以并发多个进程来实现对粉丝的消息同步

3.A转发B的消息msg_b

1）在t_msg_info_A中添加这条元消息msg_a，type为2

2）更新t_user_info_A中Msg_count

3）在t_uer_msg_index_A中插入A发的这条消息的索引（A的编号和消息编号）

4）在t_msg_info_B中更新msg_b的Transferred_count和Transfer_count

5）在t_msg_msg_relation中添加User_a,msg_a与User_b，msg_b的转发关系，page_index为Transferred_count%page_count

4.A评论B的消息msg_b

1）在t_msg_info_A中添加这条元消息msg_a，type为1

2）更新t_user_info_A中Msg_count

3）在t_uer_msg_index_A中插入A发的这条消息的索引（A的编号和消息编号）

4）在t_msg_info_B中更新msg_b的Commented_count和Comment_count

5）在t_msg_msg_relation中添加User_a,msg_a与User_b，msg_b的评论关系，page_index为Commented_count%page_count

5.A删除消息msg_a

1）删除t_msg_info中的元数据msg_a

2）删除t_uer_msg_index_A中的User_a，msg_a行记录

3）备注：如果A的msg_a被别人评论或者引用，那么在对方查看评论或者转发的时候会提示“原消息已被作者删除”

6.A删除转发消息msg_a

1）删除t_msg_info_A中的元数据msg_a

2）删除t_uer_msg_index_A中的User_a，msg_a行记录

3）在t_msg_msg_relation_A表中找到msg_a的源消息，即B的msg_b

4）删除t_msg_msg_relation_A中user_a，msg_a和user_b，msg_b的转发关系

5）更新t_msg_info_B中msg_b记录的Transfer_count，减1

7.A删除评论消息msg_a

1）删除t_msg_info_A中的元数据msg_a

2）删除t_uer_msg_index_A中的User_a，msg_a行记录

3）在t_msg_msg_relation_A表中找到msg_a的源消息，即B的msg_b

4）删除t_msg_msg_relation_A中user_a，msg_a和user_b，msg_b的评论关系

5）更新t_msg_info_B中msg_b记录的Commecnt_count，减1

8.A拉取全部消息

1）从t_uer_msg_index_A中拉取Author_id，Msg_id，Time_t索引，并以Time_t排序

2）通过页码和每页count控制返回结果数量，这样避免了server io 压力冲击

5月25日更新：

1）条件允许的话，所有的index表可以放到内存中，全部cache，而元数据直接ssd，这样读速度会提高很多，当然也要做好热备

2）t_user_relation表最好做合并存储

5月27日更新：

1）在第二步原创发消息要通知给粉丝，这时如果是明星，那么推送的数量可能数百万，新浪采取的做法是对这数百万粉丝进行区别对待，按照活跃度划分为几个层级，每个层级有一个推送时效限定，这样可以做到最想看到这个信息的人能够最及时的看到明星动态

2）用硬件来提升速度，将所有index表放在memory上，元数据放在ssd上，数据可以现在这两层上做处理，并定时持久化到mysql中

3）提供批量处理接口，比如拉取最新更新索引

4）在一定限度上容忍不一样，但要实现最终一致性

6月1日更新：

本文用的是push模式，关于微博的pull模式，请参见 http://blog.csdn.net/cleanfield/archive/2011/05/27/6450626.aspx

6月30日更新：

在新浪微博中，评论和转发都与原创消息是一样的独立记录，只不过多了一条消息关系记录，在展现的时候除了要展现自己添加的转发内容或评论内容之外，还需要将最原始的那条目标消息取出来。

12月8日更新：

消息与消息关系表（t_msg_msg_relation）的备注中，应该是以Referenced_id取模分裂