隨著佇列技術越來越成熟，很多公司都把mq放入其技術棧中，線上也基本都執行著該元件。接下來我們一起討論下，當使用mq後，你該如何分析線上問題？這裡給出兩個名詞解釋，「推」：指常用的rpc呼叫，「拉」：使用佇列進行訊息傳遞。
如上圖乙個普通的服務架構，圖中有多個要素，下面對這幾個要素進行詳細說明。
webserver與使用者進行互動的服務。它把使用者請求寫入mq，並從redis/db中讀取結果渲染成頁面返回給使用者。
佇列緩衝使用者請求，方便下游服務橫向擴充套件。
consumer訊息的消費者。它會有一些處理邏輯：呼叫（本例使用的rpc是thrift）下游的服務（worker）完成一些計算型任務，把最終處理結果寫入redis/db中。 consumer呼叫下游的服務有超時時間設定，如果下游服務在指定timeout時間內沒有返回結果，consumer會選擇（隨機或者順序）其它服務重試。
worker本例是一些計算型服務，會消耗cpu。
這個是典型的線上系統：某些地方使用佇列緩衝請求，但由於歷史問題、技術風險、實現複雜性高等原因又不能使每個服務都用佇列串聯。我們用這個架構進行說明，看看當出現如下問題時，會從監控上看到什麼樣的表現？系統又會有哪些違反常理的行為？而我們又該如何分析問題。
就如物理學相對論中的「運動的尺子會變短」，我們提出計算機系統中的「相對論」：對於乙個系統，當併發請求量變大時，每個請求的處理時間會變長。
我們利用「相對論」就能推導出每個二級系統都有崩潰臨界點：兩個服務a，b都遵循相對論，a呼叫b有超時重試策略；當a加大呼叫b的併發量後，b遵循「相對論」會使得每個請求的處理時間都變長。當請求量大到一定值後，b服務的處理時間會超過設定的「超時時間」，此時系統中就只有重試請求，並且每次請求都超時，這個「一定值」就是系統崩潰臨界點。
本例展示的這種情況，總體來說對外造成的影響不嚴重，系統壓力已經達到最大，接近崩潰邊緣但是沒有引發雪崩，因為還沒有造成使用者頻繁重新整理行為：橙色那條線（使用者請求速率）比較平穩。這個時候只需要增加worker的機器數即可。
這種情況分析起來稍微複雜，監控結果比較詭異。
這種情況下，通常會有兩個結論：
這兩個結論到底孰對孰錯？顯然，第二種結論是對的。
第一種為啥是錯的咧？
如果是第一種情況，系統某些地方肯定會表現出異常，諸如超時異常、cpu飆高異常，而本例中統統木有。
第二種為啥是對的咧？
遇到線上問題時最忌慌亂，人在慌亂的時候通常會採取錯誤的處理方式，加劇問題的影響面，所以理智應該排在第一位。希望每個小夥伴都不會遇到突發的線上問題，但是問題來了我們也不怕線上問題。
consumer 是推還是拉？
kafka 最初考慮的問題是，customer 應該從brokes 拉取訊息還是brokers 將消 息推送到consumer，也就是pull 還push。在這方面，kafka 遵循了一種大部分 訊息系統共同的傳統的設計 producer 將訊息推送到broker，consumer 從 broker...
ffmpeg rtmp推流 拉流 十
nginx 可以在大多數 unix linux os 上編譯執行，並有 windows 移植版。nginx 的1.20.0穩定版已經於2021年4月20日發布，一般情況下，對於新建站點，建議使用最新穩定版作為生產版本，已有站點的公升級急迫性不高。nginx 的源 使用 2 clause bsd li...
訊息推和拉的區別
對於乙個可靠的im系統，需要保證訊息的百分之百到達對端。即使是在極端情況下丟失一條訊息也是不能容忍的。乙個極其極其低概率的事件，若是放大到分布式系統中，那這個概率事件就成了必然事件。在開發測試中如果發現一次偶然的訊息丟失問題而忽略不查，那上線之後就必然會發生訊息丟失。所以作為技術，一定不能放過任何乙...