溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“ActiveMq的順序性消費問題怎么解決”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“ActiveMq的順序性消費問題怎么解決”吧！
業務的ABA問題
業務1將數據A從緩存中取到，業務B將數據A從緩存中取到并將A變成了B，然后又將B變成了A，業務1發現此時數據仍是A，A操作成功，盡管業務操作時成功的，但不代表整個過程就沒問題。另外，雖然順序性問題有可能帶來的結果是一致的，但是不代表這個過程中影響的其他數據就沒問題。
如圖，同一時刻庫中存入相同數據6條，但嚴謹邏輯只能允許庫中存在相同數據只有一條，如果此時其他業務查詢相關數據，必定會出現多結果返回
設想解決方案一:原子計數
方案:在每條數據進行操作之前，先判斷兩次操作數據是否為同一個，即redis的kv為同一個，如果相同則此時對key進行標記incr，步進1，在mq進行消費時，從redis中取出此key的步進值與傳進來的步進值比較，按理說只需要記錄想用kv值得最后最大步進值得操作
Long incr = redisService.incr(key,1); Object o = redisService.getIncrValue("key"); if(o.toString().equals(vo.getIncr())){ //業務邏輯 }
結果測試:同樣會出現此問題。一開始想到當前頁面為同一用戶對同一信息的操作，不會出現或者點不出如此高的并發，那不考慮接口被惡意攻擊的情況，使用jemeter進行動態傳參結果如何呢？
每次的參數入參讀取文件值，使每次結果為不同的操作，或者兩臺機器為同一賬戶對同一信息進行操作，必定會產生網絡延遲造成對結果不一致的問題。
設想解決方案二：分布式鎖
方案：對當前操作進行加鎖，并保證同一值得鎖操作為同一把鎖時進行業務處理，集群模式下對消息進行分組，具體方案不成熟，引入redisson處理，但也疑問為了保證順序性問題引入分布式鎖的成本與性能問題，最終沒能達到理想結果。
public Boolean tryLock(String lockKey, TimeUnit unit, int waitTime, int leaseTime) { RLock lock = redissonClient.getLock(lockKey); try { return lock.tryLock(waitTime,unit); } catch (Exception e) { return false; } }
感謝各位的閱讀，以上就是“ActiveMq的順序性消費問題怎么解決”的內容了，經過本文的學習后，相信大家對ActiveMq的順序性消費問題怎么解決這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
