以朋友圈為例，騰訊資深架構師揭秘鵝廠大資料平臺是怎樣運營的

作者：熊普江

2015年7月22日，微信朋友圈圖片顯示出現了“清帳”問題：即圖片都不能正常顯示，取而代之的是顯示一個粉色圖片，上面列有「清賬」兩字。雖然故障持續的時間只有短短幾分鐘，但影響面卻十分之廣，引發各種猜想。著名自媒體作者Fenng在公眾號“小道訊息”文章《微信居然也會缺少伺服器資源，你信麼？》也提出該問題的討論。

問題產生的原因確認是少數伺服器升級所致，但也反映出裝置資源對業務的支撐十分重要，而且運營的精細化還沒有做得足夠好。如何保障業務發展需要，保障使用者體驗，同時又充分利用好資源，控制好運營成本，是裝置資源精細技術運營需要持續探索的關鍵。

01 裝置資源精細化技術運營要點

裝置資源精細化技術運營的方法論與要點。這裡簡要回顧一下：

第一步：明確業務執行時的主要裝置資源瓶頸所在

第二步：使用價效比最合適的伺服器硬體機型來適配

第三步：從以下精細化技術運營評估點上逐個檢查評估：

• 是否可減少不合理/不必要的呼叫請求量

• 是否可最佳化減少呼叫層級或減少呼叫放大

• 分配到伺服器上的呼叫請求是否均勻

• 是否可使用快取減少後端資料層的儲存訪問

• 架構上是否使用了非同步呼叫或協程訪問

• 網路協議是否恰當

• 網路收發包量是否合理

• 作業系統或核心引數是否已做最佳化

• 資料儲存的內容、格式/編碼、份數是否合理

• 資料訪問是否存在冷熱

第四步：從管理策略與措施上進行提升，包括：

• 是否可使用新服務區或長尾服務區進行業務新上線或下線管理

• 容災備份系統或區域可否用於跑離線業務

• 資源供給能力是否可進一步提升，降低容量的水位線

我們將透過多個業務實際案例來闡述上述裝置資源精細化技術最佳化的應用。

02 微信訊息

微信收發訊息是微信產品的核心業務，也是使用裝置資源量的頭部業務，因此對該業務功能的技術運營，具有重要價值。我們主要針對三個方面精細化：呼叫關係複雜、請求分佈不均，資源使用瓶頸不一。

1. 呼叫關係複雜

為什麼說呼叫關係非常複雜？微信訊息收發分為兩種情形，單聊與群聊。單聊指的是使用者A和使用者B之間發訊息，群聊是單使用者在群裡面對N個使用者發訊息。我們看相對簡單的收發單聊訊息過程（見下圖）。

▲微信單聊訊息傳送微模組

單聊實際上有9個以上的步驟：發一條訊息，系統在後臺處理要處理9次以上。訊息連線接入，傳送訊息的邏輯模組，邏輯模組之後鑒權（帳號存在與否、帳號屬性是否正常）、安全檢查（是否垃圾、是否有害等）、收訊息人檢查（通訊地址本）、生成訊息序列號（確認不丟訊息及訊息有序拉取）、儲存訊息體、傳送訊息通知、收取新訊息等。可見呼叫關係是非常複雜的。

因此，我們針對複雜的呼叫關係邏輯進行了最佳化，包括：調整RPC介面與後臺資料儲存，合併RPC呼叫；減少呼叫層次，縮減模組；邏輯層引入強一致性快取，減少account/attr等模組持久資料的RPC訪問；分離冷熱資料，減少對冷資料的RPC訪問等等。這些精細技術最佳化在2014年實施時，節省的裝置量超過400臺。

2. 請求分佈不均

微信訊息是多機叢集處理的，如果負載不均的話，有些機器達到瓶頸時，有些機卻還很空，需要將請求均衡的分佈到機器上面。例如：訊息的KV儲存由按分號段儲存改為一致性hash，使得每機效能更均勻：原來是按號段儲存每機的負載很不均勻，而擴容是按最大負載的機器去擴容的；有些服務是序列處理的，例如最佳化容災架構，使用非同步佇列進行IO最佳化。這些精細的技術最佳化在2014年節省裝置近500臺。

3. 資源使用瓶頸不一

訊息業務的每個key都放記憶體，海量key致使需多臺伺服器來存放資料，顯然這些伺服器的資源瓶頸在記憶體上；適當將冷資料的key落地到磁碟上，可以縮小記憶體容量；同時考慮零散碎小模組可以合併一起，使資源充分使用；而合併在一起儲存，就需要技術方法解決某個業務突變引起擴容。

另外，有些業務模組則資源瓶頸的CPU或磁碟儲存上，甚至在不同的時間消耗的資源量不同，可以考慮資源混合與錯峰排程。

解決資源使用瓶頸及錯峰排程，2014年微信最佳化中節省伺服器超過250臺。

4. 其他的最佳化措施

作業系統最佳化及RPC框架效能改進。如原來微信伺服器的作業系統層面單機效能比較差，每臺機器只能處理不到100萬左右的訊息呼叫量，使用tlinux大幅將單機效能提升到近200萬。微信單機效能改進的最佳化於2014年中節省裝置超過3000臺。

伺服器的容量管理，最佳化容量水位，提升快速擴縮容能力。

新業務服務區及長尾服務區的管理最佳化。設定業務進入或遷出新服務區或長尾服務區的請求呼叫量閥值標準。

03 朋友圈

朋友圈是微信裡最為重要功能之一，幫助使用者向好友展示自己的想法與最近狀況，同時便於使用者瞭解好友的狀態、評論或點贊。朋友圈與收藏很相似，使用者資料也是永久儲存，不會刪除。

朋友圈的產品形態很特別。細心的讀者會發現，使用者發一條朋友圈，實際上是先在使用者自己個人相簿裡面存一條記錄資料；但同時會往該時刻、允許檢視其朋友圈且未遮蔽該使用者的好友時間線上插一條索引資料。

▲朋友圈時間線與個人相簿

也就是說朋友圈有兩個功能點：

• 看所有自己發的朋友圈記錄，就是個人相簿，儲存了自第1條朋友圈以來的所有朋友圈訊息記錄。訪問的頻率相對不高，但這部分儲存資料，使用者一般很少刪除，它是持續增長的，這個儲存量是巨大的。

• 我們平時刷朋友圈，即朋友圈資訊流，按時間倒序，列出某個時刻，好友發了一條狀態資訊（文字、圖片、影片、圖文等），這就是時間線。只存放2000條索引記錄，儲存所需空間不會有太大變化，但使用者訪問頻率高，經常被掃清訪問。使用者如果要看2000條以外的好友朋友圈訊息，只能點開到某個好友的個人相簿才能看了。

朋友圈每天上傳圖片請求近10億次，上傳影片請求近1億次。資料訪問超過5000億次/天，單機峰值訪問超過120萬次/分鐘。為確保資料可靠性與良好體驗，會儲存多個規格及儲存份數。因此，朋友圈的儲存體量及訪問量是非常大的，而且是永久儲存，隨時間推移，只會增不會少。這就有一個問題，如果都使用高效能儲存來服務使用者的話，伺服器資源成本將會是天量。

技術運營團隊跟蹤運營資料發現，使用者看朋友圈的時候，訪問一天之內發的朋友圈內容，大約佔了70%，一天之外內容被訪問次數大幅減少，當前1天之內的朋友圈內容儲存量只佔總朋友圈儲存量的0.3%。90%以上的訪問請求的資料都在1個月以內，當前1個月之內的朋友圈內容儲存佔總朋友圈儲存量的6.5%。

也就是說，朋友圈業務呈現訪問量大、資料冷熱非常分明的特點。需要將考慮將資料分成熱資料叢集與冷資料叢集，而且基本可以確定，熱資料叢集的增長不會太明顯，增長主要在冷資料叢集上。熱資料叢集我們就用效能最好的裝置，讓大家可以很快速訪問到所需的內容與資料；冷資料叢集就使用價格低廉的多的大容量儲存裝置。從架構上，除要支援按時間序列進行冷熱資料的遷移轉換，還需要支援使用者訪問的轉換。最終重新最佳化實現新的朋友圈資料冷熱分離儲存架構，如下圖：

▲朋友圈冷熱分享架構示意圖

這裡的熱資料叢集，使用高效能SSD儲存機型TS8/TS80；冷資料叢集使用高儲存量的SATA儲存機型TS6/TS60。

其中TS8/80 使用SSD盤，作RAID5的情況下，最大儲存量為2.4T，極限隨機iops可達到50000次，TB訪問量可達到2w次/s。

TS6/TS60使用機械SATA盤，每臺機器12塊，單塊盤容量為2T，測試併發情況下極限iops不到200次。No Raid情況下總容量為24T，極限隨機iops為2000次。TB訪問量為100次/s。

單臺TS6/TS60硬體的成本約為TS8/TS80的70%。但定義TB儲存成本為每TB資料儲存對應的硬體價格，則可知在磁碟完全利用的情況下，TS6/TS60的TB儲存成本僅為TS8/TS80的7%。滿足iops要求，磁碟不能完全利用情況下，TS6的TB儲存成本為TS8的15%。也就是說，冷熱叢集的儲存成本，可節約85%的成本。

冷熱叢集架構上，還有很多細節的技術最佳化點：如滿足時間序列的熱資料儲存結構最佳化（採用LSM Tree演演算法）；滿足冷資料平行擴容的冷資料儲存結構最佳化（採用單點序列寫入的一致性模型）等等。

04 大資料平臺管理

現在一般上規模的公司，都會建立公司統一的大資料平臺。騰訊也不例外，資料平臺部建有超大規模的資料處理叢集平臺TDW（Tencent distributed Data Warehouse：資料倉庫），包括實時計算、離線計算等等，用於全公司的資料實時處理、離線分析、個性化推薦、業務計費等。

由於移動網際網路的發展，資料呈現爆炸性增長，同樣騰訊的TDW叢集規模也迅猛增長。目前TDW單一叢集能力已達2萬臺。資料處理平臺的管理與利用，成為業務發展與成本最佳化管控的巨大挑戰。

大資料平臺的管理分為計算單元與儲存單元的管理。2016年以前，騰訊TDW叢集從CPU利用率上看，平均達85%。叢集儲存資料中，3個月內資料佔比56%，6個月內資料佔比70%，12個月以上佔比16%；叢集計算使用資料，73%為1個月內資料，92%為3個月內資料，12個月以上佔比約2%。

在精細化運營方面，技術運營團隊實施的措施有：

首先定義了沉默資料。沉默資料是指一定時間週期內未被訪問的資料。如2015年8月，騰訊TDW中3個月以上至1年的沉默資料有25PB，1年以上的沉默資料有14PB。

其次，技術運營團隊強化了資料儲存的生命週期管理。管理規定要求：所有業務申請接入TDW的資料時，都需要填報“資料儲存週期”。透過生命週期管理及沉默資料差異化儲存，2015年前8個月僅增長23%的儲存量（見下圖）。

▲資料平臺強化儲存生命週期管理

再次，透過監控大任務效率及清理無價值任務對計算單元進行最佳化。對於執行時間長、掃描資料量大的任務，實施主動監控並及時通知業務進行最佳化，必要時進行主動清理，確保平臺計算單元合理利用。在業務層面，清理兩類無價值任務：長期失敗任務與長期計算結果為空的任務（見下表）：

▲無價值任務說明

在2015年前8個月時間內，透過監控大任務效率及清理前兩類無價值任務（18398個），已最佳化計算單元超過800個（見下圖）。

▲清理無價值任務個數

對於計算單元的管理，除了無價值計算外，可以透過類似於域名管理的方法來監測計算任務的有效性。即：

• 業務每申請增加一個計算任務，需要註明：用途、有效期（預設為6個月或1年）、主要責任人（任務開發人）、次要責任人（產品或運維）。

• 任務到期前一個月或一週，提醒主要責任人renew（續期）或放棄（刪除）任務。

• 任務到期後一個月為贖回期，任務繼續執行，但每天提醒主要責任人及次要責任人。

• 任務過期一個月仍不續期，該任務將暫停執行。

• 任務過期3個月，該任務將物理刪除。

關於作者：熊普江，騰訊公司佈道師、騰訊雲高階總監，負責公司雲技術、解決方案佈道及技術架構評審等工作。自1997年涉足網際網路，曾服務美國Supreme、太平洋網路、PPTV等網際網路公司，任網路運營總監、運維總監等職務。逾20年網際網路從業背景，對大型網路架構規劃與建設、海量使用者平臺規劃與運營技術支援、超大規模業務資源規劃與技術架構管理最佳化有豐富的經驗。

本文摘編自《技術運營》，大資料（ID：hzdashuju）經出版方授權釋出，如需轉載聯絡我們。

延伸閱讀《技術運營》

點選上圖瞭解及購買

轉載請聯絡微信：togo-maruko

推薦語：由騰訊資深架構師熊普江攜手海爾電器集團CTO盛國軍共同打造！詳細闡述技術運營的精細化方法及具體實施步驟，披露大量真實案例！多位知名架構師聯袂推薦！