前段時間，在網上看到一個詞兒——“星軌”，說是新浪微博衡量服務器抗壓能力的新單位，當時我就覺得既形象又有趣，還有些搞笑。
先給大家解釋一下什麼是星軌。
一星軌表示一個一線明星出軌所帶來的流量，據說微博的服務器現在能同時扛8星軌。
也就是說：8個一線明星同一時間爆出出軌的新聞，微博都能扛得住！
當然哈，這只是一句調侃的話，用於證明微博服務器的抗壓能力已經很強了。
其實，微博的程序員小哥們可真不容易，因為微博的流量波動是很難預測的，指不定什麼時候出來一個熱點話題，微博的流量就會垂直上升。
這也是微博和其他網站最大的區別。
淘寶、地圖、京東這些應用平時的流量是很穩定的，不會出現短時間的暴增也不會出現斷崖式的下跌。
在一些特殊時點，比如雙十一，淘寶的工程師們會提前增加N倍的線上服務器，而京東的工程師們早就做好了迎接618的準備，地圖的同學們也早在節假日之前就擴充了服務器。
也就是說，上述應用都能準確知道自己的流量高峰會在什麼時候出現，所以可以在流量高峰到來以前擴充服務器資源，保證自己的應用能夠正常運行。
可能有同學會疑問，為什麼平時不多部署一些機器呢？這樣服務就不怕流量暴增了哇。
道理是這麼個道理，可是事兒不是這麼個事兒。服務器資源是比較昂貴的，平時部署太多的機器會徒增很多額外的開銷，所以大部分企業平時都只會部署能承受正常流量3~4倍流量的機器。
它們採取的方式都是在流量高峰到來之前擴充更多的服務器（不少企業都是租用亞馬遜、阿里雲等雲服務提供商的服務器），用完之後就釋放，這樣能節約不少成本。
而微博就很無奈了，因為它無法預測流量高峰，誰也不知道明星們啥時候就搞個出軌或是其他新聞出來，流量短時間暴增，微博的服務器就扛不住了。
下圖是鄧超2015年12月20日刷屏的微博，那一天他的刷屏就把微博服務器給搞掛了不少。
我們可以看到，上圖中，鄧超發佈的微博評論量都是10萬以下，加起來也不過幾十萬，這並不是一個很大的數字，至少和明星出軌、偷稅漏稅這種新聞比起來，流量算小的。不過即使是這樣，也都把微博服務器搞掛了，那明星出軌能帶來多大流量呢？
下圖是2014年文章爆出出軌新聞後馬伊琍的回應微博截圖，評論過百萬，轉發46萬。
2015年陳赫出軌後認錯的微博評論更是高達299萬。
所以，微博的程序員們最怕什麼？
不是怕代碼出bug。
怕的是明星出軌。
而和明星出軌比起來，程序員們更怕的是明星出軌的新聞被晚上爆出來。
一個明星的出軌可能會導致幾十個、上百個人半夜爬起來加班。
所以，各位大佬，請別出軌了，就算要出軌，請一定要在工作日的正常工作時間被曝出軌，程序員很辛苦的。
好不容易要下班了，WTF？？？
下面這一條微博帶來的流量起碼等於三個一線明星同時出軌帶來的流量。
程序員內心OS：
加班！加班！加班！
在無休止的加班中，程序員小哥哥們終於忍不住了，想著要改變這個現象！！！
所以，程序員們日夜不休地優化代碼，終於！微博的抗壓能力上去了！
現在能扛8星軌，8個明星同時出軌也不虛了。
最近沒有聽說明星出軌的新聞把微博服務器搞掛的消息了吧。
好啦，段子講完了，下面來點乾貨，今天給大家聊一聊“消息隊列”，以及如何用“消息隊列”來應對大流量高併發下用戶提交內容的入庫問題。
在講消息隊列之前，先給大家介紹一個互聯網術語——UGC。
“互聯網術語，全稱為User Generated Content，也就是用戶生成內容的意思。UGC的概念最早起源於互聯網領域，即用戶將自己原創的內容通過互聯網平臺進行展示或者提供給其他用戶。UGC是伴隨著以提倡個性化為主要特點的Web2.0概念興起的。”
在本文中，大家可以認為UGC指的是用戶的評論內容。
下圖是互聯網企業在線服務常見的部署方式：
當用戶發送請求之後（評論操作或者消息請求操作），中轉設備就把流量分攤到集群中的各個物理節點上，比如使用Nginx做代理以及負載均衡。
當流量短時間暴增的時候，假設正常情況下一臺服務器的qps（每秒的請求量）是300，突然某個明星出軌的事情上熱搜了，qps暴增到3000，導致其中某些稍微脆弱的服務器先跪了，那麼剩下的服務器就要承擔更多的流量（跪了的服務器的流量被分到了其他剩下的服務器上），服務器承受的壓力越來越大，然後就一臺一臺地跪了。
相信大家都知道，對於存儲系統而言（比如MySQL，MongoDB等），正常情況下的寫入壓力、更新壓力是大於查詢壓力的，而恰好，微博的評論短時間轟炸，後端集群只要有一個環節扛不住就很容易癱瘓了，這時候用戶看到的結果就是——操作無響應。
那麼問題來了，我們該怎麼去應對這種情況呢？
給在線服務加一個消息中間件是個不錯的選擇。
什麼是消息中間件？
百度百科對消息隊列的解釋是“在消息的傳輸過程中保存消息的容器”。
我相信很多朋友看了這個解釋也還沒有明白什麼是"消息隊列"，所以我們還是以微博為例來看一個具體的場景。
這裡我們做一個抽象，把產生消息的用戶比喻成生產者，把服務器集群比喻成消費者（生產者消費者是不是很熟啊，哈哈，學過操作系統的同學肯定很熟）。
我們在生產者和消費者之間加了一箇中間件——消息隊列，用它可以來幹嘛呢？
它是來做消息轉發的，當請求過來之後，不是直接發給服務器，而是發給消息隊列，然後消息隊列把消息中轉一下再發給服務器。
很多同學可能會想，這不是多此一舉嗎？
其實不然。
- 消息隊列可以把消息分類，分別下發，比如點贊、評論和轉發，各自走各自的通道。
- 消息隊列可以暫存消息。當用戶的請求到達消息隊列以後，消息隊列就給用戶發出響應，顯示評論成功，即使這時候該評論還沒寫入數據庫，可是用戶是不感知的。當流量暴增的時候，生產者生成的消息大於消費者的處理能力，消息就會先被暫存在消息隊列裡，然後消費者全力去處理，這樣就避免了服務器壓力過大。消息隊列並不是全部存儲在內存中，也是可以寫入硬盤的，所以能存儲很大量的消息。
這裡只是給大家介紹了消息隊列相關知識的冰山一角，更多的知識，大家可以下來自己去了解。
閱讀更多 米花頭美髮預約 的文章
