前提

    本文主要介紹分散式資料庫演變歷程，以及演變過程的解決方案，沒有方案的具體實現步驟。

資料庫高可用的發展歷程

1、查詢操作比較多，利用快取，緩解資料庫的讀壓力
2、寫操作成為資料庫瓶頸，利用資料庫主從複製，在程式碼中進行讀寫分離
3、為了避免寫伺服器宕機，從而造成寫操作異常，進行主主複製
4、單臺不能在支撐系統壓力的時候，進行叢集擴充套件，通過負載均衡完成叢集均勻分擔壓力
5、為了避免宕機對系統影響，搭建高可用叢集成為關鍵。
6、MySQL的單表最多支撐5000萬，為了擴大容量，需要分庫分表

資料庫高可用解決方案

1、新增快取，緩解資料庫查操作。
快取方式有兩種，本地快取，分散式快取。
本地快取通常採用ehcache，分散式快取通常有兩種選擇，redis和memcached，關於兩者區別請移步

• 在應用層直接實現
  非常通用，簡單的解決方案，直接在應用層讀取分片規則，然後解析分片規則，根據分片規則實現切分的路由邏輯。這種方案侵入業務，但是實現比較簡單，適合快速上線，因為切分邏輯是自己開發，所以生產上的問題比較容易解決。但是這樣會讓資料庫保持連線比較多，需要考慮應用伺服器的節點數量，需要提前進行容量評估，而且對開發人員能力要求比較高。
  開源框架dbsplit就是採用這種方式。
• 通過定製JDBC協議實現
  通過定製JDBC協議，針對業務層提供與JDBC一致的介面，讓開發人員專注業務開發，不再關心分庫分表的實現，讓分庫分表在JDBC的內部實現。但是需要開發人員理解JDBC協議才能實現分庫分表邏輯。
  流程的客戶端分庫分表框架Sharding JDBC 採用這種方案。
• 通過定製ORM框架
  因為關係資料庫與面嚮物件語言之間的差距，ORM框架的廣泛使用，就有了通過定製ORM框架實現分庫分表的方案。把分片規則實現到ORM框架中或者通過ORM框架支援的擴充套件機制來實現。一般常用的是通過在Mybatis配置檔案的SQL中增加表索引的引數來實現分片。如下：

<select id="getUser" parameterType="java.util.Map" resultType="User">
    select userId,username
        from user_#{index}
    where userId = #{userId}
</select>

2、代理分片
在應用層和資料庫層增加一個代理層，把分片的路由規則配置在代理層，代理層提供對外提供與JDBC相容的介面給應用層，應用層的開發人員不用關心分片規則，只需要關心業務邏輯的實現。
這種方案讓開發人員專注於業務邏輯的實現，把分庫分表的操作留給代理層做；不足之處：增加代理層，加重了網路傳輸的負擔，還需要維護代理層，以及硬體成本。
常用代理分片實現框架有Cobar和Mycat等。
3、支援事務的分散式資料庫
OceanBase，TiDB等資料庫對外提供可伸縮的體系架構，並提供分散式事務支援，將可伸縮和分散式事務的實現包裝到分散式資料庫內部實現，對使用者透明。
使用分散式資料庫的需要綜合實際情況，不要盲目的追求技術的實現。
分庫分表的帶來弊端
1、如何保證id唯一
2、配置多資料來源
3、分散式鎖的問題
4、分散式事務的問題
當然這些問題均有解決的方式，但是也這說明了事物的兩面性。小編的公司採用的是MyCat中介軟體解決，針對分庫分表這一部分的使用小編還會在後續部落格中持續更新！

總結

    關於分散式不要一口吃個胖子，針對業務，資料，實際情況具體分析，原則就是兵來將擋水來土掩，相信問題終會有解決方案的。