後期數據庫主從架構的痛點，真的痛

原創：猿天地（微信公衆號ID：cxytiandi），歡迎分享，轉載請保留出處。

讀寫分離是什麼？讀寫分離的做用就不講了，若是有不瞭解的同窗能夠本身去搜索資料進行了解。或者查看我以前的文章讀寫分離。

一開始的場景確定都基於主庫去作增刪改查的操做，等後面壓力慢慢上來後纔會考慮加數據庫的從節點，經過讀寫分離的方式來提升查詢的性能。

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

從咱們的使用習慣或者業務的場景來講，查詢的場景是大於增刪改的。因此咱們會在須要走主庫進行數據操做的業務場景下，手動去控制這條Sql要去主庫執行，這個控制的邏輯能夠本身寫，也能夠利用框架自帶的功能實現，就不細講了。

好比咱們定義一個註解 @Master 用於標記此方法走主庫操做，而後經過Aspect能夠去切換數據源。這實際上是很常見的實現方式，若是說你一開始就有從節點，就規範了這麼作是沒問題的，若是是後面新增了從節點要開始作讀寫分離，這麼作是存在問題的。

一旦這麼作的話，對於增刪改的操做沒有問題，對於查的操做可能會有問題。這個問題不是說有Bug，而是有一些體驗上的問題可能會致使Bug。你們都知道主從架構實際上是存在數據延遲的問題，只要有延遲那麼就有可能出現問題。

某些業務場景下，你新增了一條數據，而後會立刻跳到詳情去，此時若是數據有延遲，到詳情的時候去查詢從節點，就查不到剛剛新增的數據，會存在這樣的問題。

解決辦法就是把全部業務場景都整理下，而後讓測試總體迴歸一遍，將須要走主庫操做的查詢方法都加上 @Master 註解，就不會有問題了。

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

因此咱們在後期作讀寫分離的時候，基本上不會採用上面的方式去實現，由於業務功能越多，成本越高。

真正的作法是反着來，不管實現任何新功能，咱們都要考慮的點就是如何讓影響最小？如何不影響以前的邏輯？

方法就是全部的老邏輯都不動，默認仍是走主庫，可是咱們程序中已經作了讀寫分離的功能，默認查詢就是會走從庫的，因此第一步就是要將全部查詢的Sql都發往主庫，能夠經過Aspect實現。

作完了上面這一步就能夠直接上線了，由於全部的操做仍是走的主庫，跟之前沒有任何區別，不會影響任何老的邏輯。

如今就要考慮哪些查詢能夠走從庫了，可是這個動做能夠慢慢作，能夠慢慢梳理。這樣就會比較輕鬆了，每一個迭代咱們能夠梳理幾個走從庫的查詢，直接加個 @Slave 的註解讓它強制走從庫，這個場景咱們梳理過，驗證過是沒問題的。就這樣慢慢的整理，直到全部老邏輯都梳理完。

好的思路可以保證穩定性和易用性，若是有收穫那就點個讚唄！

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