mq裡每天有幾百萬資料堆積，在高可用場景裡怎麼有限解決這問題？

近期，好多網友提起mq積累的問題，也不知道他們是工作場景中遇到實際問題，還是說在面試過程中遇到這樣的問題，因此想知道這個問題答案。不管是哪種情況吧，那麼接下來我就以自然語言的方式與大家輕鬆的來討論一下mq相關的東西吧。

什麼是mq？

什麼是mq呢？其實相比mq這個叫法，國內好多朋友更喜歡叫訊息佇列，既然是這樣的話，那麼想必mq一定是 message queue的縮寫了，通常mq的工作方式都是委託模式，是一個生產者消費者的模式，一般順序執行的程式都是需要耗時的，如果改用使用訊息佇列的的話，就可以將一些具體處理業務的程式省略掉，直接委託給訊息佇列，然後繼續往下執行其他部分， 然後再委派另一個程序去處理訊息佇列上的內容， 因此這個過程就可以理解為生產者與消費者，生產者只負責往訊息佇列中新增內容，而消費者則負責處理訊息佇列中的內容，一個負責讓佇列壯大，一個負責讓佇列減小。

mq用於解決什麼問題？

那麼mq用於解決什麼樣的問題呢？在什麼樣的場景下比較適合使用mq呢？以我個人的語言來說，mq適合於解決那些高併發非實時的問題，舉個實際例子，比如發郵件，在程式中大量用到發郵件的話，大家都知道發郵件程式也是需要耗時的，你在執行業務程式時，執行到一半的時候，因為發郵件程式導致程式在那轉了一小會才繼續往後執行這顯然是體驗很不好的，如果再有一定併發的情況，那簡直是沒法看了，因此這種情況下就把mq用上，到發郵件的時候，不做實際發郵件動作，只是委託給訊息佇列，在佇列上加入一條訊息，然後就繼續執行，這樣的話就大大的增加了體驗的流暢度。

為了更進一步說明，再舉一個例子，就以電商的下單系統為例，做過電商的同學都知道，下單過程是相對複雜的過程，同時還用到了事務，要求資料無誤差，要同時修改好多張表，比如有訂單表，訂單商品表，庫存表，庫存日誌表，訂單日誌表等等，顯然這些複雜的計算是非常耗時的，如果多個使用者併發下單的話，顯然對系統造成巨大的壓力，如果實時計算的話也不太現實，再說了使用者下單後，還要等待漫長的物流，使用者是不會在乎延遲這幾分鐘或者說幾秒鐘不是麼？使用者下完訂單後，程式只需要告訴使用者下單成功就行，剩下的就把這部分計算業務委託給訊息佇列就OK了，然後讓消費者慢慢去消費吧。

mq為什麼會產生資料堆積？

那麼接下來咱們就探討一下，訊息佇列為什麼會產生積累？在回答這個問題之前，我做一個我自己認為比較形象的比喻吧，我認為訊息佇列就是這樣一個水池子，這個水池子有一個進水管，同時也有一個出水管，進水管負責往水池進水，出水管負責從水池往外排水，如果說進水管比較細，進水能力小，出水管比較粗，出水能力強的話，那麼是不是水池永遠都是空的，相反如果進水管很粗，進水能力很強，出水管很細，排水能力會差，那麼是不是水池的存水量越來越多，一直到最後溢位，訊息佇列也是同樣的道理，當生產者能力大於消費者的能力時（系統的併發訪問過高），勢必會造成資料積累，造成訊息佇列大量資料的堆積。

如何解決mq堆積問題？

上面已經對訊息佇列的應用場景有了說明，產生mq堆積的原因也十分明確了，那麼mq的堆積問題如何解決呢？那答案自然是增加消費者的消費能力或者降低生產者的生產能力，當然降低生產者的生產能力顯然是不現實呢，你總不能不讓使用者下單吧，使用者的行為你無法管，因此要做的只能是增加消費者的消費能力了，比如增加多個程序同時消費處理，比如有3個生產者程序在生產，可以設定10個消費者程序來消費，或者更據具體的業務場景或者高效的處理語言與演算法來增加消費者的消費能力，總之讓生產者生產能力小於消費者的消費能力，透過這種方式就可以逐漸減少訊息佇列的資料堆積了。

另外，最後要說一點，mq只是一個技術模型，與哪種計算機語言無關係，大多數語言都可以實現mq，當然有的語言會更合適一點，對於mq的生產者程式碼與mq的消費者的程式碼，這兩種程式碼完全可以是兩種不同的計算機語言，在實際應用場景中，大家根據實際的業務情況使用最合適的語言，那麼關於mq的討論就暫時聊到這裡了，接下來，關於mq你還有什麼想說的繼續在評論區進行留言。

以上所有圖片均來之網際網路

大家好，我是“上世是朵花”。如果你有什麼好的看法或者觀點可以在評論區展現你的才華，互動交流，如果想進一步瞭解我，那就關注我吧！