最近開發(fā)新需求，在測試環(huán)境測試和解決了兩個很有意思的問題，特此記錄一下。
- 在數(shù)據(jù)庫事務(wù)中發(fā)送MQ消息（MQ消息消費和事務(wù)提交順序不確定）
- 問題描述
如下圖所示，業(yè)務(wù)流程是在數(shù)據(jù)庫讀提交隔離級別下，首先插入數(shù)據(jù)，然后發(fā)送MQ消息。MQ消息中包含數(shù)據(jù)id，消費者拿到消息后根據(jù)id查數(shù)據(jù)庫。
由于MQ消息是在數(shù)據(jù)庫事務(wù)中發(fā)送的，所以可能會導(dǎo)致MQ發(fā)送成功，消費者開始消費MQ，但是此時生產(chǎn)者所在的事務(wù)還未提交，所以消費者根據(jù)id查不到數(shù)據(jù)，由此產(chǎn)生問題。
產(chǎn)生問題的原因
數(shù)據(jù)庫事務(wù)中的代碼順序是插入數(shù)據(jù)->發(fā)送MQ->提交事務(wù)，但是因為MQ發(fā)送后，消費者消費是異步的，所以并不能保證MQ消費和提交事務(wù)的順序，有可能提交事務(wù)在前，這種情況就沒有問題，消費者可以看到事務(wù)提交后的數(shù)據(jù)，但如果是MQ消費在前，事務(wù)提交在后，那MQ消費者是看不到未提交的事務(wù)數(shù)據(jù)的。解決方法
最簡單的方案是什么也不用做，MQ消費者消費失敗的話，重新消費或者人工接入解決，當(dāng)然這種方案也有問題，就是MQ發(fā)送成功，但是事務(wù)回滾...
或者可以把MQ發(fā)送放在事務(wù)之外，確保發(fā)送MQ的時候事務(wù)已經(jīng)提交，也是可以的，消費失敗就重新消費唄。還是不建議把發(fā)送MQ的操作放在事務(wù)里，因為可能會加大事務(wù)執(zhí)行時間，有造成大事務(wù)的風(fēng)險。
還有一種終極解決方案就是使用事務(wù)消息，在數(shù)據(jù)庫事務(wù)中發(fā)送半消息，然后事務(wù)提交后，發(fā)送消息確認(rèn)半事務(wù)消息，并提供事務(wù)回查接口。
- 消息生產(chǎn)者和消費消費者產(chǎn)生了并發(fā)修改
- 問題描述
消息生產(chǎn)者連續(xù)兩次修改數(shù)據(jù)，并兩次發(fā)送數(shù)據(jù)改動消息到消息消費者，消息消費者收到消息后，從數(shù)據(jù)庫查數(shù)據(jù)并寫入緩存，最后更新數(shù)據(jù)的is_cache字段。
邏輯流程簡單來說是這樣的：修改data.time=t1->發(fā)送MQ通知消費者將數(shù)據(jù)寫入緩存->修改data.time=t2->發(fā)送MQ通知消費者將數(shù)據(jù)寫入緩存。原來的本意是將data.time=t2的最終結(jié)果更新到緩存。但是最后發(fā)現(xiàn)，執(zhí)行完畢后，數(shù)據(jù)庫中的時間總是t1而不是期望的t2。
- 產(chǎn)生問題的原因
最終發(fā)現(xiàn)是消息消費者更新is_cache字段用的sql有問題，他并不是單獨更新指定id的is_cache字段，而是先查數(shù)據(jù)庫數(shù)據(jù)，然后修改is_cache字段，然后用數(shù)據(jù)庫數(shù)據(jù)對象更新全部字段。和問題1一樣，MQ消息消費是異步的，所以修改t1,t2的順序和消息消費的順便是不確定的，可能會產(chǎn)生這樣的順序：修改data.time=t1->發(fā)送MQ->消費MQ，加載數(shù)據(jù)庫數(shù)據(jù)data.time=t1，寫入緩存->修改data.time=t2->前面的消費者繼續(xù)執(zhí)行，寫入緩存后更新is_cahce字段，并將data.time=t1更新回去，覆蓋了data.time=t2的預(yù)期結(jié)果
最主要的還是因為消費者修改了本不屬于自己要更新的字段data.time，由此和生產(chǎn)者產(chǎn)生了數(shù)據(jù)修改競爭，相當(dāng)于多線程修改共享數(shù)據(jù)，造成了問題。
- 解決方案
消費者只修改更新data.is_cache字段，避免和消費者競爭修改共享字段，避免競爭。
