MQ使用心得

首先簡述一下個人業務場景：A系統將須要同步到第三方的報文發送到MQ，同步系統消費MQ作同步；至關於將系統業務與同步獨立拆分；

1.前期調研

技術調研： 技術這塊前期對比了開源的幾種MQ的優缺點，不過公司有本身的MQ平臺，因此就採用的公司的MQ；
業務調研： 雖然只是作同步，爲何要用到MQ呢？rest接口它不香嗎？是這樣的，在作同步的時候，須要保證順序，好比說：A報文與B報文之間，必須A報文先同步成功以後，B報文才能夠同步；不然第三方系統那邊會形成數據異常；

2.方案1-基於數據庫

業務系統側，將須要同步的報文都保存到一張表裏面，設置狀態爲未同步；而後同步平臺讀取表中未同步的報文，按報文的建立時間排序後，依次同步；
起初就是這麼設計的，在不斷的去摸索以後，發現有些問題：

1.同步平臺是多節點部署，如何去保證同步表中的一條報文不會被同步屢次？

這個問題是能夠解決的：經過version或者redis分佈式鎖；

2.如何保證報文順序？

假如如今報文爲：
3 {報文}
2 {報文}
1 {報文}
若是server1同步id=3的報文，server2同步id=2的報文；此時，server2先同步成功，server3再同步成功的時候，第三方服務同樣會致使數據錯誤；

看似能夠解決，可是若是新增一臺server就會相對比較麻煩；

3.方案2-基於MQ

MQ是會存在重複消費的行爲，因此須要在消費端作消息的冪等性，若是添加server節點，只須要在hash時，分發到不一樣的queue就能夠；
每一個queue表明一種業務類型，每種業務類型之間保證同步順序，若是須要使用全局順序的消息，則須要使用topic來完成；

看似完美的解決方案，其實還有問題：

1.若是消息在消費端處理的過程當中，忽然停服了，這條消息確定不會在MQ中丟失，由於MQ沒有收到成功響應，可是，下次服務啓動時，消費此條消息時，冪等性會將此消息攔截掉，致使消息丟失；

解決思路：保存每條消息到數據庫，並設置狀態爲消費中，當服務啓動時，經過一臺server（爲何是一臺，由於若是是多臺的話，會存在server1檢測到server2在處理正常消費中的消息）來檢查數據表中是否有消費中的記錄，若是有，則先處理消費中的記錄，處理完成後，再開始server1,server2的正常消費；

2.server1消費的比較慢，server1消費v3時，server2消費v6,v2？

若是你消費消息以後的邏輯比較簡單，可能會出現上述問題，同樣沒有保證消息的順序性；出現這種問題能夠增長你的queue隊列個數，由於消費消息時，是經過輪詢的方式來消費不一樣的queue，queue個數增長了，也提升了每一個隊列的循環時間；固然若是這樣還解決不了，那你能夠每臺server對應一個topic來處理；