一年一度的春晚再次落下帷幕，而微博也順利地陪伴大家度過除夕之夜。
談及馬年春晚，人們首先想到的不是春晚上精彩的節目，而是微博上的吐槽，邊看春晚，邊刷微博，邊吐槽，已經成了國人的習慣。看春晚不再是為了看節目，而是為了能夠在微博上吐槽，知道大家在吐槽什麼，更有人戲稱不是春晚成就了微博，而是微博拯救了春晚。
相關廠商內容
根據以往統計的資料，春晚期間微博的訪問量將激增到日常水平的數倍之多，而瞬時發表量更是飆公升數十倍，如此場景絲毫不亞於**雙11和12306搶票時的」盛況」。
而最後的統計資料結果表明，馬年春晚直播期間，微博的訪問量和發表量都再創新高，而我們系統也自始至終平穩執行，經受住了此次高峰的考驗。這成功的背後，是我們的工程師將近乙個月的努力。其間面臨了哪些問題，又是如何解決的呢？下面，我們一一為大家揭秘。
需要提到一點的是，微博目前線上部署了幾千臺伺服器，來保障日常的正常訪問。假如面對原來數倍的訪問壓力時，如果簡單粗暴通過線性擴容來應對的話，需要部署原來數倍的伺服器，也就是需要上萬台伺服器。無論從硬體成本還是從管理成本上，這都是不可接受的。那麼，又該如何做呢？
眾所周知，為了盡可能的保障線上執行的伺服器的穩定，資源都是有一定冗餘度的，一般安全值在30%以上。在面臨5倍的訪問量時，出於成本的考慮，單純的擴容難以令人接受。這個時候，就要充分利用每台伺服器，在不影響業務效能的前提下，使每台伺服器的利用率發揮到極限，可以極大的降低資源擴容的數量。如何評估伺服器的承受極限是其中的關鍵，為此我們在業務低峰時期，對線上的伺服器進行了實際的壓測。具體方法如下：
假如線上乙個服務池裡有300臺 tomcat伺服器在提供api服務，正常情況下，每台伺服器的負載都小於1（為了簡化模型，我們這裡只提到了系統load這個指標，實際情況要比這個複雜的多，還要考慮cpu 利用率、頻寬、io延遲等）。通過運維系統，我們以10%、20%、30%、40%、50%等比例逐步將該服務池裡的300臺 tomcat 機器503，通過觀察一台 tomcat 伺服器的負載以及 api 服務的介面效能，當伺服器的負載達到極限或者 api 服務的介面效能達到閾值時，假設此時服務池裡正常狀態的 tomcat 伺服器的數量是100臺，那麼我們就可以推斷出該服務池，極限情況下可以承受3倍與日常的訪問壓力。同理，為了承擔5倍的訪問量，只需再擴容一倍機器即可。
網際網路應用有個顯著特點，就是讀多寫少。針對讀多有很多成熟的解決方案，比如可以通過cache 來快取熱資料來降低資料庫的壓力等方式來解決。而對於寫多的情況，由於資料庫本身寫入效能瓶頸，相對較難解決。
微博系統在處理發表微博時，採用了非同步訊息佇列。具體來講，就是使用者發表微博時，不是直接去更新資料庫和快取，而是先寫入到 mcq訊息佇列中。再通過佇列機處理程式讀取訊息佇列中的訊息，再寫入到資料庫和快取中。那麼，如何保證訊息佇列的讀寫效能，以及如何保證佇列機處理程式的效能，是系統的關鍵所在。
為了驗證佇列機處理程式的極限處理能力，我們在業務低峰時期，對線上佇列機進行了實際的壓測，具體方法如下：
通過開關控制，使佇列機處理程式停止讀取訊息，從而堵塞訊息佇列，使堆積的訊息分別達到10萬，20萬，30萬，60萬，100萬，然後再開啟開關，使佇列機重新開始處理訊息，整個過程類似於大壩蓄水，然後開閘洩洪，可想而知，瞬間湧來的訊息對佇列機將產生極大的壓力。通過分析日誌，來查詢佇列機處理程式最慢的地方，也就是瓶頸所在。
通過兩次實際的壓測模擬，出乎意料的是，我們發現系統在極限壓力下，首先達到瓶頸的並非是資料庫寫入，而是快取更新。因此，為了提高極限壓力下，佇列機處理程式的吞吐量，我們對一部分快取更新進行了優化。
無論是發微博，還是刷 feed，在微博系統內的處理過程都十分複雜，依賴著各種內部資源和外部服務，保證系統的可靠性顯得尤為困難。
為此，我們內部開發了代號為試金石——touchstone的壓測系統，對系統的可靠性進行全面檢測。
首先，我們對微博的各個介面進行了服務依賴和資源依賴的梳理，並針對每個服務和資源定義了相應的 sla 和降級開關。然後，模擬資源或者服務出現異常，再來檢視其對介面效能的影響。以 redis資源為例， 假設系統定義了redis的 sla是300ms，相應的埠是6379，通過 touchstone，使該埠不可用，從而模擬 redis 資源出現異常，然後驗證依賴該資源的介面的效能，確保 sla 。同時，通過降級開關，對該資源進行降級，驗證降級開關的有效。
基於以上方法，對系統進行了全面的檢測，並對各個服務和資源的 sla 和降級開關進行梳理，總結成業務降級手冊，保證在出現問題時，運維人員無需開發的介入，也能第一時間根據降級手冊進行降級，確保問題能夠盡快解決。
任何乙個系統，都包含核心系統和非核心系統。在出現異常的情況下，棄車保帥，只保障核心系統的穩定性也是可以接受的。
同樣，對於乙個業務，也要區分核心邏輯和非核心邏輯。以發微博為例，更新快取和寫資料庫屬於核心邏輯，而給其它業務部門推送資料則屬於非核心邏輯。因此，可以將推送資料進行非同步化處理，交給單獨的執行緒池處理，在出現異常時，不會對更新快取和寫資料庫造成影響。
微博早在2023年就開始了多機房的部署，如今已經具備三大機房（分別針對聯通、電信和海外使用者）。
我們都知道，**的發生都是有前兆的，比如一些動物的異常反應。同樣，系統中的任何問題出現之前，也是有線索可尋的。這就需要對系統的關鍵指標做實時的監控，當指標出現異常時，能夠第一時間發出報警資訊。
為此，我們基於實時流處理系統 storm 開發了一套監控系統——dashboard。有別於以往的監控系統，它能實時處理系統產生的海量日誌，繪製出更加直觀的曲線，方便運維進行管理。通過 dashborad，我們能夠了解系統的實時狀態，主要包括feed的訪問量、微博的發表量、佇列機的處理效能，訊息佇列的堆積量等指標。當某個監控指標出現異常時，能夠第一時間在 dashboard 中反映出來，從而第一時間採取措施，解決問題，避免問題擴大化。
春晚已經過去乙個月了，漸漸成為回憶。但春晚背後，我們的工程師所付出的巨大的努力所產生的價值，卻是一筆寶貴的財富，希望這篇文章能給大家帶來啟發甚至幫助，也在此向為微博春晚默默貢獻的工程師們致敬！
讀《微博春晚背後的技術故事》筆記
文章講述了在應對春節可能帶來的挑戰，微博做了哪一些準備。方法 1 為應對訪問量的劇增，在現有的服務下進行壓力測試，確認現在有的服務可以承受多大的壓力，從而決定需要擴充多少的伺服器。在訪問量比較少的時候，按10 20 的比例把部分服務池裡的伺服器503處理，然後觀察伺服器壓力。假設有300臺伺服器，關...
解讀微信終端開源背後的故事
問 mars的研發有沒有借用一些其它開源產品？趙原 最開始研發時，mars與業務相關，它的優化必須結合內部業務來完成，所有的技術都是自主研發完成。當然我們也會使用例如openssl這樣的一些非常基礎的開源庫。在mars選擇開源後，我們將其中很多業務相關的部分移除掉，將它改造成誰都可以使用的技術。趙原...
微信支付商戶系統架構背後的故事
本文由李躍森發表於雲 社群專欄 postgresql xc在事務管理系統方案本身有乙個明顯的缺點，那就是事務管理機制會成為系統的瓶頸，gtm global transaction manager全域性事務管理器 會限制系統的擴充套件規模。如圖1所示，是每個請求過來cn coordinator 協調節...