後期資料庫主從架構的痛點,真的痛

猿天地發表於2021-05-22

原創:猿天地(微信公眾號ID:cxytiandi),歡迎分享,轉載請保留出處。

讀寫分離是什麼?讀寫分離的作用就不講了,如果有不瞭解的同學可以自己去搜尋資料進行了解。或者檢視我之前的文章讀寫分離

一開始的場景肯定都基於主庫去做增刪改查的操作,等後面壓力慢慢上來後才會考慮加資料庫的從節點,通過讀寫分離的方式來提高查詢的效能。

首先讀寫分離預設查詢都是走從節點的。

從我們的使用習慣或者業務的場景來說,查詢的場景是大於增刪改的。所以我們會在需要走主庫進行資料操作的業務場景下,手動去控制這條Sql要去主庫執行,這個控制的邏輯可以自己寫,也可以利用框架自帶的功能實現,就不細講了。

比如我們定義一個註解 @Master 用於標記此方法走主庫操作,然後通過Aspect可以去切換資料來源。這其實是很常見的實現方式,如果說你一開始就有從節點,就規範了這麼做是沒問題的,如果是後面新增了從節點要開始做讀寫分離,這麼做是存在問題的。

一旦這麼做的話,對於增刪改的操作沒有問題,對於查的操作可能會有問題。這個問題不是說有Bug,而是有一些體驗上的問題可能會導致Bug。大家都知道主從架構其實是存在資料延遲的問題,只要有延遲那麼就有可能出現問題。

某些業務場景下,你新增了一條資料,然後會馬上跳到詳情去,此時如果資料有延遲,到詳情的時候去查詢從節點,就查不到剛剛新增的資料,會存在這樣的問題。

解決辦法就是把所有業務場景都整理下,然後讓測試整體迴歸一遍,將需要走主庫操作的查詢方法都加上 @Master 註解,就不會有問題了。

看似沒有任何問題,其實大家忽略了一點就是時間成本問題。要整理業務場景,要整體迴歸測試,這些都是要花時間的,時間就是最大的成本。

所以我們在後期做讀寫分離的時候,基本上不會採用上面的方式去實現,因為業務功能越多,成本越高。

真正的做法是反著來,無論實現任何新功能,我們都要考慮的點就是如何讓影響最小?如何不影響之前的邏輯?

方法就是所有的老邏輯都不動,預設還是走主庫,但是我們程式中已經做了讀寫分離的功能,預設查詢就是會走從庫的,所以第一步就是要將所有查詢的Sql都發往主庫,可以通過Aspect實現。

做完了上面這一步就可以直接上線了,因為所有的操作還是走的主庫,跟以前沒有任何區別,不會影響任何老的邏輯。

現在就要考慮哪些查詢可以走從庫了,但是這個動作可以慢慢做,可以慢慢梳理。這樣就會比較輕鬆了,每個迭代我們可以梳理幾個走從庫的查詢,直接加個 @Slave 的註解讓它強制走從庫,這個場景我們梳理過,驗證過是沒問題的。就這樣慢慢的整理,直到所有老邏輯都梳理完。

好的思路能夠保證穩定性和易用性,如果有收穫那就點個讚唄!

關於作者:尹吉歡,簡單的技術愛好者,《Spring Cloud微服務-全棧技術與案例解析》, 《Spring Cloud微服務 入門 實戰與進階》作者, 公眾號猿天地發起人。

相關文章