分庫分表落地解決方案

随着系統不斷的運作，當資料庫的資料開始超過千萬、上億時，mysql資料庫将承受更大的壓力。資料是企業生存的根本，資料庫的健康狀況将直接決了定企業的競争力。

解決思路

為了更好的緩解資料庫壓力，使得系統更高效的運作，落地的解決方案有：1、分庫（也叫垂直拆分，即：每個子產品對應一個單獨的資料庫）。2、分表（也叫水準拆分，即：一張表的資料拆分存儲到多張表裡）。

引入的新問題

1、資料庫分離的同時，也引入了分布式事物的問題。2、表的水準拆分的同時，也帶來了很多的挑戰，比如：分頁查詢、表資料的後續擴充、資料的存儲和檢索政策。

落地解決方案

1、分布式事物的解決方案也有很多，比如：TCC、MQ事物消息等。這裡提出方案的是事物補償，且僅有事務補償沒有復原。具體做的時候需要注意：将執行一個操作所涉及到的所有校驗條件全部提到服務編排層的最前面（包括試算）。若所有的校驗條件都通過了，則認為後續執行的業務邏輯一定是通過的。如果執行報錯，那麼，通過消息隊列做三次補償，補償仍然失敗，手工介入處理。

2、RPC調用、事物補償引入了并發場景下的接口幂等性問題，這裡給出三種解決方案是：a.樂觀鎖，ID和版本号，update version … where version

3、分表的同時帶來了資料的存儲和檢索問題，這裡給的解決方案是：a.根據業務組ID（全局配置設定唯一）取模運算，比如：10張表，那麼，就是取10的模來決定存儲的表編号，并存入路由表。業務組的ID是指一個更大的管理機關，比如：某個商戶的ID、企業的ID。b.增加路由表，根據業務組ID查找路由表，找到表編号。c.對于沒有業務組關聯的資訊，例如：使用者資訊，也是直接采用取模的計算方式。對于一些特殊場景的userId，也可以存儲到路由表裡，檢索的時候，優先檢索路由表。這裡有兩個重要的概念第一個是按照業務組ID為機關操作，第二個是根據路由表來查找表編号。