[[399869]]

本文轉(zhuǎn)載自微信公眾號「猿天地」，作者尹吉?dú)g。轉(zhuǎn)載本文請聯(lián)系猿天地公眾號。

讀寫分離是什么?讀寫分離的作用就不講了，如果有不了解的同學(xué)可以自己去搜索資料進(jìn)行了解。

一開始的場景肯定都基于主庫去做增刪改查的操作，等后面壓力慢慢上來后才會考慮加數(shù)據(jù)庫的從節(jié)點(diǎn)，通過讀寫分離的方式來提高查詢的性能。

首先讀寫分離默認(rèn)查詢都是走從節(jié)點(diǎn)的。

從我們的使用習(xí)慣或者業(yè)務(wù)的場景來說，查詢的場景是大于增刪改的。所以我們會在需要走主庫進(jìn)行數(shù)據(jù)操作的業(yè)務(wù)場景下，手動去控制這條 Sql 要去主庫執(zhí)行，這個控制的邏輯可以自己寫，也可以利用框架自帶的功能實現(xiàn)，就不細(xì)講了。

比如我們定義一個注解 @Master 用于標(biāo)記此方法走主庫操作，然后通過 Aspect 可以去切換數(shù)據(jù)源。這其實是很常見的實現(xiàn)方式，如果說你一開始就有從節(jié)點(diǎn)，就規(guī)范了這么做是沒問題的，如果是后面新增了從節(jié)點(diǎn)要開始做讀寫分離，這么做是存在問題的。

一旦這么做的話，對于增刪改的操作沒有問題，對于查的操作可能會有問題。這個問題不是說有 Bug，而是有一些體驗上的問題可能會導(dǎo)致 Bug。大家都知道主從架構(gòu)其實是存在數(shù)據(jù)延遲的問題，只要有延遲那么就有可能出現(xiàn)問題。

某些業(yè)務(wù)場景下，你新增了一條數(shù)據(jù)，然后會馬上跳到詳情去，此時如果數(shù)據(jù)有延遲，到詳情的時候去查詢從節(jié)點(diǎn)，就查不到剛剛新增的數(shù)據(jù)，會存在這樣的問題。

解決辦法就是把所有業(yè)務(wù)場景都整理下，然后讓測試整體回歸一遍，將需要走主庫操作的查詢方法都加上 @Master 注解，就不會有問題了。

看似沒有任何問題，其實大家忽略了一點(diǎn)就是時間成本問題。要整理業(yè)務(wù)場景，要整體回歸測試，這些都是要花時間的，時間就是最大的成本。

所以我們在后期做讀寫分離的時候，基本上不會采用上面的方式去實現(xiàn)，因為業(yè)務(wù)功能越多，成本越高。

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

方法就是所有的老邏輯都不動，默認(rèn)還是走主庫，但是我們程序中已經(jīng)做了讀寫分離的功能，默認(rèn)查詢就是會走從庫的，所以第一步就是要將所有查詢的 Sql 都發(fā)往主庫，可以通過 Aspect 實現(xiàn)。

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

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

好的思路能夠保證穩(wěn)定性和易用性，如果有收獲那就點(diǎn)個贊唄!

關(guān)于作者：尹吉?dú)g，簡單的技術(shù)愛好者，《Spring Cloud 微服務(wù)-全棧技術(shù)與案例解析》, 《Spring Cloud 微服務(wù) 入門 實戰(zhàn)與進(jìn)階》作者, 公眾號猿天地發(fā)起