出處:http://blog.csdn.net/cleanfield/article/details/6339428 注意,原文下面的評(píng)論也是難得的學(xué)習(xí)資料,千萬(wàn)不能錯(cuò)過(guò) 用戶信息表(t_user_info) 字段名稱 字節(jié)數(shù) 類型 描述 User_id 4 uint32 用戶編號(hào)(主鍵) User_name 20 Char[20] 名稱 Msg_count 4
出處: http://blog.csdn.net/cleanfield/article/details/6339428
注意,原文下面的評(píng)論也是難得的學(xué)習(xí)資料,千萬(wàn)不能錯(cuò)過(guò)
用戶信息表(t_user_info)
字段名稱 |
字節(jié)數(shù) |
類型 |
描述 |
User_id |
4 |
uint32 |
用戶編號(hào)(主鍵) |
User_name |
20 |
Char[20] |
名稱 |
Msg_count |
4 |
uint32 |
發(fā)布消息數(shù)量,可以作為t_msg_info水平切分新表的auto_increment |
Fans_count |
4 |
uint32 |
粉絲數(shù)量 |
Follow_count |
4 |
Uint32 |
關(guān)注對(duì)象數(shù)量 |
備注:以User_id取模分表
用戶之間關(guān)系表(t_user_relation),必須有關(guān)注與被關(guān)注的關(guān)系
字段名稱 |
字節(jié)數(shù) |
類型 |
描述 |
User_id |
4 |
uint32 |
用戶編號(hào)(聯(lián)合主鍵) |
Follow_id |
4 |
uint32 |
被關(guān)注者編號(hào)(聯(lián)合主鍵) |
Type |
1 |
Uint8 |
關(guān)系類型(0,粉絲;1,關(guān)注) |
備注:關(guān)系是單向的,以User_id取模分表
用戶消息索引表(t_uer_msg_index)
字段名稱 |
字節(jié)數(shù) |
類型 |
描述 |
User_id |
4 |
uint32 |
用戶編號(hào)(聯(lián)合主鍵) |
Author_id |
4 |
uint32 |
消息發(fā)布者編號(hào)(可能是被關(guān)注者,也可能是自己)(聯(lián)合主鍵) |
Msg_id |
4 |
uint32 |
消息編號(hào)(由消息發(fā)布者的msg_count自增)(聯(lián)合主鍵) |
Time_t |
4 |
Uint32 |
發(fā)布時(shí)間(必須是消息元數(shù)據(jù)產(chǎn)生時(shí)間) |
備注:此表就是當(dāng)我們點(diǎn)擊“我的首頁(yè)”時(shí)拉取的消息列表,只是索引,Time_t對(duì)這些消息進(jìn)行排序
消息與消息關(guān)系表(t_msg_msg_relation)
字段名稱 |
字節(jié)數(shù) |
類型 |
描述 |
Reference_id |
4 |
uint32 |
引用消息用戶編號(hào)(聯(lián)合主鍵) |
Reference _msg_id |
4 |
uint32 |
引用消息編號(hào)(聯(lián)合主鍵) |
Referenced_id |
4 |
uint32 |
消息發(fā)布者編號(hào) |
Referenced _msg_id |
4 |
uint32 |
被引用消息編號(hào) |
Type |
1 |
Uint8 |
操作類型(1,評(píng)論;2,轉(zhuǎn)發(fā)) |
Time_t |
4 |
Uint32 |
發(fā)布時(shí)間 |
Page_index |
4 |
Uint32 |
轉(zhuǎn)發(fā)或者評(píng)論頁(yè)碼 |
備注:以Reference_id取模分表。
騰訊微博比新浪微博好的一點(diǎn)是一個(gè)消息的所有評(píng)論和轉(zhuǎn)發(fā)都是被固定頁(yè)碼,這樣在點(diǎn)擊看評(píng)論的時(shí)候搜索效率更高,因?yàn)槎嗔艘粋€(gè)where Page_index的定位條件,當(dāng)然帶來(lái)的問(wèn)題就是可能看到有些頁(yè)的評(píng)論排版并不是滿頁(yè),這就是因?yàn)闃?biāo)識(shí)為這個(gè)Page_index的評(píng)論有刪除操作。
消息元數(shù)據(jù)表(t_msg_info)
字段名稱 |
字節(jié)數(shù) |
類型 |
描述 |
User_id |
4 |
uint32 |
發(fā)消息用戶編號(hào)(聯(lián)合主鍵) |
Msg_id |
4 |
uint32 |
消息編號(hào)(聯(lián)合主鍵) |
Content |
140 |
Char[140] |
消息內(nèi)容 |
Type |
1 |
Uint8 |
消息類型(0,原創(chuàng);1,評(píng)論;2,轉(zhuǎn)發(fā)) |
Commented_count |
4 |
Uint32 |
評(píng)論過(guò)數(shù)量(只增不減,刪除評(píng)論不影響此值,可以作為評(píng)論多頁(yè)顯示的頁(yè)碼) |
Comment_count |
4 |
Uint32 |
保留的評(píng)論數(shù)量 |
Transferred_count |
4 |
Uint32 |
轉(zhuǎn)發(fā)過(guò)數(shù)量(只增不減,刪除轉(zhuǎn)發(fā)不影響此值,可以作為轉(zhuǎn)發(fā)多頁(yè)顯示的頁(yè)碼) |
Transfer_count |
4 |
Uint32 |
保留的轉(zhuǎn)發(fā)數(shù)量 |
Time_t |
4 |
Uint32 |
發(fā)布時(shí)間 |
備注:消息元數(shù)據(jù)中,content像可能存在圖片,這部分可以在分布式文件系統(tǒng)中存儲(chǔ)。在2011年數(shù)據(jù)庫(kù)大會(huì)上聽(tīng)楊海潮的演講,對(duì)于nosql 也有涉及,本人能力有限,對(duì)這部分的職責(zé)還不清楚,希望高人指點(diǎn)。
非常推崇楊海潮ppt中的歸檔做法,因?yàn)槲⒉┦怯袝r(shí)間軸線的,對(duì)于一定時(shí)間之前的記錄可以分層次歸檔,這樣在前端的最新的數(shù)據(jù)表的壓力就會(huì)減輕很多。
業(yè)務(wù)邏輯:
1.A關(guān)注B
1)在t_user_relation_A中添加
A |
B |
1 |
2)在t_user_relation_B中添加
B |
A |
0 |
2.原創(chuàng)發(fā)消息
1)在t_msg_info_A中添加這條元消息,type為0
2)更新t_user_info_A中Msg_count
3)在t_uer_msg_index_A中插入A發(fā)的這條消息的索引(A的編號(hào)和消息編號(hào))
4)在t_user_relation_A中找到所有關(guān)注A的人,比如B,C,D,E,F等等,并發(fā)在這些用戶的t_uer_msg_index中插入A的這條信息索引,比如名人微博可以并發(fā)多個(gè)進(jìn)程來(lái)實(shí)現(xiàn)對(duì)粉絲的消息同步
3.A轉(zhuǎn)發(fā)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發(fā)的這條消息的索引(A的編號(hào)和消息編號(hào))
4)在t_msg_info_B中更新msg_b的Transferred_count和Transfer_count
5)在t_msg_msg_relation中添加User_a,msg_a與User_b,msg_b的轉(zhuǎn)發(fā)關(guān)系,page_index為Transferred_count%page_count
4.A評(píng)論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發(fā)的這條消息的索引(A的編號(hào)和消息編號(hào))
4)在t_msg_info_B中更新msg_b的Commented_count和Comment_count
5)在t_msg_msg_relation中添加User_a,msg_a與User_b,msg_b的評(píng)論關(guān)系,page_index為Commented_count%page_count
5.A刪除消息msg_a
1)刪除t_msg_info中的元數(shù)據(jù)msg_a
2)刪除t_uer_msg_index_A中的User_a,msg_a行記錄
3)備注:如果A的msg_a被別人評(píng)論或者引用,那么在對(duì)方查看評(píng)論或者轉(zhuǎn)發(fā)的時(shí)候會(huì)提示“原消息已被作者刪除”
6.A刪除轉(zhuǎn)發(fā)消息msg_a
1)刪除t_msg_info_A中的元數(shù)據(jù)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的轉(zhuǎn)發(fā)關(guān)系
5)更新t_msg_info_B中msg_b記錄的Transfer_count,減1
7.A刪除評(píng)論消息msg_a
1)刪除t_msg_info_A中的元數(shù)據(jù)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的評(píng)論關(guān)系
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)通過(guò)頁(yè)碼和每頁(yè)count控制返回結(jié)果數(shù)量,這樣避免了server io 壓力沖擊
5月25日更新:
1)條件允許的話,所有的index表可以放到內(nèi)存中,全部cache,而元數(shù)據(jù)直接ssd,這樣讀速度會(huì)提高很多,當(dāng)然也要做好熱備
2)t_user_relation表最好做合并存儲(chǔ)
5月27日更新:
1)在第二步原創(chuàng)發(fā)消息要通知給粉絲,這時(shí)如果是明星,那么推送的數(shù)量可能數(shù)百萬(wàn),新浪采取的做法是對(duì)這數(shù)百萬(wàn)粉絲進(jìn)行區(qū)別對(duì)待,按照活躍度劃分為幾個(gè)層級(jí),每個(gè)層級(jí)有一個(gè)推送時(shí)效限定,這樣可以做到最想看到這個(gè)信息的人能夠最及時(shí)的看到明星動(dòng)態(tài)
2)用硬件來(lái)提升速度,將所有index表放在memory上,元數(shù)據(jù)放在ssd上,數(shù)據(jù)可以現(xiàn)在這兩層上做處理,并定時(shí)持久化到mysql中
3)提供批量處理接口,比如拉取最新更新索引
4)在一定限度上容忍不一樣,但要實(shí)現(xiàn)最終一致性
6月1日更新:
本文用的是push模式,關(guān)于微博的pull模式,請(qǐng)參見(jiàn) http://blog.csdn.net/cleanfield/archive/2011/05/27/6450626.aspx
6月30日更新:
在新浪微博中,評(píng)論和轉(zhuǎn)發(fā)都與原創(chuàng)消息是一樣的獨(dú)立記錄,只不過(guò)多了一條消息關(guān)系記錄,在展現(xiàn)的時(shí)候除了要展現(xiàn)自己添加的轉(zhuǎn)發(fā)內(nèi)容或評(píng)論內(nèi)容之外,還需要將最原始的那條目標(biāo)消息取出來(lái)。
12月8日更新:
消息與消息關(guān)系表(t_msg_msg_relation)的備注中,應(yīng)該是以Referenced_id取模分裂
聲明:本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí),若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com