談談KV存儲集羣的設計要點

版權聲明：本文由廖念波原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/150

來源：騰雲閣 https://www.qcloud.com/community

 

Key-value存儲系統，是很是廣泛的需求，幾乎每一個在線的互聯網後臺服務都須要KV存儲，咱們團隊在KV存儲方面，經歷過幾個時期，我本身深感要作好不容易。

這裏扯遠一點，展開說一下：

第一個時期，很早期的時候，咱們的數據存儲在mysql表裏，按照用戶帳號簡單的分庫分表，爲了保證訪問高併發，利用每一個mysql服務器的內存作數據緩存；主備兩套分佈在不一樣IDC，業務邏輯本身作副本同步。當時主要的問題是：內存的數據結構擴展困難、運維工做瑣碎、數據同步機制自己的缺陷致使不能作異地IDC部署，這些缺點對於業務飛速發展、一地機房已經不夠用的局面很是被動

第二個時期，咱們設計了新的KV存儲系統，其用戶數據結構容易擴展、具有能夠多地部署的數據同步機制，很好的應對了新時期業務發展的須要。爲了設備成本考慮，咱們把數據作冷熱分離，訪問頻繁的數據會加載到專門的cache層，且對於不一樣的訪問模型，掛載不一樣架構的cache，另一個file層專門作數據持久化。這樣的設計，使得架構太複雜，bug收斂速度慢，運維工做相比之前甚至更復雜了。

第三個時期，爲了應對廣泛的KV存儲需求，咱們以公共組件的形式從新設計了KV存儲，做爲團隊標準的組件之一，獲得了大規模的應用。結合同期抽象出來的邏輯層框架、路由管理等其餘組件，團隊的公共基礎組件和運維設施建設的比較完備了，整個業務的開發和運維實現了標準化。但這個階段就用了咱們團隊足足2年多時間。

不一樣於無數據的邏輯層框架，KV存儲系統的架構設計會更復雜、運維工做更繁瑣、運營過程當中可能出現的情況更多、bug收斂時間會更長。一句話：團隊本身作一個KV存儲系統是成本很高的，並且也有比較高的技術門檻。

設計一個KV存儲，須要考慮至少這些方面：

1. 如何組織機器的存儲介質，一般是內存、磁盤文件；例如用hash的方式組織內存

2. 如何設計用戶的數據結構，使得通用、易於擴展、存儲利用率高；例如PB序列化、Json、XML方式

3. 友好的訪問接口，而不僅是get / set一整個value

4. 如何作集羣分佈、如何sharding、如何作到方便的擴縮容；例如一致性hash算法

5. 如何作數據冗餘、副本間如何同步、一致性問題；副本間如何選舉master

6. 備份與恢復、數據校驗與容錯

7. 讀寫性能

8. 其餘可能的特殊需求：例如咱們設計過一個KV存儲，用於存儲一些公衆號的個數不受限粉絲列表

上面八點，業內的KV存儲組件通常都會考慮到，或者各有特點，各自優點在伯仲之間。可是綜合過去的經驗教訓，咱們以爲有一點很容易被忽視：可運維性、運維自動化、黑盒化運維。

舉一個例子，前面提到的咱們第二個時期的KV存儲系統，剛開始應用的時候，一次擴容過程會有10多步的運維操做，包括load數據、作增量同步、屢次修改機器狀態、數據比對等等，須要運維同事以高度的責任心來完成。另外就是運維同事必須如該KV存儲架構設計者同樣深入理解系統背後的原理和細節，不然就不能很好的執行運維操做，這個要求也很是高，新老交接週期長，還容易出運維事故。

基於上面的考慮，同事爲了讓用戶更容易學習和接受，毫秒服務引擎在redis cluster的基礎上，實現了運維web化，並加上了集羣的監控。

毫秒服務引擎(msec, 取英文名Mass Service Engine in Cluster的首字母組合)是騰訊一個開源框架，其創做衝動和構建經驗，來自QQ後臺團隊超過10年的運營思考。官網:

毫秒引擎能夠經過web界面方便的進行：

1. 集羣概要狀態查看
   

2. 能夠在web上方便的完成平常的運維操做：新搭集羣、擴縮容、故障機器的恢復：
   

3. 請求量、內存使用、cpu等各類狀態信息可直觀監控，也能夠按IP粒度查看
   

限於篇幅和時間限制，詳細的可見騰訊雲服務市場、毫秒服務引擎官網，或者微信公衆號:msec-engine