【轉】單KEY業務，資料庫水平切分架構實踐

標籤：phone   映射   img   資料存放區   獨立   uid   方式   資料   解決方案   

本文將以“使用者中心”為例，介紹“單KEY”類業務，隨著資料量的逐步增大，資料庫效能顯著降低，資料庫水平切分相關的架構實踐：

• 如何來實施水平切分
• 水平切分後常見的問題
• 典型問題的最佳化思路及實踐

一、使用者中心

使用者中心是一個非常常見的業務，主要提供使用者註冊、登入、資訊查詢與修改的服務，其核心中繼資料為：

      User(uid, login_name, passwd, sex, age, nickname, …)

其中：

• uid為使用者ID，主鍵
• login_name, passwd, sex, age, nickname, …等使用者屬性

資料庫設計上，一般來說在業務初期，單庫單表就能夠搞定這個需求，典型的架構設計為：

• user-center：使用者中心服務，對調用者提供友好的RPC介面
• user-db：對使用者進行資料存放區

 

二、使用者中心水平切分方法

當資料量越來越大時，需要對資料庫進行水平切分，常見的水平切分演算法有“範圍法”和“雜湊法”。

範圍法，以使用者中心的業務主鍵uid為劃分依據，將資料水平切分到兩個資料庫執行個體上去：

• user-db1：儲存0到1千萬的uid資料
• user-db2：儲存1到2千萬的uid資料

範圍法的優點是：

• 切分策略簡單，根據uid，按照範圍，user- center很快能夠定位到資料在哪個庫上
• 擴容簡單，如果容量不夠，只要增加user-db3即可

範圍法的不足是：

• uid必須要滿足遞增的特性
• 資料量不均，新增的user-db3，在初期的資料會比較少
• 請求量不均，一般來說，新註冊的使用者活躍度會比較高，故user-db2往往會比user-db1負載要高，導致伺服器利用率不平衡

雜湊法，也是以使用者中心的業務主鍵uid為劃分依據，將資料水平切分到兩個資料庫執行個體上去：

• user-db1：儲存uid模數得1的uid資料
• user-db2：儲存uid模數得0的uid資料

雜湊法的優點是：

• 切分策略簡單，根據uid，按照hash，user-center很快能夠定位到資料在哪個庫上
• 資料量均衡，只要uid是均勻的，資料在各個庫上的分布一定是均衡的
• 請求量均衡，只要uid是均勻的，負載在各個庫上的分布一定是均衡的

雜湊法的不足是：

• 擴容麻煩，如果容量不夠，要增加一個庫，重新hash可能會導致資料移轉，如何平滑的進行資料移轉，是一個需要解決的問題

 

三、使用者中心水平切分後帶來的問題

使用uid來進行水平切分之後，整個使用者中心的業務訪問會遇到什麼問題呢?

對於uid屬性上的查詢可以直接路由到庫，假設訪問uid=124的資料，模數後能夠直接定位db-user1：

對於非uid屬性上的查詢，例如login_name屬性上的查詢，就悲劇了：

假設訪問login_name=shenjian的資料，由於不知道資料落在哪個庫上，往往需要遍曆所有庫，當分庫數量多起來，效能會顯著降低。

如何解決分庫後，非uid屬性上的查詢問題，是後文要重點討論的內容。

 

四、使用者中心非uid屬性查詢需求分析

任何脫離業務的架構設計都是耍流氓，在進行架構討論之前，先來對業務進行簡要分析，看非uid屬性上有哪些查詢需求。

根據樓主這些年的架構經驗，使用者中心非uid屬性上經常有兩類業務需求：

(1)使用者側，前台訪問，最典型的有兩類需求

• 使用者登入：通過login_name/phone/email查詢使用者的實體，1%請求屬於這種類型
• 使用者資訊查詢：登入之後，通過uid來查詢使用者的執行個體，99%請求屬這種類型

使用者側的查詢基本上是單條記錄的查詢，訪問量較大，服務需要高可用，並且對一致性的要求較高。

(2)運營側，後台訪問，根據產品、運營需求，訪問模式各異，按照年齡、性別、頭像、登陸時間、註冊時間來進行查詢。

運營側的查詢基本上是批量分頁的查詢，由於是內部系統，訪問量很低，對可用性的要求不高，對一致性的要求也沒這麼嚴格。

這兩類不同的業務需求，應該使用什麼樣的架構方案來解決呢?

 

五、使用者中心水平切分架構思路

使用者中心在資料量較大的情況下，使用uid進行水平切分，對於非uid屬性上的查詢需求，架構設計的核心思路為：

• 針對使用者側，應該採用“建立非uid屬性到uid的映射關係”的架構方案
• 針對運營側，應該採用“前台與後台分離”的架構方案

 

六、使用者中心-使用者側最佳實務

【索引表法】

思路：uid能直接定位到庫，login_name不能直接定位到庫，如果通過login_name能查詢到uid，問題解決

解決方案：

• 建立一個索引表記錄login_name->uid的映射關係
• 用login_name來訪問時，先通過索引表查詢到uid，再定位相應的庫
• 索引表屬性較少，可以容納非常多資料，一般不需要分庫
• 如果資料量過大，可以通過login_name來分庫

潛在不足：多一次資料庫查詢，效能下降一倍

【緩衝映射法】

思路：訪問索引表效能較低，把映射關係放在緩衝裡效能更佳

解決方案：

• login_name查詢先到cache中查詢uid，再根據uid定位元據庫
• 假設cache miss，採用掃全庫法擷取login_name對應的uid，放入cache
• login_name到uid的映射關係不會變化，映射關係一旦放入緩衝，不會更改，無需淘汰，快取命中率超高
• 如果資料量過大，可以通過login_name進行cache水平切分

潛在不足：多一次cache查詢

【login_name產生uid】

思路：不進行遠程查詢，由login_name直接得到uid

解決方案：

• 在使用者註冊時，設計函數login_name產生uid，uid=f(login_name)，按uid分庫插入資料
• 用login_name來訪問時，先通過Function Compute出uid，即uid=f(login_name)再來一遍，由uid路由到對應庫

潛在不足：該函數設計需要非常講究技巧，有uid產生衝突風險

【login_name基因融入uid】

思路：不能用login_name產生uid，可以從login_name抽取“基因”，融入uid中

假設分8庫，採用uid%8路由，潛台詞是，uid的最後3個bit決定這條資料落在哪個庫上，這3個bit就是所謂的“基因”。

解決方案：

• 在使用者註冊時，設計函數login_name產生3bit基因，login_name_gene=f(login_name)，如粉色部分
• 同時，產生61bit的全域唯一id，作為使用者的標識，如綠色部分
• 接著把3bit的login_name_gene也作為uid的一部分，如屎黃色部分
• 產生64bit的uid，由id和login_name_gene拼裝而成，並按照uid分庫插入資料
• 用login_name來訪問時，先通過函數由login_name再次複原3bit基因，login_name_gene=f(login_name)，通過login_name_gene%8直接定位到庫

 

七、使用者中心-運營側最佳實務

前台使用者側，業務需求基本都是單行記錄的訪問，只要建立非uid屬性 login_name / phone / email 到uid的映射關係，就能解決問題。

後台運營側，業務需求各異，基本是批量分頁的訪問，這類訪問計算量較大，返回資料量較大，比較消耗資料庫效能。

如果此時前台業務和後台業務公用一批服務和一個資料庫，有可能導致，由於背景“少數幾個請求”的“批量查詢”的“低效”訪問，導致資料庫的cpu偶爾瞬時100%，影響前台正常使用者的訪問(例如，登入逾時)。

而且，為了滿足後台業務各類“奇形怪狀”的需求，往往會在資料庫上建立各種索引，這些索引佔用大量記憶體，會使得使用者側前台業務uid/login_name上的查詢效能與寫入效能大幅度降低，處理時間增長。

對於這一類業務，應該採用“前台與後台分離”的架構方案：

使用者側前台業務需求架構依然不變，產品運營側後台業務需求則抽取獨立的web / service / db 來支援，解除系統之間的耦合，對於“業務複雜”“並發量低”“無需高可用”“能接受一定延時”的後台業務：

• 可以去掉service層，在運營後台web層通過dao直接存取db
• 不需要反向 Proxy，不需要叢集冗餘
• 不需要訪問即時庫，可以通過MQ或者線下非同步同步資料
• 在資料庫非常大的情況下，可以使用更契合大量資料允許接受更高延時的“索引外置”或者“HIVE”的設計方案

 

八、總結

將以“使用者中心”為典型的“單KEY”類業務，水平切分的架構點，本文做了這樣一些介紹。

水平切分方式：

水平切分後碰到的問題：

• 通過uid屬性查詢能直接定位到庫，通過非uid屬性查詢不能定位到庫

非uid屬性查詢的典型業務：

• 使用者側，前台訪問，單條記錄的查詢，訪問量較大，服務需要高可用，並且對一致性的要求較高
• 運營側，後台訪問，根據產品、運營需求，訪問模式各異，基本上是批量分頁的查詢，由於是內部系統，訪問量很低，對可用性的要求不高，對一致性的要求也沒這麼嚴格

這兩類業務的架構設計思路：

使用者前台側，“建立非uid屬性到uid的映射關係”最佳實務：

• 索引表法：資料庫中記錄login_name->uid的映射關係
• 緩衝映射法：緩衝中記錄login_name->uid的映射關係
• login_name產生uid
• login_name基因融入uid

運營後台側，“前台與後台分離”最佳實務：

• 前台、後台系統web/service/db分離解耦，避免後台低效查詢引發前台查詢抖動
• 可以採用資料冗餘的設計方式
• 可以採用“外置索引”(例如ES搜尋系統)或者“大資料處理”(例如HIVE)來滿足後台變態的查詢需求

九、參考文檔

沈劍  架構師之路 公眾號

 

【轉】單KEY業務，資料庫水平切分架構實踐