問題描述

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

需求

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

尋找解決方案

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

• 使用緩存分擔(dān)數(shù)據(jù)庫壓力
• 對查詢數(shù)據(jù)庫過程做優(yōu)化

緩存方案

更新策略

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

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

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

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

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

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

緩存架構(gòu)

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

同時(shí)為了解決緩存刪除失敗的問題，當(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è)置對應(yīng)的索引或聯(lián)合索引
• 通過了解業(yè)務(wù)場景，看看能否將一些小SQL合并成大SQL

通過本文的介紹，我們可以看到，優(yōu)化慢查詢并不一定需要對程序代碼進(jìn)行復(fù)雜的修改。通過巧妙地運(yùn)用緩存和SQL優(yōu)化手段，我們可以達(dá)到相同或者更好的效果。在實(shí)際的開發(fā)中，我們應(yīng)該繼續(xù)探索和研究這些優(yōu)化方法，以提高程序的效率和穩(wěn)定性。

到此這篇關(guān)于通過緩存+SQL修改優(yōu)雅地優(yōu)化慢查詢的文章就介紹到這了,更多相關(guān)優(yōu)化慢查詢內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論