使用者資訊表（t_user_info）
欄位名稱
位元組數
型別
描述
user_id
4uint32
使用者編號（主鍵）
user_name
20char[20]
名稱msg_count
4uint32
發布訊息數量,可以作為t_msg_info水平切分新錶的auto_increment
fans_count
4uint32
粉絲數量
follow_count
4uint32
關注物件數量
備註：以user_id取模分表
使用者之間關係表（t_user_relation）,必須有關注與被關注的關係
欄位名稱
位元組數
型別
描述
user_id
4uint32
使用者編號（聯合主鍵）
follow_id
4uint32
被關注者編號（聯合主鍵）
type
1uint8
關係型別（0，粉絲；1，關注）
備註：關係是單向的，以user_id取模分表
使用者訊息索引表（t_uer_msg_index）
欄位名稱
位元組數
型別
描述
user_id
4uint32
使用者編號（聯合主鍵）
author_id
4uint32
訊息發布者編號（可能是被關注者，也可能是自己）（聯合主鍵）
msg_id
4uint32
訊息編號(由訊息發布者的msg_count自增)（聯合主鍵）
time_t
4uint32
發布時間（必須是訊息元資料產生時間）
備註：此表就是當我們點選「我的首頁」時拉取的訊息列表，只是索引，time_t對這些訊息進行排序
訊息與訊息關係表（t_msg_msg_relation）
欄位名稱
位元組數
型別
描述
reference_id
4uint32
引用訊息使用者編號（聯合主鍵）
reference _msg_id
4uint32
引用訊息編號（聯合主鍵）
referenced_id
4uint32
訊息發布者編號
referenced _msg_id
4uint32
被引用訊息編號
type
1uint8
time_t
4uint32
發布時間
page_index
4uint32
備註：以reference_id取模分表。
訊息元資料表（t_msg_info）
欄位名稱
位元組數
型別
描述
user_id
4uint32
發訊息使用者編號（聯合主鍵）
msg_id
4uint32
訊息編號（聯合主鍵）
content
140char[140]
訊息內容
type
1uint8
commented_count
4uint32
comment_count
4uint32
transferred_count
4uint32
**過數量（只增不減，刪除**不影響此值，可以作為**多頁顯示的頁碼）
transfer_count
4uint32
保留的**數量
time_t
4uint32
發布時間
備註：訊息元資料中，content像可能存在，這部分可以在分布式檔案系統中儲存。在2023年資料庫大會上聽楊海潮的演講，對於nosql 也有涉及，本人能力有限，對這部分的職責還不清楚，希望高人指點。
非常推崇楊海潮ppt中的歸檔做法，因為微博是有時間軸線的，對於一定時間之前的記錄可以分層次歸檔，這樣在前端的最新的資料表的壓力就會減輕很多。
業務邏輯：
1.a關注b
1）在t_user_relation_a中新增ab
12）在t_user_relation_b中新增ba
02.原創發訊息
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
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.a刪除訊息msg_a
1）刪除t_msg_info中的元資料msg_a
2）刪除t_uer_msg_index_a中的user_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
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
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日更新：
2）用硬體來提公升速度，將所有index表放在memory上，元資料放在ssd上，資料可以現在這兩層上做處理，並定時持久化到mysql中
3）提供批量處理介面，比如拉取最新更新索引
4）在一定限度上容忍不一樣，但要實現最終一致性
6月1日更新：
本文用的是push模式，關於微博的pull模式，請參見
6月30日更新：
12月8日更新：
訊息與訊息關係表（t_msg_msg_relation）的備註中，應該是以referenced_id取模**
原文：
騰訊空間 新浪微博 騰訊微博登入介面
1 引用js檔案 2 html 3 js指令碼 document ready function 第三方平台登入 var tpalogin 儲存登入使用者資訊 param 引數重置 paramreset function qq空間 qzone function function reqdata,opt...
實戰新浪微博 騰訊微博的分享功能
算上也是半年前做的，今天翻出來放出來，作為日誌記錄，也許能幫助一些人。我做的大概介面是如下圖。呵呵，上面這些都是些預備工作。下面正式開發。以上就是工程上設定。下面具體 以下處理sina的相關 以下是處理sina的授權驗證函式，qq的未寫。void removeauthdata bool islogg...
新浪微博授權
一.建立應用 2.進入我的應用 3.建立應用 二.oauth的授權流程 你所開發的應用需要的流程如下 2.得到request token後重定向使用者到服務商的授權頁面 3.如果使用者選擇授權你的應用，用request token向服務商請求換取access token 4.得到access tok...