作者 | 張冬洪

責編 | 仲培藝

【導語】?微博擁有超過3.76億月活用戶，是當前社會熱點事件傳播的主要平臺。而熱點事件往往具有不可預測性和突發性，較短時間內可能帶來流量的翻倍增長，甚至更大。如何快速應對突發流量的沖擊，確保線上服務的穩定性，對于提供全微博數據托管的服務部門數據庫團隊來說既是機遇又是挑戰。本文嘗試從一線DBA的視角管窺微博熱點事件背后的數據庫運維應對之道。

背景&挑戰

背景

正是圖1這條微博動態，讓一個平常的國慶假期變得不同尋常，微博剛一發出就引爆網絡，它將明星CP動態推向了輿論的高潮，并霸占微博熱搜榜好幾天，也正是因為這個突發的流量，致使流量過大一度引發微博服務器癱瘓，而成為吃瓜群眾熱議的話題。微博擁有超過3.76億月活用戶，是當前社會熱點事件傳播的最主要平臺，其中包括但不限制于大型活動（如里約奧運會、十九大等）、春晚、明星動態（如王寶強離婚事件、女排奪冠、喬任梁去世、白百合出軌、TFBOYS生日、鹿晗關曉彤CP等）。而熱點事件往往具有不可預見性和突發性，并且伴隨著極短時間內流量的數倍增長，甚至更多，有時持續時間較長。如何快速應對突發流量的沖擊，確保線上服務的穩定性，是一個挑戰巨大且頗有意義的事情。

圖1 鹿晗發博截圖

熱點事件的特點

從上述系列流量圖中，我們可以看出這兩起事件對微博的核心服務如Feed、評論、贊、話題等帶來的壓力都是成倍的，創造了歷史的新高點。仔細分析不難發現，這類事件基本可以分為：發生期、發酵期、暴漲期和緩解期，只是由于天時地利人和等各種因素的綜合影響，各個時期的持續時間、流量變化不盡相同，對服務的壓力也有所差異，在暴漲期所表現出的不亞于天貓雙11，以及12306搶票的盛況。總體上反映出這類熱點事件的特點為：

• 不可預見性和突發性

• 峰值流量大

• 持續時間短

• 參與人數多

• 涉及資源廣

圖2 鹿晗關曉彤CP Feed業務量圖3 鹿晗關曉彤CP評論業務量圖4 鹿晗關曉彤CP 話題業務

面臨的挑戰

微博研發中心數據庫部門主要負責全微博平臺后端資源的托管和運維，主要涉及的后端資源服務包括MySQL、Memcached、Redis、HBase、Memcacheq、Kafka、Pika、PostgreSQL等。為了應對峰值流量并保證用戶的良好體驗，資源層會面臨哪些挑戰？又將如何解決呢？

• 面對不可預期的峰值流量，有時惡意的刷站行為，如何應對數倍，甚至數十倍于日常訪問量的壓力？

• 如何應對瞬時可達幾萬/秒的發表量？

• 如何做到異地容災？

• 如何保證緩存的命中率，減少緩存穿透甚至“雪崩”？

• 如何實現緩存的快速動態擴縮容？

• 如何保證服務的低延遲、高可用？

• 如何保證核心系統的穩定性？

• 如何實時監控系統服務狀態？

• ……

微博數據庫運維體系架構解析

業務架構

微博目前用戶基數龐大，DAU和MAU均為數億。從整個技術體系來看，微博核心總體分為前端和后端平臺，端上主要是PC端、移動端、開放平臺以及企業開放平臺。后端平臺主要是Java編寫的各種接口層、服務層、中間件層及存儲層。除此之外，微博搜索、推薦、廣告、大數據平臺也是非常核心的產品。從業務角度看，整體架構圖如下：

圖5 業務架構圖

這里以微博平臺的業務為例，微博平臺的服務部署架構如圖6。

圖6 平臺服務部署架構圖

就平臺業務而言，后端的資源每天承載著千億次的寫請求，萬億次的讀請求，如MySQL在流量極端峰值的情況下承載著幾十萬，甚至上百萬的QPS，面對這么大體量的業務壓力，對于后端資源的穩定性和RTT也提出了極高的要求，對業務部門承諾的SLA必須達到3個9，部分業務甚至4個9，且平均響應時間不能高于50ms。因此面臨的挑戰不言而喻。為了達到這一目標，需要有一個完善的，穩定可靠的，健壯的數據庫運維體系來提供支撐和管理全平臺25個分支下600多個產品線的業務運維。

數據庫運維體系架構

圖7 數據庫運維體系架構圖

整個運維體系由三大部分組成：UI層、應用服務層、基礎服務層。UI層是各種管理平臺的Dashboard和功能入口以及提供基礎的Restful API等；應用服務層是數據庫運維過程中所用到的各種功能模塊集合，為RD和DBA提供最全面的數據庫管理功能，這部分是整個運維體系中的核心組成部分，也是整個體系中最龐大和最復雜的部分；基礎服務層是整個運維體系中最基礎的依賴層，為數據庫運維體系提供底層的基礎服務，這里需要特別提出是，熱點事件應對過程中的彈性擴縮容就是依賴這一層的DCP系統和Docker鏡像，結合私有云和公有云提供的ECS虛擬機來完成。

MySQL高可用架構

圖8 MySQL高可用架構圖

MHA（Master High Availability）目前在MySQL高可用方面是一個相對成熟的解決方案，它由日本DeNA公司Youshimaton（現就職于Facebook公司）開發，是一套優秀的作為MySQL高可用性環境下故障切換和主從提升的高可用軟件。在MySQL故障切換過程中，MHA能做到在0~30秒之內自動完成數據庫的故障切換操作，并且在進行故障切換的過程中，MHA能在最大程度上保證數據的一致性，以達到真正意義上的高可用。微博MySQL高可用也基于MHA方案實現，這里MHA是在Youshimaton開發的MHA思想上自研而成。整個架構由三部分組成：監控、MHA和MySQL集群（主從實例）組成。為了實現MySQL的高可用和災備：

• 在部署拓撲結構上，我們把MySQL的從庫實例部署在不同的數據中心，給業務提供的是域名方式訪問后端的DB資源，跨數據中心的同步帶來的另一個好處是業務結構清晰和同機房前端訪問同機房的后端資源，而不必跨機房訪問，同時也方便架構上做流量切換的操作。

• 我們會為被監控的MySQL主庫添加一個白名單，白名單內的端口，在啟用監控的條件下，能夠實現在主庫服務器宕機，所有從庫實例都不可連主庫，長時間服務器網絡故障的條件下，自動完成主從切換。其中，主庫check階段，首先用從管理機上用Python自帶的MySQL庫去連接MySQL測試，如果連接失敗，再檢查主機層面連通性以及進程存活情況，如果失敗，再考慮從所有從庫去檢查主庫情況，優先先檢查一臺從庫，這樣做主要是為了防止誤切。

• 在MHA自身的高可用上，我們也是基于KeepAlive做了高可用的方案，保證MHA的可用性。

多級緩存架構

圖9 多級緩存架構圖

Config Service

這一模塊是基于現有微博的配置服務中心，它主要是管理靜態配置和動態命名服務的一個遠程服務，能夠在配置發生變更的時候實時通知監聽的Config Client。

Proxy

這一模塊是作為獨立的應用對外提供代理服務，用來接收來自業務端的請求，并基于路由規則轉發到后端的Cache資源，它本身是無狀態的節點。它包含了如下部分：

• 異步事件處理(Event Handler)：用來管理連接、接收數據請求、回寫響應；

• Processor：用來對請求的數據進行解析和處理；

• Adapter：用來對底層協議進行適配，比如支持MC協議、Redis協議；

• Router：用來對請求進行路由分發，分發到對應的Cache資源池，進而隔離不同業務；

• LRU Cache：用來優化性能，緩解因為經過Proxy多一跳（網絡請求）而帶來的性能弱化；

• Timer：用來執行一些后端的任務，包含對底層Cache資源健康狀態的探測等；

• Stat：Proxy節點信息狀態統計。

Proxy啟動后會去從Config Service加載后端Cache資源的配置列表進行初始化，并接收Config Service配置變更的實時通知。

Cluster Manager

這一模塊是作為實際數據緩存的管理模塊，通過多層結構來滿足服務的高可用。 首先解釋一下各層的作用：

圖10 多級緩存中各角色含義

其中，Master是主緩存節點，Slave是備份節點，當Master緩存失效或實例掛掉后，數據還能夠從Slave節點獲取，避免穿透到后端DB資源，L1主要用來抗住熱點的訪問，它的容量一般比Master要小，平臺的業務通常部署多組L1，方便進行水平擴容以支撐更高的吞吐。

Client客戶端

這一模塊主要是提供給業務開發方使用的Client（SDK包），對外屏蔽掉了所有細節，只提供了最簡單的get/set/delete等協議接口，從而簡化了業務開發方的使用。

應用啟動時，Client基于namespace從Config Service中獲取相應的Proxy節點列表，并建立與后端Proxy的連接。正常一個協議處理，比如set命令，Client會基于負載均衡策略挑選當前最小負載的Proxy節點，發起set請求，并接收Proxy的響應返回給業務調用端。

Client會識別Config Service推送的Proxy節點變更的情況重建Proxy連接列表，同時Client端也會做一些容災，在Proxy節點出現問題的時候，對Proxy進行摘除，并定期探測是否恢復。

目前微博平臺部分業務子系統的Cache服務已經遷移到了CacheService之上，它在實際運行過程中也取得了良好的性能表現，目前整個集群在線上每天支撐著超過千萬級的QPS，平均響應耗時低于1ms。

它本身具備了以下特性。

• 高可用

所有的數據寫入請求，Cache Service會把數據雙寫到HA的節點，這樣，在Master緩存失效或掛掉的時候，會從Slave讀取數據，從而防止節點fail的時候給后端資源（DB等）帶來過大的壓力。

• 服務的水平擴展

Cache Service Proxy節點本身是無狀態的，在Proxy集群存在性能問題的時候，能夠簡單地通過增減節點來伸縮容。而對于后端的Cache資源，通過增減L1層的Cache資源組，來分攤對于Master的請求壓力。這樣多數熱點數據的請求都會落L1層，而L1層可以方便的通過增減Cache資源組來進行伸縮容。

• 實時的運維變更

通過整合內部的Config Service系統，能夠在秒級別做到資源擴容、節點替換等相關的運維變更。目前這塊主要結合DCP系統，利用Docker鏡像以及虛擬機資源完成彈性的擴縮容。

• 跨機房特性

微博系統會進行多機房部署，跨機房的服務器網絡時延和丟包率要遠高于同機房，比如微博廣州機房到北京機房需要40ms以上的時延。Cache Service進行了跨機房部署，對于Cache的查詢請求會采用就近訪問原則，對于Cache的更新請求支持多機房的同步更新。

異步消息隊列更新機制

互聯網應用有個顯著特點，就是讀多寫少。針對讀多有很多成熟的解決方案，比如可以通過Cache來緩存熱數據以降低數據庫的壓力等方式來解決。而對于寫多的情況，由于數據庫本身的寫入性能瓶頸，相對較難解決。我們知道春晚發祝福，或娛樂熱點的時候發評論、點贊等場景下，會有大量的并發寫入，我們為了解決這類問題，引入了“異步消息隊列更新機制”。從微博平臺的服務部署架構圖中也可以看到，當用戶發微博或評論等時候，不是直接去更新緩存和DB，而是先寫入到MCQ消息隊列中，再通過隊列機處理程序讀取消息隊列中的消息，再寫入到數據庫和緩存中。那么，如何保證消息隊列的讀寫性能，以及如何保證隊列機處理程序的性能，是系統的關鍵所在。

• 按消息大小設置雙重隊列，保證寫入速度

眾所周知，2016年中旬之前微博的最大長度不超過140個字，現在放開了這個限制。但是大部分用戶的實際發表的微博長度都比較小，為了提高寫入隊列的速度，我們針對不同長度的微博消息，寫入不同大小的消息隊列，比如以512字節為分界線，大于512字節的寫入長隊列，小于512字節的寫入短隊列，其中短隊列的單機寫入性能要遠遠高于長隊列。實際在線結果表明，短隊列的QPS在萬/s級別，長隊列的QPS在千/s級別，而95%的微博消息長度均小于512字節。這種優化，大大提高了微博消息的寫入和讀取性能。

• 堵塞隊列，壓測隊列的承載能力和隊列機極限處理能力

為了驗證隊列機處理程序的極限處理能力，我們在業務低峰時期，對線上隊列機進行了實際的壓測，具體方法如下：通過開關控制，使隊列機處理程序停止讀取消息，從而堵塞消息隊列，使堆積的消息分別達到10萬，20萬，30萬，60萬，100萬，然后再打開開關，使隊列機重新開始處理消息，整個過程類似于大壩蓄水，然后開閘泄洪，可想而知，瞬間涌來的消息對隊列機將產生極大的壓力。通過分析日志，來查找隊列機處理程序最慢的地方，也就是瓶頸所在。通過兩次實際的壓測模擬，出乎意料的是，我們發現系統在極限壓力下，首先達到瓶頸的并非是數據庫寫入，而是緩存更新。因此，為了提高極限壓力下，隊列機處理程序的吞吐量，我們對一部分緩存更新進行了優化。

另一方面，通過壓測，也可以幫助我們發現隊列的承載能力和處理能力，有效幫助我們找到隊列的短板，方便我們進行優化和擴容，通常情況下，核心隊列都會保證3到4倍的冗余。

應對熱點事件的手段和策略

擴容

這是DBA常采用的手段。擴容通常分為水平擴容和垂直擴容：

• 垂直擴容

垂直擴容，可以理解為保證架構不變的前提下，通過增加硬件投入即可實現的擴容方式。對于緩存而言，擴容是很容易、很方便、很快捷實現的，而對于DB來說，通常體積比較大，擴容起來很不方便，周期時間很長，尤其是應對流量的情況下，通常優先擴容緩存來抗熱點，減少對后端DB的訪問。而對于DB的擴容，我們會不定期對核心DB資源進行評估，隨著業務的不斷發展，當超過一定的水位線時，為了保證DB的可用性，需要保留3到4倍的冗余，當不滿足時，便需要擴容。因為熱點總是不期而來，往往擴容緩存并沒有那么及時，這時候保證足夠的冗余，有助于預防DB被打掛，保障服務的穩定性，就顯得很重要。

• 水平擴容

水平擴容，可以理解為通過調整架構，擴展資源的承載能力。比如：對于Redis服務來說，原本一個業務是4主4從，在業務量并發不高的情況下，完全滿足業務需求，但是隨著業務量上漲后，Redis的寫性能變差，響應時間變慢，此時，我們需要對該業務進行水平擴展，將業務架構調整為8主8從或者更多，從而部署更多的主庫還抗寫入量。

降級

對于一個高可用的服務，很重要的一個設計就是降級開關，其目的是拋棄非重要服務，保障主要或核心業務能夠正常提供服務。對于后端資源，包括MySQL、MC、Redis、隊列等而言，并不能保證時時刻刻都是可用的，一旦出現問題，降級策略就能派上用場。那么如何降級？降級的標準是什么？這里拿話題頁舉個例子。

圖11 話題首頁

圖12 點擊“導語”進入的二級頁面

• 拋棄非核心大量運算業務，減輕自身計算服務壓力。

任何一個系統，都包含核心系統和非核心系統。在出現異常的情況下，棄車保帥，只保障核心系統的穩定性也是可以接受的。對于上面的這個話題來說，話題首頁是核心業務，話題二級頁面是非核心業務。當話題DB資源出現瓶頸時，我們可以優先讓RD同學降級二級頁，釋放DB的連接資源并減少查詢請求，保障話題首頁能夠有更多的資源可用。

• 拋棄非核心模塊，減輕自身資源壓力。

同樣，對于同一個業務，也要區分核心邏輯和非核心邏輯。對于話題首頁的這個資源，微博時尚發布的Feed流屬于核心邏輯，而頭像下方的時尚美妝榜TOP1 榜單則屬于非核心邏輯。毫無疑問，為了減負，非核心邏輯必要時是可以被降級的。

• 拋棄高耦合邏輯，避免依賴服務性能下降導致雪崩。

在微博復雜的架構體系中，各種依賴和接口調用，錯綜復雜。就話題首頁資源來看，“閱讀11.8億 討論36萬 粉絲1.9萬”的計數就是調用微博平臺的接口獲取Redis計數器資源的結果。對于熱點事件而言，尤其是對于這種全平臺都可能會調用的資源來說，當時的訪問量是極大的，響應時間肯定會比平時差，如果話題首頁因為要取該資源而超時，導致話題“白頁”，那必然不是想要的結果，所以需要拋棄這類高耦合邏輯。對于后端資源而言，當某個資源，比如某臺MCQ服務器宕機，嚴重影響V4啟動，拖累整體動態擴容時，業務方就會考慮暫時503這臺服務器實例資源，保證整個擴容流程的順暢和速度。同時業務方也會根據請求的后端資源使用特點的不同，有時在降級前會使用一些fast fail或fast over的策略來保障服務的穩定性和可用性。

切流量

對于一個大型系統而言，這也是一個常用手段，通常可用從DNS、LVS、H5、HaProxy（四層負載均衡）、Nginx（七層負載均衡）等層面上來實現流量的切換。常見的使用場景有：

1. 某機房業務流量達到瓶頸，影響業務的請求耗時和用戶體驗的時候，需要將到這個機房的請求量，一部分切到其他機房，使得流量相對均衡一點。

2. 機房搬遷、機房斷網/斷電，也需要進行切流量操作，保證服務的可用性。

3. 業務架構調整、鏈路壓測，比如將晚高峰的流量，從一個機房切到另一個機房，壓測另一個機房的資源承載能力。

4. 線路帶寬打滿，由于某條專線的承載能力達到上限，不得不將流量從該線路切到其他線路。春晚前，彈性擴縮容的需求很多，經常有很多業務方同時進行擴容，因為需要下載鏡像、遷移數據、下發配置等，專線很容易成為瓶頸，故需要準備一個備用專線或提前提升專線容量。

5. 運營商故障，雖然現在一般的機房都具備BGP的能力，但有時還是需要從業務層面去解決。

限流

從字面意思可以看出，限流的目的就是為了防止惡意請求（如刷站）、惡意攻擊，或者防止流量超出系統的峰值。處理的原則就是限制流量穿透到后端的資源，保障資源的可用性。舉個例子：比如圖13的QPS異常現象，請求流量超出平時晚高峰的好幾倍，嚴重影響了服務的穩定性和后端DB的承載能力，為了保障DB資源的可用性，經排查是屬于通過user_timeline接口的惡意刷站行為，此時，我們要做的就是封殺該接口，限制流量穿透到DB層，封殺后，效果很明顯。

圖13 刷站時QPS圖

限流（封殺）后的效果如圖14所示：

圖14 限流效果圖

除了封殺接口之外，其他一些可借鑒的思路是：

• 對于惡意IP：可以使用Nginx deny進行屏蔽或采用iptables進行限制。

• 對于穿透到后端DB的請求流量：可以考慮用Nginx的limit模塊處理或者Redis Lua腳本實現或者啟用下面的過載保護策略。

• 對于惡意請求流量：只訪問到Cache層或直接封殺。

過載保護

這個策略是針對DB資源設計的，就是當請求超過DB的承載范圍時，啟動的一個自我保護機制。比如，在某個明星出軌的時候，有用戶惡意刷評論列表，導致評論的數據庫從庫資源出現大量延遲，嚴重影響服務的性能，為了防止DB資源因過載而不可用，通過和業務方溝通后，果斷啟動了過載保護機制，從而保證了評論服務的穩定性。圖15就是應用了過載保護機制后的效果。開源的工具可以使用percona公司開源的pt-kill工具實現。

圖15 過載保護效果圖

鏈路壓測

壓測的目的是找出資源或者鏈路上的瓶頸點或者驗證技術選型的可行性或測試優化的效果，這也是一個常態化的過程，一般分為兩種場景：

• 找瓶頸點

這個通常是配合業務方共同完成，如上面的異步消息隊列更新機制中提到的一樣，通過切流量、堵塞隊列、壓測隊列的承載能力和隊列機極限處理能力，找出資源的瓶頸點，方便作為進行優化和擴容的依據，有時候也作為設置水位線的一個標準。

• 驗證技術選型的可行性或測試優化效果

有時候為了引入新的技術，需要進行性能/壓力測試，或者有時候為了驗證某項優化的效果，然而壓測很難模擬真實的線上環境場景，此時在保證服務穩定可控的情況下，通過TCPCopy的方式引入線上的真實流量加以驗證。

• 水位線&預警機制

這可以快速有效地幫助了解線上業務的變化趨勢，以及快速定位業務的實時運行情況，如果超過水位線，會觸發預警機制，通過這種手段可以輔助DBA做出相應的策略判斷，比如：擴容、限流、過載保護等。

需要完善和改進的地方或未來的規劃

智能擴縮容

當前很多情況下，尤其是當有熱點的時候，DBA都是通過申請資源，部署服務，然后上線，完成一系列的手動操作完成擴容，這顯然會浪費很多的人力，效率也不高。未來，可以通過設置水位線，增加對熱key的預判，以及帶寬的閾值，當超過警戒位后，通過開發的自動化工具來智能地進行MC的動態擴縮容。

故障自愈系統

故障無處不在，因為任何硬件都有使用壽命，都有折損率。現在每天都可能有服務器宕機、服務器異常重啟、服務器系統readonly、內存損壞、RAID卡損壞、CPU損壞、主板損壞、磁盤損壞、電源模塊損壞等，各種硬件的故障都有可能會導致服務異常，那么如何應對這些故障，保證服務器的高可用，是一個普遍面臨的問題。微博有很多服務器都過保，它們就像一個“雷” 一樣無處不在，但是這些故障也是有輕有重，有緊急有非緊急的，根據具體部署業務的不同而不同。服務器數量之多，每天報警幾千條，全憑人工處理很難覆蓋全面，這就急需結合監控和故障采集樣本開發一套自愈系統，完成基礎的，甚至大部分類型的故障修復工作，比如自動報修。

移動辦公

移動互聯網時代，移動辦公已經不是什么時髦的事情，很多的工作都能直接在手機或智能終端設備上完成。雖然目前有部分工作，比如工單審核、登錄服務器執行命令等都可以在手機上實現，但是還有很多工作沒有辦法完成，比如查看監控、手動擴容等復雜操作，需要后續的完善。

服務自助化

服務自助化，需要依賴完善的基礎服務和健壯穩定的自動化平臺，以及充足的冗余資源和完備的標準服務流程和規范才能完成。這是一個長期的過程，目前微博已經能夠在SQL審核、Online DDL方面提供自助式服務，但是還有很多方面需要完善和提高，比如：資源申請、資源下線、資源擴容等。

作者簡介：張冬洪，新浪微博研發中心高級DBA，Redis中國用戶組主席，多年Linux和數據庫運維經驗，專注于MySQL和NoSQL架構設計與運維以及自動化平臺的開發；目前在微博主要負責Feed核心系統相關業務的數據庫運維和業務保障工作。?
本文為《程序員》原創文章，未經允許不得轉載。

1月13日，SDCC 2017之數據庫線上峰會即將強勢來襲，秉承干貨實料（案例）的內容原則，邀請了來自阿里巴巴、騰訊、微博、網易等多家企業的數據庫專家及高校研究學者，圍繞Oracle、MySQL、PostgreSQL、Redis等熱點數據庫技術展開，從核心技術的深挖到高可用實踐的剖析，打造精華壓縮式分享，舉一反三，思辨互搏，報名及更多詳情可掃描下方二維碼或點擊「閱讀原文」查看。

總結

以上是生活随笔為你收集整理的微博热点事件背后数据库运维的“功守道”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。