新浪微網誌，騰訊微網誌mysql資料庫主表猜想

使用者資訊表（t_user_info）

字段名稱

位元組數

類型

描述

User_id

4

uint32

使用者編号（主鍵）

User_name

20

Char[20]

名稱

Msg_count

釋出消息數量,可以作為t_msg_info水準切分新表的auto_increment

Fans_count

粉絲數量

Follow_count

Uint32

關注對象數量

備注：以User_id取模分表

使用者之間關系表（t_user_relation）,必須有關注與被關注的關系

使用者編号（聯合主鍵）

Follow_id

被關注者編号（聯合主鍵）

Type

1

Uint8

關系類型（0，粉絲；1，關注）

備注：關系是單向的，以User_id取模分表

使用者消息索引表（t_uer_msg_index）

Author_id

消息釋出者編号（可能是被關注者，也可能是自己）（聯合主鍵）

Msg_id

消息編号(由消息釋出者的msg_count自增)（聯合主鍵）

Time_t

釋出時間（必須是消息中繼資料産生時間）

備注：此表就是當我們點選“我的首頁”時拉取的消息清單，隻是索引，Time_t對這些消息進行排序

消息與消息關系表（t_msg_msg_relation）

Reference_id

引用消息使用者編号（聯合主鍵）

Reference _msg_id

引用消息編号（聯合主鍵）

Referenced_id

消息釋出者編号

Referenced _msg_id

被引用消息編号

操作類型(1,評論；2，轉發)

釋出時間

Page_index

轉發或者評論頁碼

備注：以Reference_id取模分表。

騰訊微網誌比新浪微網誌好的一點是一個消息的所有評論和轉發都是被固定頁碼，這樣在點選看評論的時候搜尋效率更高，因為多了一個where Page_index的定位條件，當然帶來的問題就是可能看到有些頁的評論排版并不是滿頁，這就是因為辨別為這個Page_index的評論有删除操作。

消息中繼資料表（t_msg_info）

發消息使用者編号（聯合主鍵）

消息編号（聯合主鍵）

Content

140

Char[140]

消息内容

消息類型（0，原創；1，評論；2，轉發）

Commented_count

評論過數量（隻增不減，删除評論不影響此值，可以作為評論多頁顯示的頁碼）

Comment_count

保留的評論數量

Transferred_count

轉發過數量（隻增不減，删除轉發不影響此值，可以作為轉發多頁顯示的頁碼）

Transfer_count

保留的轉發數量

 備注：消息中繼資料中，content像可能存在圖檔，這部分可以在分布式檔案系統中存儲。在2011年資料庫大會上聽楊海潮的演講，對于nosql 也有涉及，本人能力有限，對這部分的職責還不清楚，希望高人指點。

非常推崇楊海潮ppt中的歸檔做法，因為微網誌是有時間軸線的，對于一定時間之前的記錄可以分層次歸檔，這樣在前端的最新的資料表的壓力就會減輕很多。

業務邏輯：

1.A關注B

1）在t_user_relation_A中添加

A

B

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

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

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

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

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取模分裂