消息丟失
消息發送出去，由於網絡問題沒有抵達服務器
1.做好容錯方法(try-catch)，發送消息可能會網絡失敗，失敗後要有重試機制，可記錄到系統數據庫，採用定期掃描重發的方式。
2.做好日誌記錄，每個消息狀態是否都被服務器收到都應該被記錄
3.做好定期重發，如果消息沒有發送成功，定期去數據庫掃描未成功的消息進行重發
消息抵達Broker，Broker要將消息寫入磁盤纔算成功，此時Broker尚未持久化完成，宕機。
publisher必須加入確認回調機制，確認成功的消息，修改數據庫消息狀態
自從ACK狀態下，消費者收到消息，但沒來得及消費便宕機
一定開啓手動ACK，消息成功才移除，失敗或者沒來得及處理就noACK並重新入隊。
消息重複
消息消費成功，事務已經提交，ack時，機器宕機，導致沒有ack成功，Broker的消息重新由unack-> ready，併發送給其他消費者。
消息消費失敗，由於重試機制，自動又將消息發送出去。
成功消費，ACK時宕機，消息由unack變爲ready，Broker又重新發送
消費者的業務消費接口應該設計成冪等性的，比如扣庫存工作單的狀態標誌
使用 防重表(redis, mysql) 唯一索引，發送消息每一個都有業務的唯一標識，處理過就不用再處理。
RabbitMQ的每一個消息都有redelivered字段，可以獲取消息是否是被重新投遞的。
消息積壓
消費者宕機積壓
消費者消費能力不足積壓
發送者發送流量太大
上線更多的消費者，進行正常消費。
上線專門的隊列消費服務，將消息先批量取出來，記錄數據庫，離線慢慢處理。