講一些題外話,沒興趣的可直接跳過.

首先非常感謝並宣傳一波常常被罵的狗血淋頭卻又覺得異常可愛的暗滅大人.   教會我的太多太多, 但最重要的也是和這篇文章有關聯的就是讓我明白該如何去思考問題, 定位問題, 解決問題.

首先介紹下背景,  這邊做的是一對多(包括一對一)的私信功能,那麼自然而然對應的就需要幾個api其中包括

1.傳送私信

2.略略略

表結構如下:

groups表 

用於儲存使用者組資訊, 使用者組是由兩個或多個使用者組成的

user_group_relations表

因為一個使用者可能有多個組所以使用一張表來儲存使用者與組的關係

messages表

用於儲存私信

對應業務層介面如下:

/**
     *
     * 將訊息儲存到db
     * 儲存成功後更新對應userGroup表的latestMessageId
     * 更新userGroupRelation表中對應使用者的未讀訊息數量
     *
     * 以上三步操作必須保證原子性, 因此執行在一個事物中.
     * @param receiverIds 接收訊息使用者id
     * @param message 訊息實體
     * @return 成功建立後的message實體.
     */
    Message sendMessage(List<Long> receiverIds, Message message);
 

可能各位看官會有疑問, 為何沒有senderId, senderId是通過springSecurity中的上下文獲取當前使用者id的,包含在實現中.

寫這篇部落格時才想到這樣不太好, 依賴於springSecurity,萬一不用springSecurity又得改程式碼 (記下, 馬上去重構)

簡單來說傳送一個私信需要做如下步驟

1.通過將senderId和receiverIds排序分割加密後作為group的code

2.通過code獲取Group(code對應那條記錄加s鎖)

3.messages表中有group的外來鍵, 因為使用的orm所以呼叫new出來message瞬態物件的setGroup方法, 引數為第2步中code查詢出來的結果

4.save第3步中的瞬態message物件到messages表中 (新增成功後獲取該行記錄的x鎖)

5.更新第二步中group那條記錄的latest_message_id為第4步中插入成功後的id (code對應那條記錄的x鎖)

6.更新user_group_relations中的n條unread_message_counts為+1

實現程式碼如下

 /**
     *
     * 高併發下會產生多個事物,若將{@link com.hikedu.backend.model.UserGroup#latestMessageId}的更新邏輯放置在傳送訊息邏輯中
     * 不僅影響效能, 而且會造成死鎖.
     * 鑑於上述原因, 暫不更新該冗餘欄位, 後續可採用訊息佇列的形式在訊息傳送完畢後進行更新
     *
     * @param receiverIds 接收訊息使用者id
     * @param message 訊息實體
     * @return
     */
    @Transactional(isolation = Isolation.READ_COMMITTED, rollbackFor = Throwable.class, propagation = Propagation.REQUIRED)
    @NotNull
    @Override
    public  Message sendMessage(List<Long> receiverIds, Message message) {

        //TODO 優化高併發下的效能. 目前一秒內產生400個併發請求,90%Line平均為2500, tps平均為10.2/s, error%為2.25或0
        log.info("The user {} sending a message", message.getSender().getId());
        log.info("The receiverIds is {}", receiverIds);
        log.info("The message content is {}", message.getContent());

        List<Long> copyReceiverIds = new ArrayList<>(receiverIds);
        if (message.getSender() == null) {
            throw new RuntimeException("The sender can not be null");
        }else {
            Message fullMessage;
            if (isSendMessageAllowed(copyReceiverIds, message)) {
                //將獲取UserGroup的s鎖
                message = fillUpForSendMessage(copyReceiverIds, message);
                //將獲取UserGroup的s鎖和插入message的x鎖
                fullMessage = messageRepository.saveAndFlush(message);
                log.info("The inserted message id is {}", fullMessage.getId());

                //獲取userGroup的s鎖和x鎖
                userGroupRelationService.
                        addUnreadMessageCounts(receiverIds, message.getUserGroup().getId(), 1);
                return fullMessage;
            } else {
                throw new RuntimeException("The current operation not allowed, cause - unknown");
            }
        }
    }

以上是解決完死鎖後的程式碼, 其中去掉了如下userGroupService方法的呼叫

/**
     * 更新最新訊息id
     * @param userGroupIds 需要更新的使用者組id
     * @param latestMessageId 最新訊息id
     * @return 更新後的所有使用者組
     */
    List<UserGroup> changeLatestMessageId(List<Long> userGroupIds, Long latestMessageId);

以上就是整個的需求加實現方案及實現程式碼,非併發下執行ok. 

鑑於上家公司養成了對api進行壓力測試觀察併發下執行情況的習慣(再次感謝暗滅大人), 開啟jmeter開400個併發,一秒內全部發送出去.

此時,問題就是出現了, error百分率為80%多, 嚇得我趕緊檢視日誌.

Deadlock found when trying to get lock; try restarting transaction

趕緊google一波,發現是死鎖. 咦, 死鎖是啥沒遇到過啊

google一波死鎖,找到好幾篇這篇講的ok

死鎖產生的必要條件也知道了,也知道了s鎖和x鎖的定義和概念

又google找到其他人解決死鎖過程的部落格

沒啥收穫, 但是知道了怎麼去看mysql最新的死鎖日誌

也知道了怎麼閱讀mysql死鎖日誌

隨後,瘋狂操作一波,看到了dead lock 日誌

查閱以上dead lock日誌可知

事物1在等待user_groups(對應當前文章中的group)表中記錄為主鍵為2那行的x鎖, 本身不持有其他鎖 (實際持有該行記錄的s鎖)

事物2也在等待user_groups(對應當前文章中的group)表中記錄為主鍵為2那行的x鎖,本身擁有正在等待獲取x鎖那行記錄的s鎖

s鎖,x鎖的定義如下

以上定義轉載自其他部落格, 已標記為超連結.

根據s鎖x鎖的定義和當前事物持有的鎖和等待的鎖可知如下事實

1.事物1持有group表中id為2那行記錄的s鎖, 在等待x鎖

2.事物2持有group表中id為2那行記錄的s鎖,在等待x鎖

3.事物1和事物2永遠無法提交, 因為兩者均需要獲取x鎖, 又都持有s鎖, 因事物未結束,又無法釋放s鎖.

4.MySQL會介入並將其中一個事物回滾, 回滾後的事物釋放s鎖, 另一個事物能夠獲得x鎖.

so, 這就是為什麼會出現error率為80%多的原因, 那麼我們回到程式碼中看看為何會出現這種情況.

以下程式碼為會對錶進行操作的方法呼叫

userGroup = userGroupService.getByCode(userGroupCode); (獲取group表中id為2那行記錄的s鎖)

//將獲取gropup表中id為2那行記錄的s鎖和插入message的x鎖
                fullMessage = messageRepository.saveAndFlush(message);

//獲取group為2那行記錄的x鎖
userGroupService.changeLatestMessageId(savedUserGroup, fullMessage.getId());

在併發下有兩個執行緒同時進行, 因為sendMessage方法開啟了事物,因此也產生了兩個事物.

事物1執行完第一步操作後執行第二步操作, 在第三步操作執行前事物2執行了如下步驟

事物2執行完了第一步獲得了group為2那條記錄的s鎖 (此時事物1也已獲得).

有趣的事情發生了

事物1在等事物2釋放group主鍵為2那行記錄的s鎖以便獲取x鎖

事物2也在等待事物1釋放group主鍵為2那行記錄的s鎖以便獲取x鎖

最終死鎖.

那麼解決方法還是有幾個的,但是好幾個都行不通

一.將事物的粒度縮小, 也就是巢狀事物

將以上三步呼叫的方法上都啟用事物, 並對事物做如下設定

將傳播級別設定為PROPAGATION_REQUIRES_NEW

隔離界別設定為READ_COMMITTED

很傻很天正, 這樣會出現兩種情況

1.lock wait time out 鎖等待超時

因為外層的事物也就是sendMessage被掛起, sendMessage中獲取了幾行記錄的s鎖或x鎖

該事物不結束不會釋放鎖,而在其他三個獨立的事物中也需要獲取sendMessage事物中加鎖那行記錄的鎖,最終一直等啊等啊等啊等, tiem out ,game over.

2.因事物隔離級別,無法查詢到sendMessage事物中更改或新增的記錄

sendMessage這個事物中對錶中的記錄進行了更改或新增, 隨後被巢狀在sendMessage事物中的事物掛起, 掛起後執行巢狀中的事物,巢狀中的事物無法查詢到sendMessage事物中對於表進行的更改,所以,就是各種NotFoudException.

其實上述問題可以通過調整隔離級別來實現, 但是考慮到不能產生髒讀,最終放棄.

二. 強制執行緒同步

執行緒同步,也就是保證事物有序執行. 這樣是ok的, 但是不管是非併發還是併發下效能堪憂,最終放棄

三.精確定位導致死鎖的程式碼行,並考慮進行移除或優化解決死鎖 (最終解決方案)

最終定位到引起死鎖的那行程式碼如下

//獲取group為2那行記錄的x鎖
userGroupService.changeLatestMessageId(savedUserGroup, fullMessage.getId());

這步是更新group表中的冗餘欄位latest_message_id,

想到可以加入到佇列或redis快取中來非同步處理, 最終刪除該行程式碼, 趕緊瘋狂操作壓測了一波

最後各項資料還算說的過去,資料如下:

非併發請求平均響應在200ms以下

400個請求,1秒之內全部發送出去., 因為是本地所以效能太差, 但是不會死鎖. 90%Line在2250ms, tps在10條/s  error率 0%, 

同時保證了傳送私信三步操作的原子性,在異常時能夠正常回滾.

最後說下花費將近1.3小時寫這篇部落格的收穫吧.

蚊子特別喜歡我, 親了我好幾下.

剿滅蚊子2只.

note: 有哪裡講的不對的,還請各位大佬指正.