springboot based 主從數據源中間件方案

 

 

 

 

 

先定幾個原則/目標：

原則：

1.必須保證數據邏輯的一致性；

反例：剛寫了數據，（由於主從延遲）查詢不到；

2.對開發人員透明，對業務代碼無侵入性；與單數據源的業務代碼調用一致；

反例：對已有業務代碼的侵入式改動，顯示說明datasource；

3.根據調用場景自動選擇主從數據源

場景：涉及寫入，讀寫都在主庫進行。只涉及查詢，從庫查詢

反例：

    3.1寫事務調用從庫

    3.2非必要的從主庫查詢

4.給業務開發選擇的權利，能夠以最低成本的方式顯示進行數據源（類別）選擇（如annotation等）；

場景：只涉及查詢，可是業務須要，必須從主庫查詢；

5.主從數據源共存，與單數據源方案，能夠無縫切換

 

擴展目標：

6.低成本的數據源切換線程安全

反例：全局悲觀鎖,同步鎖實現

7.支持多個從庫/從庫HA

8.主數據庫不可用，從庫自動頂上

9.代碼級別上，採用spring boot starter方案

 

不考慮場景：

sharding 目前不考慮，若是須要，做單獨專題展開。

 

備忘問題：

傳播級別：

   調用者上下文顯示說明MASTER,被調用者顯示說明SLAVE; 或反過來，須要一個合理的切換機制/或者不切換；

 

傳播性能夠作以下規則：

1.若是外層爲master，則內層無論原先級別，都將提高至master級別；

2.級別只升不降

3. 同一個線程，若是不切換主從，同一分類的機器，（主要是指多個slave ）實例也不切換

4.更多的調用層級，直接遞推便可（傳播）；

 

case：

• master → slave        =>     master → master
• master → master      =>     master → master
• slave   → master       =>     slave → master
• slave  → slave           =>     slave → slave

 

Master/Slave 切換場景的幾種設定：

 

	默認Slave（性能優先）	默認Master（開發效率優先）	若是調用者未顯示說明@Master/Slave，根據事務狀態自主選擇主從； 不在傳播鏈中生成@Master/Slave	若是調用者未顯示說明@Master/Slave，根據事務狀態自主選擇主從； 在傳播鏈中生成@Master/Slave
優勢	1.分擔主庫負擔 2.儘量利用從庫，從庫只讀，HA成本低	1.現有代碼無任何改動可正常運行	1.用戶徹底控制，截斷了隱性的@Master 2.更多的@Slave場景機會	1.整個傳播鏈行爲一致，使得整個數據行爲更一致；
缺點	全部現有的服務，涉及到寫或者必須連master的場景，必須顯示標明@Master； 不然會有兩種狀況： 1.涉及寫入的時候會默認鏈接到只讀從庫，程序會報錯； 2. 非寫入動做，但可能有數據讀取的延時性問題	1.須要顯示標明@Slave，才能鏈接從庫 2.從庫利用率會較低	1.有可能業務邏輯的不一致； 例子： a.不標明@Master/Slave 的調用上下文先執行了 寫操做； b.而後調用了@Slave 的讀操做服務； a步驟寫入的數據，有可能在b操做中讀取不出來   這種場景，固然能夠經過顯示標明調用者爲 @Master 來規避；	1.對事務的狀態判斷，並不能單方面很好的決定是否選擇主從，因此通常會選擇主庫；（TODO:看是否能更好優化） 2.爲了程序運行邏輯不出異常的狀況下，而大多選擇了@Master，那麼接下來的級別都會是@Master，@Slave 的場景會很是少，從庫利用率會很低

 

項目地址：

https://github.com/leochowcomtop/db-proxy