如何通過(guò)緩存+SQL修改優(yōu)化慢查詢

本篇內(nèi)容介紹了“如何通過(guò)緩存+SQL修改優(yōu)化慢查詢”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

問(wèn)題描述

單例數(shù)據(jù)庫(kù)模式中，后端高并發(fā)請(qǐng)求多（讀多寫少），導(dǎo)致數(shù)據(jù)庫(kù)壓力過(guò)大，關(guān)鍵接口響應(yīng)變慢，嚴(yán)重影響體驗(yàn)。

需求

減少接口的響應(yīng)時(shí)間。

尋找解決方案

由于問(wèn)題主要處在數(shù)據(jù)庫(kù)壓力過(guò)大的情況，采用兩種優(yōu)化思路優(yōu)化查詢過(guò)程：

• 使用緩存分擔(dān)數(shù)據(jù)庫(kù)壓力

• 對(duì)查詢數(shù)據(jù)庫(kù)過(guò)程做優(yōu)化

緩存方案

更新策略

使用Redis，雖然可以很好地減少數(shù)據(jù)庫(kù)的壓力，但是同時(shí)在高并發(fā)的情況下，容易出現(xiàn)數(shù)據(jù)不一致的情況，尤其是在更新數(shù)據(jù)的時(shí)候。

最常見的導(dǎo)致不一致的原因是雙寫操作，即高并發(fā)情況下短時(shí)間內(nèi)對(duì)數(shù)據(jù)庫(kù)進(jìn)行兩次寫操作。為了最小程度地出現(xiàn)這種情況，緩存在更新策略上采用先更新數(shù)據(jù)庫(kù)后刪除緩存的方式。

對(duì)于雙寫問(wèn)題，在最壞情況下，寫請(qǐng)求A在更新數(shù)據(jù)庫(kù)后，被寫請(qǐng)求B先一步更新數(shù)據(jù)庫(kù)+刪除緩存，然后A請(qǐng)求才刪除緩存，也不會(huì)導(dǎo)致后續(xù)請(qǐng)求讀取到錯(cuò)誤的值。

對(duì)于先寫后讀，在最壞情況下，寫請(qǐng)求A在更新數(shù)據(jù)庫(kù)后，被讀請(qǐng)求C先一步在緩存讀取到舊值，然后A請(qǐng)求才刪除緩存，也只會(huì)影響這段時(shí)間的讀請(qǐng)求，刪除后的讀請(qǐng)求不影響。

對(duì)比其他方案（先更新緩存后更新數(shù)據(jù)庫(kù)、先刪除緩存后更新數(shù)據(jù)庫(kù)、先更新數(shù)據(jù)庫(kù)后更新緩存）在最壞情況下會(huì)導(dǎo)致的錯(cuò)誤（更新數(shù)據(jù)庫(kù)失敗導(dǎo)致緩存是未知值、雙寫后數(shù)據(jù)庫(kù)變成舊值、更新緩存失敗導(dǎo)致緩存保存舊值）要好得多。

但是先更新數(shù)據(jù)庫(kù)后刪除緩存也不是完全安全的，除了上文提到的高并發(fā)下先寫后讀可能讀到舊值外，若刪除緩存失敗，也有可能導(dǎo)致讀到舊值。處理方法見下文。

緩存架構(gòu)

添加緩存，勢(shì)必要修改業(yè)務(wù)代碼，如何配置架構(gòu)才能把對(duì)代碼的入侵性講到最低，這里使用監(jiān)聽數(shù)據(jù)庫(kù)binlog的方法，使用中間件監(jiān)聽mysql的日志，當(dāng)出現(xiàn)操作時(shí)，通知專門的模塊來(lái)修改緩存，做到修改緩存和業(yè)務(wù)邏輯解耦。

同時(shí)為了解決緩存刪除失敗的問(wèn)題，當(dāng)發(fā)生失敗時(shí)，發(fā)送消息至消息隊(duì)列傳遞給專門的模塊進(jìn)行重試刪除。

中間件選擇：

• 緩存使用Redis

• 監(jiān)聽binlog使用canal

• 消息隊(duì)列使用RocketMQ

架構(gòu)如下所示：

SQL優(yōu)化

查詢優(yōu)化可以從兩個(gè)方面進(jìn)行：

• 根據(jù)高頻的查詢case，遵循最左匹配原則，設(shè)置對(duì)應(yīng)的索引或聯(lián)合索引

• 通過(guò)了解業(yè)務(wù)場(chǎng)景，看看能否將一些小SQL合并成大SQL

“如何通過(guò)緩存+SQL修改優(yōu)化慢查詢”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！