問題描述

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

需求

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

尋找解決方案

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

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

2. 對查詢數(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請求才刪除緩存，也不會導(dǎo)致后續(xù)請求讀取到錯(cuò)誤的值。

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

對比其他方案（先更新緩存后更新數(shù)據(jù)庫、先刪除緩存后更新數(shù)據(jù)庫、先更新數(shù)據(jù)庫后更新緩存）在最壞情況下會導(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)行：

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

2. 通過了解業(yè)務(wù)場景，看看能否將一些小SQL合并成大SQL