用户信息表(t_user_info)

字段名称

字节数

类型

描述

User_id

4

uint32

用户编号(主键)

User_name

20

Char[20]

名称

Msg_count

4

uint32

发布消息数量,可以作为t_msg_info水平切分新表的auto_increment

Fans_count

4

uint32

粉丝数量

Follow_count

4

Uint32

关注对象数量

备注：以User_id取模分表

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

字段名称

字节数

类型

描述

User_id

4

uint32

用户编号(联合主键)

Follow_id

4

uint32

被关注者编号(联合主键)

Type

1

Uint8

关系类型(0，粉丝；1，关注)

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

用户消息索引表(t_uer_msg_index)

字段名称

字节数

类型

描述

User_id

4

uint32

用户编号(联合主键)

Author_id

4

uint32

消息发布者编号(可能是被关注者，也可能是自己)(联合主键)

Msg_id

4

uint32

消息编号(由消息发布者的msg_count自增)(联合主键)

Time_t

4

Uint32

发布时间(必须是消息元数据产生时间)

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

消息与消息关系表(t_msg_msg_relation)

字段名称

字节数

类型

描述

Reference_id

4

uint32

引用消息用户编号(联合主键)

Reference _msg_id

4

uint32

引用消息编号(联合主键)

Referenced_id

4

uint32

消息发布者编号

Referenced _msg_id

4

uint32

被引用消息编号

Type

1

Uint8

操作类型(1,评论；2，转发)

Time_t

4

Uint32

发布时间

Page_index

4

Uint32

转发或者评论页码

备注：以Reference_id取模分表。

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

消息元数据表(t_msg_info)

字段名称

字节数

类型

描述

User_id

4

uint32

发消息用户编号(联合主键)

Msg_id

4

uint32

消息编号(联合主键)

Content

140

Char[140]

消息内容

Type

1

Uint8

消息类型(0，原创；1，评论；2，转发)

Commented_count

4

Uint32

评论过数量(只增不减，删除评论不影响此值，可以作为评论多页显示的页码)

Comment_count

4

Uint32

保留的评论数量

Transferred_count

4

Uint32

转发过数量(只增不减，删除转发不影响此值，可以作为转发多页显示的页码)

Transfer_count

4

Uint32

保留的转发数量

Time_t

4

Uint32

发布时间

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

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

业务逻辑：

1.A关注B

1)在t_user_relation_A中添加

A

B

1

2)在t_user_relation_B中添加

B

A

0

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日更新：

6月30日更新：

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

12月8日更新：

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

2014年11月11日更新：

用户A转发用户B的消息meg_b，其实也是会产生一个消息元数据msg_a，而msg_a与msg_b是转发关系而已，从另一层面上说，也可以理解为A做了一次原创，这次产生的消息也会push到A的关注着消息列表中。

现在新浪微博可以看到哪些人转发了消息msgA, 转发内容是怎样的。这需要做一种反向映射，就是一个msgA对应一个msgXXX列表。简单点，可以直接一个kv存储，v是一个队列，mysql与nosql都可以很方便的搞定

16年10月20日更新：