訊息佇列是很早以前就有的一種中介軟體。由於系統之間需要通訊，所以訊息佇列就產生了。訊息佇列的使用場景主要有以下幾個場景。
1.非同步處理
比如我們要設計乙個秒殺系統的解決方案（當然秒殺系統有很多解決方案，這裡只是舉乙個簡單的例子）。秒殺系統主要就是解決有限的伺服器資源完成瞬時盡可能多的海量請求。但是乙個秒殺請求又有很多問題需要解決，比如：
1）風險控制
2）庫存鎖定
3）生成訂單
4）簡訊通知
5）其他
如果按照傳統方式，我們的秒殺系統需要依次處理以上問題，最後將結果返回前端。但是我們知道，只有風險控制與庫存鎖定是秒殺系統的關鍵服務，對於像生成訂單和簡訊通知等並不是一定要在秒殺請求中立刻處理的服務。所以，秒殺請求我們只需要處理前兩個服務，然後就可以直接返回秒殺請求結果。對於後續的服務，我們可以通過訊息系統來完成。如下圖：
傳統處理方式
訊息系統
2.流量控制
我們仍然以秒殺系統為例，雖然上面的方式已經減少了伺服器壓力，提高的qps。但是在面對更大量的請求的時候，伺服器總有處理不過來的時候。畢竟伺服器資源是有限的，那麼為了保證伺服器不被系統壓垮，我們需要提高伺服器的健壯性，這裡我們通過mq系統來隔離後端的服務請求，所有的請求都先提交到mq系統中，而後端伺服器則只需要根據自己的實際處理能力來處理請求即可。對於超時的請求，則直接丟棄。前端controller層可以直接秒殺請求失敗。
這樣做的好處是：提高了系統的健壯性，在高併發情況下，請求不會直接沖死後端服務。運維可以通過請求資料水平擴容伺服器例項，不需要修改任何**。
這樣做的壞處是：服務鏈路過長，系統複雜度增加。
如果我們可以預估自己伺服器處理容量，我們可以採用另乙個令牌桶的方式處理。大概方法就是我們做乙個定時令牌器，將令牌定時放入乙個桶中，如果滿桶了，則丟棄令牌，否則就將令牌存入。在乙個請求過來的時候，我們的controller取令牌，如果取到了，就處理請求，如果取不到，直接返回失敗。示意圖如下：
3.服務解耦
服務解耦最典型的例子就是訂單的處理。我們知道，乙個訂單新建成功以後，我們往往需要呼叫比如：發起支付，簡訊通知服務等等。但是隨著業務的發展，業務邏輯原來越複雜，我們可能又新增了諸如大資料統計模組等服務。傳統的方式就是我們做訂單的同學需要重新修改邏輯，來對應新增的服務。但是通過mq系統的訂閱方式，我們只需要將訂單訊息發布出去，所有需要消費訂單處理的服務訂閱訂單訊息服務就可以了。這樣新增的服務不再需要修改訂單的邏輯，達到解耦的目的。
總結通過上面的說明，我們發現mq系統在分布式系統中的應用還是非常廣泛的。所以，如何在分布式框架中用好乙個mq系統，也是我們所必須了解熟悉的。好的mq使用可以達到事半功倍的效果。對於mq系統的使用，我也僅僅是在工作中使用過一點點的功能。後續我會將我在使用mq系統中遇到的一些問題一一說明一下，希望能對看到的人有所幫助。
什麼樣的公司需要高手，什麼樣的公司需要普通水平員工
觀點一 小公司需要全是高手，大公司需要少量高手和大量的普通水平的職員 兩三個人的專案組，什麼都要幹，什麼事情都要那兩三個人幹，個個都是全能多面手。大公司是現代化管理，高度分工，只需要會一項技術即可。員工大多數是流水線上的裝配工，技術要求低。觀點二 差公司需要高手，好公司需要普通員工。差公司，指的是沒...
我們需要什麼樣的測試？
左耳朵耗子發表了 我們需要全職的qa嗎？後，一石激起千重浪，贊成者有之，激烈反對者有之 有人說文中對qa的定義不對，還有人說以偏概全 的確，在需不需要專職的qa角色這個問題上，很難用乙個簡單的 需要 或 不需要 來回答。前兩天我寫了一篇對該文的回應文章，但由於文章寫就得比較倉促，很多觀點來不及完整表...
我們需要什麼樣的計算
本文選自 讓雲觸手可及 微軟雲計算實踐指南 一書 我們需要什麼樣的計算 我認為全球電腦市場的規模大約為5臺。ibm創始人托馬斯 j 沃森 thomas j.watson 1943 當我們站在微軟美國芝加哥資料中心一層的時候，資料中心管理人員告訴我這一層有好幾萬臺計算機，但是我們一台也沒看到。這是我見...