丨解決一個(gè)互斥問(wèn)題系統(tǒng)并發(fā)用戶數(shù)提升了10倍

優(yōu)化業(yè)務(wù)中的互斥鎖，以及是如何提升業(yè)務(wù)RPS（Requestspersecond，請(qǐng)求吞吐量）性能指標(biāo)10倍以上的，從而幫助你全面地了解分析與優(yōu)化互斥鎖的詳細(xì)過(guò)程。以優(yōu)化掉，而哪些場(chǎng)景下不可以。并且你還會(huì)掌握一種手動(dòng)實(shí)現(xiàn)事務(wù)的機(jī)制（作回滾機(jī)制），來(lái)替代業(yè)務(wù)中互斥鎖的，進(jìn)一步來(lái)幫助優(yōu)化提升軟件的性能。這個(gè)性能優(yōu)化案例的業(yè)務(wù)場(chǎng)景是這樣的：用戶給表單提交一條記錄，在這條記中會(huì)可見(jiàn)，在該業(yè)務(wù)中使用了一個(gè)Redis鎖來(lái)實(shí)現(xiàn)互斥，從而實(shí)現(xiàn)了被加鎖的業(yè)務(wù)邏輯執(zhí)字段不重復(fù)檢測(cè)：檢查插入的字段值在數(shù)據(jù)庫(kù)中是否有重復(fù)的情況出現(xiàn)，如果出現(xiàn)重復(fù)其他操作：即用戶提交記錄的過(guò)程中一些關(guān)鍵業(yè)務(wù)操作，其特點(diǎn)是不能被拆分執(zhí)行，也不能被回滾。如果操作成功的話，就會(huì)執(zhí)行下一步的操作，否則也會(huì)直接退出。所有字段插入除此之外，在優(yōu)化前的代碼實(shí)現(xiàn)中，需要進(jìn)行重復(fù)性校驗(yàn)的字段都會(huì)記錄在Redis中。所以，圖中的操作1、操作3都是基于Redis來(lái)實(shí)現(xiàn)的。那么在看完這個(gè)業(yè)務(wù)實(shí)現(xiàn)邏輯圖之后，你可能會(huì)比較好奇：什么不使用關(guān)系數(shù)據(jù)庫(kù)中的字段唯一性檢測(cè)機(jī)制來(lái)實(shí)現(xiàn)呢？其實(shí)這是因?yàn)?，在這個(gè)業(yè)務(wù)系統(tǒng)中有大約0則可能都不一樣，而且用戶還可以隨意修改這個(gè)規(guī)則。所以，這個(gè)系統(tǒng)在設(shè)計(jì)實(shí)現(xiàn)的時(shí)Redis比較簡(jiǎn)單，而且是按照單個(gè)表單來(lái)進(jìn)行加鎖的，所以在因此，問(wèn)題在第22講中，我們已經(jīng)學(xué)習(xí)過(guò)加鎖的計(jì)算邏輯屬于串行資源，這是系統(tǒng)中潛在的性能在這個(gè)中，因?yàn)長(zhǎng)ock和Unlock是采用Redis的互斥鎖來(lái)實(shí)現(xiàn)的，它們所使用的Redis的script實(shí)現(xiàn)如圖中所示，通過(guò)在真實(shí)系統(tǒng)中進(jìn)量，其中Locktime+Unlocktime的操作時(shí)間之和在3ms左右。 執(zhí)行開(kāi)銷為30ms左右，那么對(duì)應(yīng)的MaxRPS=1s/(3ms+30ms)，也就是大30RPS左0MaxRPS300RPS因此到這里，在這個(gè)性能優(yōu)化案例中，我們經(jīng)過(guò)測(cè)量加鎖的計(jì)算邏輯執(zhí)行時(shí)間為30RPS，然后根據(jù)上面的，我們計(jì)算出的最大RPS值也為30RPS左右，這與真實(shí)的性能測(cè)試針對(duì)這個(gè)業(yè)務(wù)案例，你應(yīng)該也能發(fā)現(xiàn)一個(gè)明顯的特點(diǎn)：絕大多數(shù)情況下，并不會(huì)出現(xiàn)并發(fā)提交相同字段值的情況。也就是說(shuō)，如果這個(gè)業(yè)務(wù)邏輯沒(méi)有增加互斥鎖，在.9%下業(yè)務(wù)邏輯也是正確的。所以，針對(duì)這種場(chǎng)景，我們就可以采用手動(dòng)實(shí)現(xiàn)事務(wù)機(jī)制，來(lái)優(yōu)化掉業(yè)務(wù)代碼中的互斥鎖，來(lái)提升請(qǐng)求吞吐量的性能。而這里我們已經(jīng)知道，在這個(gè)案例中，使用互斥鎖解決的問(wèn)題是判斷字段不重復(fù)和段插入操作的原子性問(wèn)題。所以說(shuō)，我們其實(shí)可以考慮采用一些優(yōu)化機(jī)制，來(lái)單獨(dú)實(shí)現(xiàn)這兩個(gè)操作組合的原子性。實(shí)際上，原來(lái)的Redis使用s的Pipeline保證這兩步操作組合的原子性，從而不會(huì)被其他Redis操作干擾到。這樣針對(duì)接下來(lái)的其他操作（也就是用戶提交數(shù)據(jù)過(guò)程中的一些不可拆分的關(guān)鍵業(yè)務(wù)操。另了實(shí)務(wù)的和能我們要字段時(shí)，記錄前的狀態(tài)和插入后的變更狀態(tài)，從而就可以實(shí)現(xiàn)失敗后的回滾機(jī)制。但是，我最后在實(shí)現(xiàn)時(shí)并沒(méi)有采納，這背后其實(shí)有很多的原因。比方說(shuō)，使用MongoDB的事務(wù)需要進(jìn)行數(shù)據(jù)遷移，而且需要升級(jí)系統(tǒng)的MongoDB集群的數(shù)據(jù)庫(kù)版本等，以及使用Redis事務(wù)機(jī)制的代碼實(shí)現(xiàn)并不友好，等等。不過(guò)這里有一個(gè)最重要的原因就是，不管是使用RedisDB的時(shí)間，拉長(zhǎng)到了步驟“作結(jié)束之后，而這樣就顯著增大了事務(wù)失敗的概率。所以最后，我們采用前面這種優(yōu)化后的實(shí)現(xiàn)機(jī)制，因?yàn)槿コ嘶コ怄i，所以用戶間的提交Pipelne操作會(huì)排隊(duì)處理，而由Pipele的執(zhí)行時(shí)長(zhǎng)在3msRPS，提升到了PS實(shí)現(xiàn)了性能提升超過(guò)10。同步互斥是高性能分布式系統(tǒng)設(shè)計(jì)實(shí)現(xiàn)的關(guān)鍵技術(shù)之一，而在軟件開(kāi)發(fā)的過(guò)程中，我們很容易因?yàn)樵O(shè)計(jì)或?qū)崿F(xiàn)不高效，導(dǎo)致整個(gè)軟件系統(tǒng)的性能不夠理想。所以在今天的課堂上，我通過(guò)一個(gè)真實(shí)的性能優(yōu)化案例，給你講解了業(yè)務(wù)中使用互斥鎖存在的性能問(wèn)題，包括它對(duì)請(qǐng)求吞吐量的性能影響，以及優(yōu)化互斥鎖來(lái)提升系統(tǒng)性能的方法和過(guò)程。但是，每個(gè)業(yè)務(wù)系統(tǒng)中的同步互斥問(wèn)題都存在特有的復(fù)雜性，所以你應(yīng)該學(xué)習(xí)收獲到的RedisCAS命令，有Pipelne機(jī)制，還支持t，你的思考和看法。如果覺(jué)得有收獲，也歡迎你把今天的內(nèi)容給的朋友。給需要的人，Ta訂閱后你可得