帖子中心，是互聯網業務中，一類典型的“1對多”業務，即：一個用戶能發布多個帖子，一個帖子只有一個發布者。

隨著數據量的逐步增大，并發量的逐步增大，帖子中心這種“1對多”業務，架構應該如何設計，有哪些因素需要考慮，是本文將要系統性討論的問題。

[[335476]]

什么是x對x?

所謂的“1對1”，“1對多”，“多對多”，來自數據庫設計中的“實體-關系”ER模型，用來描述實體之間的映射關系。

什么是“1對1”業務?

用戶中心，一個用戶只有一個登錄名，一個登錄名只對應一個用戶，這是典型的1對1業務。

什么是“1對多”業務?

帖子中心，一個用戶可以發多條微博，一條微博只有一個發送者，這是典型的1對多業務。

什么是“多對多”業務?

feed關注，一個用戶可以關注多個用戶，一個用戶也可以被多個用戶關注，這是典型的多對多業務。

帖子中心是個什么業務，有什么典型的業務需求?

帖子中心是一個典型的1對多業務。

一個用戶可以發布多個帖子，一個帖子只對應一個發布者。

任何脫離業務的架構設計都是耍流氓，先來看看帖子中心對應的業務需求。

帖子中心，是一個提供帖子發布，修改，刪除，查看，搜索的服務。

帖子中心，有什么寫操作?

• 發布(insert)帖子;
• 修改(update)帖子;
• 刪除(delete)帖子;

帖子中心，有什么讀操作?

• 通過tid查詢(select)帖子實體，單行查詢;
• 通過uid查詢(select)用戶發布過的帖子，列表查詢;
• 帖子檢索(search)，例如通過時間、標題、內容搜索符合條件的帖子;

在數據量較大，并發量較大的時候，架構如何設計?

典型的，通常通過元數據與索引數據分離的架構設計方法。

架構中的幾個關鍵點，如上圖所示：

• tiezi-center：帖子服務;
• tiezi-db：提供元數據存儲;
• tiezi-search：帖子搜索服務;
• tiezi-index：提供索引數據存儲;
• MQ：tiezi-center與tiezi-search通訊媒介，一般不直接使用RPC調用，而是通過MQ對兩個子系統解耦。

此時，讀需求怎么滿足?

tiezi-center和tiezi-search分別滿足兩類不同的讀需求。

如上圖所示：

• tid和uid上的查詢需求，可以由tiezi-center從元數據讀取并返回;
• 其他類檢索需求，可以由tiezi-search從索引數據檢索并返回;

寫需求怎么辦呢?

至于寫需求，如上圖所示：

• 增加，修改，刪除的操作都會從tiezi-center發起;
• tiezi-center修改元數據;
• tiezi-center將信息修改通知發送給MQ;
• tiezi-search從MQ接受修改信息;
• tiezi-search修改索引數據;

tiezi-search，搜索架構不是本文的重點，不再展開，后文將重點描述帖子中心元數據水平切分設計。

帖子中心，數據庫元數據如何設計?

帖子中心業務，很容易了解到，其核心元數據為：

t_tiezi(tid, uid, time, title, content, …); 

其中：

• tid為帖子ID，主鍵;
• uid為用戶ID，發帖人;
• time, title, content …等為帖子屬性;

數據庫設計上，在業務初期，單庫就能滿足元數據存儲要求。

• tiezi-center：帖子中心服務，對調用者提供友好的RPC接口;
• tiezi-db：對帖子數據進行存儲;

在相關字段上建立索引，就能滿足相關業務需求。

• 帖子記錄查詢，通過tid查詢，約占讀請求量90%;

select * from t_tiezi where tid=$tid 

• 帖子列表查詢，通過uid查詢其發布的所有帖子，約占讀請求量10%;

select * from t_tiezi where uid=$uid 

隨著數據量越來越大，如何進行水平切分，對存儲容量進行線性擴展呢?

方案一：帖子ID切分法

既然是帖子中心，并且帖子記錄查詢量占了總請求的90%，很容易想到通過tid字段取模來進行水平切分。

這個方法簡單直接，優點：

• 100%寫請求可以直接定位到庫;
• 90%的讀請求可以直接定位到庫;

缺點也很明顯：

一個用戶發布的所有帖子可能會落到不同的庫上，10%的請求通過uid來查詢會比較麻煩;

如上圖，一個uid訪問需要遍歷所有庫。

有沒有一種切分方法，確保同一個用戶發布的所有帖子都落在同一個庫上，而在查詢一個用戶發布的所有帖子時，不需要去遍歷所有的庫呢?

方案二：用戶ID切分法

使用uid來分庫可以解決這個問題。

新的問題出現了：如果使用uid來分庫，確保了一個用戶的帖子數據落在同一個庫上，那通過tid來查詢，就不知道這個帖子落在哪個庫上了，豈不是還需要遍歷全庫，需要怎么優化呢?

tid的查詢是單行記錄查詢，只要在數據庫(或者緩存)記錄tid到uid的映射關系，就能解決這個問題。

新增一個索引庫：

t_mapping(tid, uid); 

• 這個庫只有兩列，可以承載很多數據;
• 即使數據量過大，索引庫可以利用tid水平切分;
• 這類kv形式的索引結構，可以很好的利用cache優化查詢性能;
• 一旦帖子發布，tid和uid的映射關系就不會發生變化，cache的命中率會非常高;

使用uid分庫，并增加索引庫記錄tid到uid的映射關系之后，每當有uid上的查詢，可以通過uid直接定位到庫。

每當有tid上的查詢，可以先查mapping表得到uid，再通過uid定位到庫。

這個方法的優點是：

• 一個用戶發布的所以帖子落在同一個庫上;
• 10%的請求過過uid來查詢列表，可以直接定位到庫;
• 索引表cache命中率非常高，因為tid與uid的映射關系不會變;

缺點也很明顯：

• 90%的tid請求，以及100%的修改請求，不能直接定位到庫，需要先進行一次索引表的查詢，當然這個查詢非常塊，通常在5ms內可以返回;
• 數據插入時需要操作元數據與索引表，可能引發潛在的一致性問題;

有沒有一種方法，既能夠通過uid定位到庫，又不需要建立索引表來進行二次查詢呢，使得uid和tid都能夠直接一次命中的方案呢?

方案三：基因法

(1) 什么是分庫基因?

通過uid分庫，假設分為16個庫，采用uid%16的方式來進行數據庫路由，這里的uid%16，其本質是uid的最后4個bit決定這行數據落在哪個庫上，這4個bit，就是分庫基因。

(2) 什么是基因法分庫?

在“1對多”的業務場景，使用“1”分庫，在“多”的數據id生成時，id末端加入分庫基因，就能同時滿足“1”和“多”的分庫查詢需求。

如上圖所示，uid=666的用戶發布了一條帖子(666的二進制表示為：1010011010)：

• 使用uid%16分庫，決定這行數據要插入到哪個庫中;
• 分庫基因是uid的最后4個bit，即1010;
• 在生成tid時，先使用一種分布式ID生成算法生成前60bit(上圖中綠色部分);
• 將分庫基因加入到tid的最后4個bit(上圖中粉色部分);
• 拼裝成最終的64bit帖子tid(上圖中藍色部分);

這般，保證了同一個用戶發布的所有帖子的tid，都落在同一個庫上，tid的最后4個bit都相同，于是：

• 通過uid%16能夠定位到庫;
• 通過tid%16也能定位到庫;

有人要問了，同一個uid發布的tid落在同一個庫上，會不會出現數據不均衡?

只要uid是均衡的，每個用戶發布的平均帖子數是均衡的，每個庫的數據就是均衡的。

又有人要問了，最開始分16庫，分庫基因是4bit，未來要擴充成32庫，分庫基因變成了5bit，那怎么辦?

需要提前做好容量預估，例如事先規劃好5年內數據增長256庫足夠，就提前預留8bit基因。

總結

將以“帖子中心”為典型的“1對多”類業務，在架構上，采用元數據與索引數據分離的架構設計方法：

• 帖子服務，元數據滿足uid和tid的查詢需求;
• 搜索服務，索引數據滿足復雜搜索尋求;

對于元數據的存儲，在數據量較大的情況下，有三種常見的切分方法：

• tid切分法，按照tid分庫，同一個用戶發布的帖子落在不同的庫上，通過uid來查詢要遍歷所有庫;
• uid切分法，按照uid分庫，同一個用戶發布的帖子落在同一個庫上，需要通過索引表或者緩存來記錄tid與uid的映射關系，通過tid來查詢時，先查到uid，再通過uid定位庫;
• 基因法，按照uid分庫，在生成tid里加入uid上的分庫基因，保證通過uid和tid都能直接定位到庫;

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文