嘉賓介紹

周小軍，　騰訊高級運維工程師，目前在騰訊社交網絡事業部負責社交業務海量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單元化來部署。一個業務譬如QQ音樂可能接入層和邏輯層各有十幾個SET，數據層有幾個SET。SET分別部署到不同的區域。每個SET都能容納一定數量的在線用戶(譬如500萬在線用戶)。

天津大爆炸2億用戶跨省大調度

8月12日發生在天津的特大爆炸事故中，騰訊天津數據中心距爆炸現場才1-2公里。當時天津數據中心高危，現場數名工程師受傷，市電隨時可能中斷，柴電只能支持不到一天。8月13日我們啟動了大調度，把天津所容納的二億多華北活躍用戶全部調度回深圳和上海。調度過程QQ用戶無感知(從那幾天IT業界的新聞來看，外界對這一大事件毫無知曉)。

這應該是中國互聯網史上最大規模的一次調度。調度的成功受益于SET化的管理，受益于數據SET的三地同步。

同步是怎么做的呢?

業務數據按倉庫為單元，在全國各地IDC部署幾個異地倉庫，通過數據流水來實現各異地倉庫間數據同步和一致性保證。當某一城市的IDC災難性故障時，業務能迅速切到其他城市IDC恢復數據的讀寫，實現業務柔性可用，保證業務服務的持續性。數據的同步由同步中心負責，業務寫入同步中心，由各地的倉庫同步服務，從同步中心中讀取數據，并寫入本地倉庫。

技術特點

1.低成本：利用數據冷熱自動分離技術，將熱數據存儲在內存，冷數據存儲在SSD中，從而大幅度降低成本，且保證20%以內的數據保存在內存中。

2.可擴展性強：表存儲空間可以在線自動無損伸縮，業務基本無感知，適合各種規模的業務，和業務的各個生命周期。

3.高性能：單表最大支持千萬次/秒的訪問。通過網絡訪問的延時1ms左右。單臺存儲服務器千兆網絡環境支持50萬/秒的訪問，萬兆網絡環境支持超過100萬/秒的訪問。

4.可用性超過99.95%：軟硬件全冗余設計，雙機熱備，主備切換對業務透明，跨機架跨交換機部署。

5.數據持久性超過8個9：數據落磁盤存儲，多內存和磁盤副本，具有災難時回檔能力。

高可用架構

經過幾年的不斷打磨及優化，我們NoSQL分布式集群的架構已經非常的成熟，主要有以下幾個特點：

1.高可靠：主備冗余，故障自動切換機制來解決單點問題，當主機故障時自動切換到備機。同時后臺調度系統啟動搬遷服務，把單點的備機數據搬遷到倉庫里空閑的資源池。

2.異地容災：多地部署，單IDC、甚至單個城市災難時，服務持續可用。

3.強一致性：主提供讀寫，備容災，保證數據強一致性;主故障時自動只讀，用戶切到備機后恢復讀寫，確保在單機故障時數據零丟失。

4.倉庫集群機制：標準化部署，容量伸縮自動化，數據服務能力自動適配業務增長或衰退，保持對外服務的持續可用。

數據即服務的運營理念

數據中心由計算、存儲、傳輸三大要素構成，IaaS服務提出了把傳統數據中心的CPU，內存，網絡和存儲等轉變為資源的目標，為業務提供計算資源的池化及智能調度管理。對于數據層我們的目標則是DaaS，把數據做為服務提供給用戶。

構建可伸縮的分布式數據庫

我們的分布式數據庫把存儲資源池化，把內存存儲塊及磁盤存儲塊做為資源，放在一個存儲大池子里按照較固定的存儲單元進行管理，并在其之上部署存儲智能調度系統。

因此，我們的上萬臺存儲服務器已經是真正意義上，具備動態伸縮能力的分布式數據庫：

◆業務使用數據容量最小為1GB，最大為10TB。

◆內存存儲從1GB擴容到多機的100GB在分鐘級在線完成，擴容過程業務無感知無損。

◆業務保持可用率4個9，延遲2ms。

◆擴容過程不需要工程師跟蹤。

我們的數據管理集中化，在數據復雜度以及數據量不斷增長的情況下，數據運維能夠支撐多變的業務需求。

運維即服務，數據即服務

在DaaS中，我們已經落地實施了以下幾點：

1.業務自助接入服務：業務申請、創建業務ID、自動創建表空間、自動下線，貫穿整個業務的生命周期。

2.機器部署：采用基礎運維平臺，包括包安裝，一鍵上架等自動化部署。支持跨機架部署。

3.彈性伸縮：一是存儲代理的彈性;二是存儲分配空間的彈性，根據業務存儲使用率自動擴縮容。

4.水位調度：業務流量在接入集群間自動流動，存儲塊在存儲集群間自動流動。

5.用戶報表：全方位的訪問趨勢、存儲趨勢、數據冷熱分布、接入機分布、存儲機分布、主機當前負載等業務存儲數據。

6.多協議支持：支持私有協議、Redis協議和Memcache協議。

7.成本分攤：按請求量和存儲量進行月度財務核算，便于對用戶成本透明。

成本優化策略

上萬臺存儲集群的成本優化是運營中比較核心的目標之一，我們在成本上的措施主要為：

1.用訪問密度做為可度量的成本指標，按每單位GB的訪問量來衡量業務接入的合理性。

2.數據密度，由于數據塊是由固定長度的Block組成的。用戶記錄的不定長會造成存儲塊碎片嚴重。所以我們通過定期的碎片整理來實現存儲塊的高效使用，碎片少，提升有效存儲空間。

3.分層存儲，熱KEY保存在內存，冷KEY下沉到SSD硬盤。按通常的八二冷熱數據比例，我們可以節省大量的內存服務器。

4.備機復用，為保證數據的強一致性，我們的存儲主機提供讀寫服務，備機只提供數據流水落地，不提供服務。因此我們在備機上部署容器，滿足公司離線計算或長尾業務對計算資源的需求。

運營團隊的工作本質

研發和DBA的關系就如同一輛車，我們造好一輛車，寫好說明手冊，而DBA則負責調教和維護這輛車，讓它能發揮最高的性能，坐得最舒服。

—MySQL研發團隊成員賴錚

的確，我們運營團隊也是類似，與研發團隊一起把原始的數據庫引擎打磨得更易于運維、性能更高及對業務更多的特性支持，發揮工匠精神，不斷在成本、安全、質量和效率上追求極致。

除了研發團隊，運維團隊本身也是開發&運維相結合的團隊，團隊內有開發和運維二種角色：

◆開發工程師：負責持續集成環境、流程引擎、接口、代碼審核等工作。

◆運維工程師：負責上到產品經理，下到任務粒度級的開發等職責。

運維強大的工具平臺具備了功能豐富的API接口，譬如身份驗證、流程引擎、CMDB接口、監控接口、日志上報、包安裝接口等功能，極大地提高了運維工程師工具開發效率。

如何一起愉快地發展

“高效運維”公眾號(如下二維碼)值得您的關注，作為高效運維系列微信群(國內領先的運維垂直社區)的唯一官方公眾號，每周發表多篇干貨滿滿的原創好文：來自于系列群的討論精華、運維講壇精彩分享及群友原創等。“高效運維”也是互聯網專欄《高效運維最佳實踐》及運維2.0官方公眾號。

重要提示：除非事先獲得授權，請在本公眾號發布2天后，才能轉載本文。尊重知識，請必須全文轉載，并包括本行及如下二維碼。

【編輯推薦】