ActiveMq的順序性消費(fèi)問題怎么解決

這篇文章主要講解了“ActiveMq的順序性消費(fèi)問題怎么解決”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“ActiveMq的順序性消費(fèi)問題怎么解決”吧！

    業(yè)務(wù)的ABA問題

業(yè)務(wù)1將數(shù)據(jù)A從緩存中取到，業(yè)務(wù)B將數(shù)據(jù)A從緩存中取到并將A變成了B，然后又將B變成了A，業(yè)務(wù)1發(fā)現(xiàn)此時(shí)數(shù)據(jù)仍是A，A操作成功，盡管業(yè)務(wù)操作時(shí)成功的，但不代表整個過程就沒問題。另外，雖然順序性問題有可能帶來的結(jié)果是一致的，但是不代表這個過程中影響的其他數(shù)據(jù)就沒問題。

如圖，同一時(shí)刻庫中存入相同數(shù)據(jù)6條，但嚴(yán)謹(jǐn)邏輯只能允許庫中存在相同數(shù)據(jù)只有一條，如果此時(shí)其他業(yè)務(wù)查詢相關(guān)數(shù)據(jù)，必定會出現(xiàn)多結(jié)果返回

     設(shè)想解決方案一:原子計(jì)數(shù)

     方案:在每條數(shù)據(jù)進(jìn)行操作之前，先判斷兩次操作數(shù)據(jù)是否為同一個，即redis的kv為同一個，如果相同則此時(shí)對key進(jìn)行標(biāo)記incr，步進(jìn)1，在mq進(jìn)行消費(fèi)時(shí)，從redis中取出此key的步進(jìn)值與傳進(jìn)來的步進(jìn)值比較，按理說只需要記錄想用kv值得最后最大步進(jìn)值得操作

 Long incr = redisService.incr(key,1); Object o = redisService.getIncrValue("key"); if(o.toString().equals(vo.getIncr())){       //業(yè)務(wù)邏輯      }

結(jié)果測試:同樣會出現(xiàn)此問題。一開始想到當(dāng)前頁面為同一用戶對同一信息的操作，不會出現(xiàn)或者點(diǎn)不出如此高的并發(fā)，那不考慮接口被惡意攻擊的情況，使用jemeter進(jìn)行動態(tài)傳參結(jié)果如何呢？

每次的參數(shù)入?yún)⒆x取文件值，使每次結(jié)果為不同的操作，或者兩臺機(jī)器為同一賬戶對同一信息進(jìn)行操作，必定會產(chǎn)生網(wǎng)絡(luò)延遲造成對結(jié)果不一致的問題。

   設(shè)想解決方案二：分布式鎖

   方案：對當(dāng)前操作進(jìn)行加鎖，并保證同一值得鎖操作為同一把鎖時(shí)進(jìn)行業(yè)務(wù)處理，集群模式下對消息進(jìn)行分組，具體方案不成熟，引入redisson處理，但也疑問為了保證順序性問題引入分布式鎖的成本與性能問題，最終沒能達(dá)到理想結(jié)果。

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的順序性消費(fèi)問題怎么解決”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對ActiveMq的順序性消費(fèi)問題怎么解決這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！