背景：
我們這里有個限購活動可以對某些商品進行機會限購，用戶可以通過積極參與平臺游戲或者購物等獲取購買機會莫鸭。今天突然收到系統(tǒng)告警吏祸，有大量異常錯誤碼瓜浸。
事故現(xiàn)象：
看了下記錄是給17萬用戶每人加了兩次購買機會拂酣，而且業(yè)務側給每個人加機會不是一次加夠秋冰，而是業(yè)務測采用每調一次接口加一次機會的形式...業(yè)務層分了8萬組數(shù)據(jù)，每組一個用戶婶熬，每組并發(fā)調兩次機會增加接口，事故造成該商家17萬會員里的埃撵，8萬多組并發(fā)里赵颅，350余名會員用戶無法正常對該活動下單（下單時候會報錯），只有極端非常近的并發(fā)會觸發(fā)這種情況暂刘，受損用戶比較少饺谬，商家還沒發(fā)現(xiàn)問題，活動所有商品就賣光了,無法購買的用戶也不會觸發(fā)下單報錯了谣拣，然后馬上我們告警中心自動郵件發(fā)來了募寨，然后在客訴之前解決了問題；
事故大概原因：
排查了一下森缠，發(fā)現(xiàn)這是一場由Mysql Read COMMIT級別+注解事務+分布式鎖拔鹰，當系統(tǒng)收到極端高并發(fā)情況(μs級)下引起的事故。 三個結合在一起產(chǎn)生的特殊bug贵涵。
下面由我細細道來
一. 業(yè)務簡單偽代碼貼一下：
/**
* 機會增加接口
XXXXXXX等符號是我手動打碼行為
*/
@Transactional(rollbackFor = Exception.class) //注意,就是這里有問題
@PostMapping("chanceAdd")
public XxxDto chanceAdd(@RequestBody xxxReq req) {
// 快速去重\快速失敗機制（借鑒AQS的addWaiter）----除此之外后面還有數(shù)據(jù)庫唯一鍵做保底持久去重
if (!redisUtils.setExNx(REPEAT_CHECK_PRE +XXX orderNo XXXXX)) {// 業(yè)務訂單號判重列肢，同一筆交易只能增加一次機會
throw new CommonException(ApplicationCode.REPEAT_SUBMIT,"重復添加機會");
}
//按人+商家+活動申請一把鎖
RLock lock = redissonClient.getLock(REPEAT_CHECK_PRE +XXX人，商家id宾茂，活動idXXXXX);
lock.lock();
try {
//活動添加記錄增加
final boolean saveRes = extChanceAddRecordService.save(ExtChanceAddRecordMapping.INSTANCE.toQuotaAddRecordPojo(req));
if (saveRes) {
//該人總機會增加,查詢是否已經(jīng)存在用戶總機會記錄
UserExtChance userExtChance = service.getUserExtChance(req.getUserId(), req.getMallId(), req.getActivityId());
if (userExtChance==null){//如果用戶購買記錄不存在
//生成用戶對該活動的總機會記錄
}else {//已存在
//對已有機會記錄做增加
}
}
} catch (Exception e) {
log.error("chanceAdd瓷马，data:{}，errorMsg:{}",req.toString(),e.getMessage());
throw new CommonException(ApplicationCode.REPEAT_SUBMIT);
} finally {
lock.unlock();
}
return new XxxDto();
}
二.錯誤原因分析
我們按照代碼線分析跨晴，模擬異常情況
- 事務開啟沒有問題
- 這里的紅鎖也可以保障分布式情況下對單人單商家單活動添加機會的串行化
- 但是假如有兩個線程A欧聘，B并發(fā)去調這個接口,可能出現(xiàn)A釋放鎖未提交事務，B獲取鎖由于A未提交的事務端盆，獲取的是A提交之前的快照怀骤，因此做出了錯誤判斷
-
至此 A，B均對于同一用戶生成了兩條總機會記錄爱谁∩古纾或者出現(xiàn)了數(shù)據(jù)覆蓋的問題（其他可能情況）。并發(fā)流程流程模擬访敌，錯誤原因分析
三.總結
本次錯誤原因是雖然我們用紅鎖保障了特定機會（(用戶凉敲，商家，活動)維度）增加的串行化，但是我們這里事務是用的注解事務導致事務在方法結束之后才提交爷抓，因此Read COMMIT級別下势决，并發(fā)情況可能讀到了未變更的數(shù)據(jù)，導致做出錯誤判斷
四.解決
改成聲明式事務蓝撇，在業(yè)務結束后提交事務或者異彻矗回滾事務，重點要在串行化結束之前（這里是獲取到紅鎖之前）完成整個事務的操作渤昌；
多虧系統(tǒng)各種告警配置....在用戶還沒發(fā)現(xiàn)之前就把問題暴露出來了虽抄，一天內完成了問題暴露，找到原因独柑，測試復現(xiàn)迈窟，開發(fā)解決，發(fā)布測試忌栅，上線车酣，刷數(shù)據(jù)，復測驗證整個流程索绪；
建議只有極簡單的事務用注解事務湖员，復雜業(yè)務還是手動比較好。
另外注意只要我方主動加鎖的一般都是咱們知道這里肯定有潛在并發(fā)問題瑞驱，在測試人員測試時候必須讓測試人員多測幾十組娘摔，確保咱們的防并發(fā)沒問題；
我們這個業(yè)務之前也讓測試人員測試了钱烟，用了30組 30qps的并發(fā)晰筛，但是由于這里確實比較偶發(fā)，所以沒出現(xiàn)問題...這次是線上出現(xiàn)了1W多組并發(fā)出現(xiàn)了問題拴袭；
