公司最近有分表分庫的需求，所以整理一下分表分庫的解決方案以及相關問題。
1.sharding-jdbc（sharding-sphere）
優點：
1.可適用於任何基於java的ORM框架,如:JPA、Hibernate、Mybatis、Spring JDBC Template,或直接使用JDBC
2.可基於任何第三方的數據庫連接池,如:DBCP、C3P0、Durid等
3.分片策略靈活,可支持等號、between、in等多維度分片,也可支持多分片鍵。
4.SQL解析功能完善,支持聚合、分組、排序、limit、or等查詢,並支持Binding Table以及笛卡爾積表查詢。
5.性能高,單庫查詢QPS為原生JDBC的99.8%,雙庫查詢QPS比單庫增加94%。
缺點：
1.理論上可支持任意實現JDBC規范的數據庫。目前僅支持mysql
2.維護會比較麻煩，需要逐個項目的修改配置。不能進行跨庫連接，代碼需要進行改造。
3.在擴展數據庫服務器時需要考慮一致性哈希問題，或者采用分片鍵局部取模方式，也難免要進行部分的數據遷移。
2.mycat
優點：
1.支持Mysql集群，可以作為Proxy使用
2.支持JDBC連接ORACLE、DB2、SQL Server，將其模擬為MySQL Server使用
3.自動故障切換，高可用性
4.支持讀寫分離，支持Mysql雙主多從，以及一主多從的模式 ，支持全局表，數據自動分片到多個節點，用於高效表關聯查詢
5.支持獨有的基於E-R 關系的分片策略，實現了高效的表關聯查詢
6.多平台支持，部署和實施簡單
缺點：
1.mycat不支持二維路由，僅支持單庫多表或多庫單表 由於自定義連接池，這樣就會存在mycat自身維護一個連接池，MySQL也有一個連接池，任何一個連接池上限都會成為性能的瓶。
3.tidb
優點：
1 .高度兼容 MySQL 大多數情況下，無需修改代碼即可從 MySQL 輕松遷移至 TiDB，分庫分表后的 MySQL 集群亦可通過 TiDB 工具進行實時遷移。
2.水平彈性擴展 通過簡單地增加新節點即可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕松應對高並發、海量數據場景。
3.分布式事務 TiDB 100% 支持標准的 ACID 事務。
4. 真正金融級高可用 相比於傳統主從 (M-S) 復制方案，基於 Raft 的多數派選舉協議可以提供金融級的 100% 數據強一致性保證，且在不丟失大多數副本的前提下，可以實現故障的自動恢復 (auto-failover)，無需人工介入。
5 .一站式 HTAP 解決方案 TiDB 作為典型的 OLTP 行存數據庫，同時兼具強大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP解決方案，一份存儲同時處理OLTP & OLAP無需傳統繁瑣的 ETL 過程。
6.雲原生 SQL 數據庫 TiDB 是為雲而設計的數據庫，同 Kubernetes深度耦合，支持公有雲、私有雲和混合雲，使部署、配置和維護變得十分簡單。
缺點： 該項目較新，還沒有經過大量的生產環境檢驗，可能會存在一定的風險。
不適用場景：
(1) 單機 MySQL 能滿足的場景也用不到 TiDB。
(2) 數據條數少於 5000w 的場景下通常用不到 TiDB，TiDB 是為大規模的數據場景 設計的。
(3)如果你的應用數據量小（所有數據千萬級別行以下），且沒有高可用、強一致性或 者多數據中心復制等要求，那么就不適合使用 TiDB。
下面詳細講一下mycat，因為部署和對系統的改造量相對較小，但實測mycat的網絡消耗和線程池的問題對性能的消耗還是挺嚴重的，所以還是根據現有情況選擇。
mycat
1.架構
如圖所示：MyCAT使用Mysql的通訊協議模擬成了一個Mysql服務器，並建立了完整的Schema（數據庫）、Table （數據表）、User(用戶)的邏輯模型，並將這套邏輯模型映射到后端的存儲節點DataNode（MySQL Instance）上的真實物理庫中，這樣一來，所有能使用Mysql的客戶端以及編程語言都能將MyCAT當成是Mysql Server來使用，不必開發新的客戶端協議。
2.工作原理
Mycat的原理中最重要的一個動詞是“攔截”，它攔截了用戶發送過來的SQL語句，首先對SQL語句做了一些特定的分析：如分片分析、路由分析、讀寫分離分析、緩存分析等，然后將此SQL發往后端的真實數據庫，並將返回的結果做適當的處理，最終再返回給用戶。
當Mycat收到一個SQL時，會先解析這個SQL，查找涉及到的表，然后看此表的定義，如果有分片規則，則獲取到SQL里分片字段的值，並匹配分片函數，得到該SQL對應的分片列表，然后將SQL發往這些分片去執行，最后收集和處理所有分片返回的結果數據，並輸出到客戶端。以select * from Orders where prov=?語句為例，查到prov=wuhan，按照分片函數，wuhan返回dn1，於是SQL就發給了MySQL1，去取DB1上的查詢結果，並返回給用戶。
3.分片策略(分表分庫)
MyCAT通過定義表的分片規則來實現分片，每個表格可以捆綁一個分片規則，每個分片規則指定一個分片字段並綁定一個函數，來實現動態分片算法。
1、Schema：邏輯庫，與MySQL中的Database（數據庫）對應，一個邏輯庫中定義了所包括的Table。
2、Table：表，即物理數據庫中存儲的某一張表，與傳統數據庫不同，這里的表格需要聲明其所存儲的邏輯數據節點DataNode。在此可以指定表的分片規則。
3、DataNode：MyCAT的邏輯數據節點，是存放table的具體物理節點，也稱之為分片節點，通過DataSource來關聯到后端某個具體數據庫上
4、DataSource：定義某個物理庫的訪問地址，用於捆綁到Datanode上
4.分片規則
1.分片枚舉 通過在配置文件中配置可能的枚舉 id，自己配置分片，本規則適用於特定的場景，比如有些業務需要按照省份或區縣來做保存，而全國省份區縣固定的，這類業務使用本條規則.
2.固定分片 hash 算法 本條規則類似於十進制的求模運算，區別在於是二進制的操作,是取 id 的二進制低 10 位，即 id 二進制 &1111111111。 此算法的優點在於如果按照 10 進制取模運算，在連續插入 1-10 時候 1-10 會被分到 1-10 個分片，增大了插入的事務控制難度，而此算法根據二進制則可能會分到連續的分片，減少插入事務事務控制難度。
3.按日期分片 此規則為按天分片。 按單月小時拆分 此規則是單月內按照小時拆分，最小粒度是小時，可以一天最多 24 個分片，最少 1 個分片，一個月完后下月從頭開始循環。每個月月尾，需要手工清理數據。 4.截取數字 hash 解析 此規則是截取字符串中的 int 數值 hash 分片。 5.日期范圍 hash 分片 思想與范圍求模一致，當由於日期在取模會有數據集中問題，所以改成 hash 方法。 先根據日期分組，再根據時間 hash 使得短期內數據分布的更均勻。 優點可以避免擴容時的數據遷移，又可以一定程度上避免范圍分片的熱點問題。要求日期格式盡量精確些，不然達不到局部均勻的目的
6.一致性 hash 一致性哈希主要應用於分布式集群對機器添加、刪除的管理 1 按照常用hash算法將要管理的對象映射到一個2^32-1的閉合環形上 2 按照常用hash算法將機器映射也映射到此閉合環形上 3 以順時針計算，將要管理的對象納入離自己最近的機器上
4.刪除節點時，該機器存儲的對象按照順時針就近原理分配到臨近機器上
5.增加節點時，按照哈希算法獲得機器hash值，然后把臨近對象分配到該節點
6. 通過虛擬節點方式，增加hash環節點的密集度，保障平衡性 特性: 1 平衡性：各節點的對象個數相對均衡 2 單調性：新對象加入時不影響原對象的存儲位置 3 分散性：相同內容會被分散到相同節點 4 負載：同一個節點不能被不同用戶映射不同內容
5.讀寫分離
數據庫讀寫分離對於大型系統或者訪問量很高的互聯網應用來說，是必不可少的一個重要功能。對於MySQL來說，標准的讀寫分離是主從模式，一個寫節點Master后面跟着多個讀節點，讀節點的數量取決於系統的壓力，通常是1-3個讀節點的配置 Mycat讀寫分離和自動切換機制，需要mysql的主從復制機制配合。
6.mysql主從復制
1、主DB server和從DB server數據庫的版本一致
2、主DB server和從DB server數據庫數據一致[ 這里就會可以把主的備份在從上還原，也可以直接將主的數據目錄拷貝到從的相應數據目錄]
3、主DB server開啟二進制日志,主DB server和從DB server的server_id都必須唯一
7.mycat分布式事務解決方案
准備階段：事務協調者(事務管理器)給每個參與者(資源管理器)發送准備消息，每個參與者要么直接返回失敗(如權限驗證失敗)，要么在本地執行事務，寫本地的redo和undo日志但不提交，可以進一步將准備階段分為以下三個步驟： 1）協調者節點向所有參與者節點詢問是否可以執行提交操作(vote)，並開始等待各參與者節點的響應。 2）參與者節點執行詢問發起為止的所有事務操作，並將Undo信息和Redo信息寫入日志。 3）各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返回一個”同意”消息；如果參與者節點的事務操作實際執行失敗，則它返回一個”中止”消息。 提交階段：如果協調者收到了參與者的失敗消息或者超時，直接給每個參與者發送回滾(Rollback)消息，否則發送提交(Commit)消息，參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。 二階段提交所存在缺點的： 1）同步阻塞問題，執行過程中所有參與節點都是事務阻塞型的，當參與者占有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態。 2）單點故障，由於協調者的重要性一旦協調者發生故障參與者會一直阻塞下去。 3）數據不一致，在二階段提交的階段二中，當協調者向參與者發送commit請求之后，發生了局部網絡異常或者在發送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求，而在這部分參與者接到commit請求之后就會執行commit操作，但是其他部分未接到commit請求的機器則無法執行事務提交，於是整個分布式系統便出現了數據部一致性的現象。
8.mycat不適用場景
1.非分片字段查詢 如果該分片字段選擇度高，也是業務常用的查詢維度，一般只有一個或極少數個DB節點命中（返回結果集）。示例中只有3個DB節點，而實際應用中的DB節點數遠超過這個，假如有50個，那么前端的一個查詢，落到MySQL數據庫上則變成50個查詢，會極大消耗Mycat和MySQL數據庫資源。
2.分頁排序 但Mycat向應用返回的結果集取決於哪個DB節點最先返回結果給Mycat。如果Mycat最先收到DB1節點的結果集，那么Mycat返回給應用端的結果集為 [0,1]，如果Mycat最先收到DB2節點的結果集，那么返回給應用端的結果集為 [5,6]。也就是說，相同情況下，同一個SQL，在Mycat上執行時會有不同的返回結果。
3.任意表JOIN 無法跨庫join
4.分布式事務 Mycat並沒有根據二階段提交協議實現 XA事務，而是只保證 prepare 階段數據一致性的 弱XA事務