文章目錄
- 前言
- rabbitMQ的使用場景
- 訊息佇列產生嚴重訊息堆積怎么處理？
- 如何應對嚴重訊息堆積呢？
- 例如有訂單訊息丟了，那就需要找出哪些訂單訊息丟了，然后重新發到佇列，
- 快速處理海量積壓訊息
- 具體問題應用場景：因硬體系統記憶體不夠（C盤記憶體只有40G），導致現在RabbitMQ里面積壓了900多萬的佇列，資料消費不過來，平臺不能正常接收資料，
- 總結
前言
實際場景：
之前平臺專案接收器只采用了tcp來接受報文資料，最近結合了下rabbitmq，來提升平臺性能，
本文主要介紹：
1.為啥要用rabbitmq，tcp的缺點，
2.rabbtimq用戶實際使用程序會遇到的問題 以及如何解決
rabbitMQ的使用場景
1.同步變異步
可以使用執行緒池解決,但是缺點很明顯:要自己實作執行緒池,并且強耦合 大多數是使用訊息佇列來解決2.低內聚高耦合:解耦----減少強依賴.
3.流量削峰—秒殺系統通過訊息佇列設定請求最大值,超過閥值的拋棄或者轉到錯誤界面
4.rabbitmq采用信道通信，不采用tcp直接通信
1).tcp的創建和銷毀開銷大，創建3次握手，銷毀4四次分手
2).高峰時成千上萬條的鏈接會造成資源的巨大浪費，而且作業系統沒秒處理tcp的數量也是有數量限制的，必定造成性能瓶頸
3).一條執行緒一條信道，多條執行緒多條信道，公用一個tcp連接，一條tcp連接可以容納無限條信道（硬碟容量足夠的話），不會造成性能瓶頸，
訊息佇列產生嚴重訊息堆積怎么處理？
1. 為什么產生訊息堆積？
大多是因為 Consumer 出問題了，沒有及時發現，或者故障恢復需要較長的時間，導致大量訊息積壓在 MQ 中，
2. 訊息堆積會有什么后果呢？
2.1 訊息被丟棄
例如 RabbitMQ 有一個訊息過期時間 TTL，過期的訊息會被扔掉，這樣訊息就徹底沒有了，
2.2 磁盤滿了
如果堆積量太大，可能導致磁盤空間不足，那么新訊息就進不來了，
2.3 海量訊息待處理
如果訊息沒過期，并且磁盤空間也夠用，那么就是產生海量訊息等待被消費，Consumer 的噩夢，
如何應對嚴重訊息堆積呢？
3.1 訊息被丟棄的情況
首先，要實作防止訊息過期問題，不應該設定過期時間，
如果就是設定了過期時間，導致了訊息丟失，怎么補救呢？
那就只能在夜深人靜，趁著訪問量最低的時候，寫一個臨時程式來補訊息了，
例如有訂單訊息丟了，那就需要找出哪些訂單訊息丟了，然后重新發到佇列，
3.2 磁盤不足的情況
系統通常都是有監控的，達到空間閾值時就會發警報，這時就要馬上處理了，
例如，在其他機器上創建臨時的訊息佇列，再寫一個臨時的 Consumer，作為訊息的中轉，把訊息積壓佇列中的訊息取出來，放到臨時佇列里面去，
快速疏散積壓的訊息，讓磁盤空間恢復正常水平，
快速處理海量積壓訊息
Consumer 恢復正常之后，面對堆積如山的訊息，怎么處理呢？
如何按照之前正常情況處理的話，猴年馬月才能消費完，此程序中還有新訊息在不斷進來，
例如，積壓了 100 萬條，有 3 個 Consumer，每一個每秒能處理 200 條，3 個 Consumer 每秒一共能處理 600 條，
大概需要一個多小時才能處理完，
這一個多小時又會積壓多少新的訊息呢？
所以正常處理肯定不行，需要提速，
例如 Kafka，這個訊息積壓的 Topic 有 3 個 Partition，那最多就能用 3 個 Consumer，所以增加 Consumer 沒有用，
還是可以使用臨時佇列的方式，
新建一個 Topic，設定為 20 個 Partition
Consumer 不再處理業務邏輯了，只負責搬運，把訊息放到臨時 Topic 中
這 20 個 Partition 可以有 20個 Consumer 了，它們來處理原來的業務邏輯，
這 20 個 Consumer 每秒一共能處理 4000 條了，這樣幾分鐘就可以處理完積壓的 100 萬條，
這幾分鐘新來的訊息也不會太多，所以很快就可以恢復正常水平，之后，再把整體結構恢復為原來的形式，
具體問題應用場景：因硬體系統記憶體不夠（C盤記憶體只有40G），導致現在RabbitMQ里面積壓了900多萬的佇列，資料消費不過來，平臺不能正常接收資料，
作業系統為window系統
解決方案
如果你的 MQ 和 DB 承載的是關鍵業務，那么與其考慮如何善后，可能更應該關心如何防止它們（全）掛掉，通常的做法就是冗余，好讓即使其中一個或多個掛掉也不至于影響整個業務，然后想辦法讓掛掉的能自動或手動復活，冗余可以有很多級別：
- 在一臺服務器上開多個同樣的服務，應對一個服務掛了的場景
- 部署多臺服務器跑同樣的服務，應對一臺服務器掛了的場景
- 在同一個地區部署多個機房，應對一個機房停電等場景
- 在多個地區部署機房，應對一個地區的所有機房被摧毀（比如地震）……
目前是另開一臺服務器做備用方案，計劃先由客戶這邊把原有的40G磁盤擴容到50G，保證這幾天能正常接收資料先，然后下周一開始 先對舊資料庫系統做資料備份，備份完成之后，再把原有的服務器做相應的擴容調整，改成linux的作業系統
風險：畢竟是2個系統，會丟失部分資料
總結
小結一下，訊息積壓還是比較麻煩的，最好是提前防范，做好硬體和訊息系統的健康監控，如果出現訊息丟失，就要人工查找丟失的訊息，然后補上，在消費不過來的時候，可以考慮使用臨時佇列作為中轉，提升處理能力，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/293044.html
標籤：其他