騰訊周小軍：十個人管理1萬多臺 NoSQL 儲存伺服器的祕密
周小軍
騰訊高階運維工程師，目前在騰訊社交網路事業部負責社交業務海量NoSQL叢集運維和團隊管理。曾在天涯社群任運維副總監，負責天涯整體運維。對網際網路網站架構、資料中心、雲端計算及自動化運維等領域有深入研究和理解，積累了十多年的IT運維管理經驗。希望窮盡一生來深入鑽研運維領域。
主題簡介
騰訊目前有三大NoSQL分散式儲存系統，分別是：
- Grocery，主要支撐QQ業務，包括關係鏈、群、圈子、訊息等
- CKV，主要支撐QQ空間、騰訊雲、相簿、音樂和廣點通等
- Quorum_KV，主要支撐微信業務，包括訊息、朋友圈等產品
我們是SNG（騰訊社交網路事業部）社交網路運營部平臺技術運營中心下的資料運維團隊。團隊主要負責CKV和Grocery二大NoSQL分散式儲存叢集的運營。目前團隊有十幾名工程師，負責一萬幾千臺儲存伺服器。主要部署在深圳、天津、上海和廣州等大區域。
儲存伺服器劃分為幾十個SET（倉庫）叢集，共有幾百TB的記憶體和SSD儲存容量，服務於QQ、朋友網、QQ空間、相簿、廣點通、微雲、音樂等各類網際網路核心業務。
部署模式
NoSQL叢集按SET的方式部署，SET也稱之為“倉庫”。一個SET是一個物理單元。倉庫內至少擁有四種伺服器角色：
- 接入機（代理伺服器）
- 儲存機（主機+備機）
- 倉庫管理機
- 搬遷機器
每個SET可部署為跨機架、跨IDC、跨城容災。一個SET就是一個永不停服、永不丟資料的獨立的，標準化的服務單元，類似於標準化集裝箱。我們最大的SET機器部署數量不會超過上千臺，超大的SET會加大管理成本。
在騰訊的海量服務運營模型中，SET是一個非常重要的概念。接入層、邏輯層和資料層均按SET單元化來部署
天津大爆炸2億使用者跨省大排程
8月12日發生在天津的特大爆炸事故中，騰訊天津資料中心距爆炸現場才1-2公里。當時天津資料中心高危，現場數名工程師受傷，市電隨時可能中斷，柴電只能支援不到一天。8月13日我們啟動了大排程，把天津所容納的二億多華北活躍使用者全部排程回深圳和上海。排程過程QQ使用者無感知（從那幾天IT業界的新聞來看，外界對這一大事件毫無知曉）。
這應該是中國網際網路史上最大規模的一次排程。排程的成功受益於SET化的管理，受益於資料SET的三地同步
同步是怎麼做的呢？
業務資料按倉庫為單元，在全國各地IDC部署幾個異地倉庫，通過資料流水來實現各異地倉庫間資料同步和一致性保證。當某一城市的IDC災難性故障時，業務能迅速切到其他城市IDC恢復資料的讀寫，實現業務柔性可用，保證業務服務的持續性。資料的同步由同步中心負責，業務寫入同步中心，由各地的倉庫同步服務，從同步中心中讀取資料，並寫入本地倉庫。
技術特點
- 低成本：利用資料冷熱自動分離技術，將熱資料儲存在記憶體，冷資料儲存在SSD中，從而大幅度降低成本，且保證20%以內的資料儲存在記憶體中。
- 可擴充套件性強：表儲存空間可以線上自動無損伸縮，業務基本無感知，適合各種規模的業務，和業務的各個生命週期。
- 高效能：單表最大支援千萬次/秒的訪問。通過網路訪問的延時1ms左右。單臺儲存伺服器千兆網路環境支援50萬/秒的訪問，萬兆網路環境支援超過100萬/秒的訪問。
- 可用性超過99.95%：軟硬體全冗餘設計，雙機熱備，主備切換對業務透明，跨機架跨交換機部署。
- 資料永續性超過8個9：資料落磁碟儲存，多記憶體和磁碟副本，具有災難時回檔能力。
高可用架構
經過幾年的不斷打磨及優化，我們NoSQL分散式叢集的架構已經非常的成熟，主要有以下幾個特點：
- 高可靠：主備冗餘，故障自動切換機制來解決單點問題，當主機故障時自動切換到備機。同時後臺排程系統啟動搬遷服務，把單點的備機資料搬遷到倉庫裡空閒的資源池。
- 異地容災：多地部署，單IDC、甚至單個城市災難時，服務持續可用；
- 強一致性：主提供讀寫，備容災，保證資料強一致性；主故障時自動只讀，使用者切到備機後恢復讀寫，確保在單機故障時資料零丟失；
- 倉庫叢集機制：標準化部署，容量伸縮自動化，資料服務能力自動適配業務增長或衰退，保持對外服務的持續可用。
資料即服務的運營理念
資料中心由計算、儲存、傳輸三大要素構成，IaaS服務提出了把傳統資料中心的CPU，記憶體，網路和儲存等轉變為資源的目標，為業務提供計算資源的池化及智慧排程管理。對於資料層我們的目標則是DaaS，把資料做為服務提供給使用者。
構建可伸縮的分散式資料庫
我們的分散式資料庫把儲存資源池化，把記憶體儲存塊及磁碟儲存塊做為資源，放在一個儲存大池子裡按照較固定的儲存單元進行管理，並在其之上部署儲存智慧排程系統。
因此，我們的上萬臺儲存伺服器已經是真正意義上，具備動態伸縮能力的分散式資料庫：
- 業務使用資料容量最小為1GB，最大為10TB
- 記憶體儲存從1GB擴容到多機的100GB在分鐘級線上完成，擴容過程業務無感知無損
- 業務保持可用率4個9，延遲2ms
- 擴容過程不需要工程師跟蹤
我們的資料管理集中化，在資料複雜度以及資料量不斷增長的情況下，資料運維能夠支撐多變的業務需求。
運維即服務，資料即服務
在DaaS中，我們已經落地實施了以下幾點：
- 業務自助接入服務：業務申請、建立業務ID、自動建立表空間、自動下線，貫穿整個業務的生命週期。
- 機器部署：採用基礎運維平臺，包括包安裝，一鍵上架等自動化部署。支援跨機架部署。
- 彈性伸縮：一是儲存代理的彈性；二是儲存分配空間的彈性，根據業務儲存使用率自動擴縮容。
- 水位排程：業務流量在接入叢集間自動流動，儲存塊在儲存叢集間自動流動。
- 使用者報表：全方位的訪問趨勢、儲存趨勢、資料冷熱分佈、接入機分佈、儲存機分佈、主機當前負載等業務儲存資料。
- 多協議支援：支援私有協議、Redis協議和Memcache協議。
- 成本分攤：按請求量和儲存量進行月度財務核算，便於對使用者成本透明。
成本優化策略
上萬臺儲存叢集的成本優化是運營中比較核心的目標之一，我們在成本上的措施主要為：
- 用訪問密度做為可度量的成本指標，按每單位GB的訪問量來衡量業務接入的合理性。
- 資料密度，由於資料塊是由固定長度的Block組成的。使用者記錄的不定長會造成儲存塊碎片嚴重。所以我們通過定期的碎片整理來實現儲存塊的高效使用，碎片少，提升有效儲存空間。
- 分層儲存，熱KEY儲存在記憶體，冷KEY下沉到SSD硬碟。按通常的八二冷熱資料比例，我們可以節省大量的記憶體伺服器。
- 備機複用，為保證資料的強一致性，我們的儲存主機提供讀寫服務，備機只提供資料流水落地，不提供服務。因此我們在備機上部署容器，滿足公司離線計算或長尾業務對計算資源的需求。
運營團隊的工作本質
研發和DBA的關係就如同一輛車，我們造好一輛車，寫好說明手冊，而DBA則負責調教和維護這輛車，讓它能發揮最高的效能，坐得最舒服
—MySQL研發團隊成員賴錚
的確，我們運營團隊也是類似，與研發團隊一起把原始的資料庫引擎打磨得更易於運維、效能更高及對業務更多的特性支援，發揮工匠精神，不斷在成本、安全、質量和效率上追求極致。
除了研發團隊，運維團隊本身也是開發&運維相結合的團隊，團隊內有開發和運維二種角色：
開發工程師：負責持續整合環境、流程引擎、介面、程式碼稽核等工作。
運維工程師：負責上到產品經理，下到任務粒度級的開發等職責。
運維強大的工具平臺具備了功能豐富的API介面，譬如身份驗證、流程引擎、CMDB介面、監控介面、日誌上報、包安裝介面等功能，極大地提高了運維工程師工具開發效率。