基于docker實作mysq主從同步熱備份和讀寫分離（下）

目錄

1. 讀寫分離的實作形式

2. 項目源碼

1、讀寫分離的實作形式

1.1、mysql-proxy方式實作

優點：實作簡單，在獨立的機器安裝mysql-proxy，直接實作讀寫分離和負載均衡，不用項目修改代碼，支援多語言。通過mysql-proxy去通路master和slave。

缺點：字元集問題，lua語言程式設計，還隻是alpha版本， 由中間件做了中轉代理， 切換資料庫變得困難，性能有所下降，時間消耗有點高。

參考：https://www.jianshu.com/p/552b1307dd22

網絡拓撲圖如下：

1.2、Sharding-Sphere分布式是資料中間件

Sharding-Sphere包含了3個産品，分别是 Sharding-JDBC、 Sharding-Proxy、 Sharding-Sidecar。

本文主要介紹Sharding-JDBC，它就是Sharding-Sphere的前身。

發展線路圖如下：

Sharding-Sphere核心功能圖：

優點：

Sharding-JDBC 采用在 JDBC 層擴充分庫分表，支援讀寫分離，是一個以 jar 形式提供服務的輕量級元件，其核心思路是小而美地完成最核心的事情，基于 JDBC 層進行分片的好處是輕量、簡單、相容性好以及無需額外的運維工作。 Sharding-JDBC是對原生的JDBC基礎上做擴充，是增強版的JDBC，是以性能上損失很小。

引用官網的話總結如下：

① Sharding-JDBC是一個開源的分布式資料庫中間件解決方案。它在Java的JDBC層以對業務應用零侵入的方式額外提供資料分片，讀寫分離，柔性事務和分布式治理能力。并在其基礎上提供封裝了MySQL協定的服務端版本，用于完成對異構語言的支援。

② Sharding-JDBC是基于JDBC的用戶端版本定位為輕量級Java架構，使用用戶端直連資料庫，以jar包形式提供服務，無需額外部署和依賴，可了解為增強版的JDBC驅動，完全相容JDBC和各種ORM架構。

③ Sharding-JDBC封裝了MySQL協定的服務端版本定位為透明化的MySQL代理端，可以使用任何相容MySQL協定的通路用戶端(如：MySQL Command Client, MySQL Workbench等)操作資料，對DBA更加友好。

缺點：

由程式員完成，運維參與不到，無法跨語言，目前僅支援 Java。

參考：認識Sharding-JDBC，中文官網，ShardingJdbc項目位址，使用ShardingJdbc應對大資料量的案例

Sharding-JDBC配置依賴

<dependency>
    <groupId>io.shardingsphere</groupId>
    <artifactId>sharding-jdbc-core</artifactId>
    <version>3.0.0</version>
</dependency>
           

Sharding-JDBC配置規則

配置是整個Sharding-JDBC的核心，是Sharding-JDBC中唯一與應用開發者打交道的子產品。配置子產品也是Sharding-JDBC的門戶，通過它可以快速清晰的了解Sharding-JDBC所提供的功能。

本部分是Sharding-JDBC的配置參考手冊，需要時可當做字典查閱。

Sharding-JDBC提供了4種配置方式，用于不同的使用場景。通過配置，應用開發者可以靈活的使用分庫分表、讀寫分離以及分庫分表 + 讀寫分離共用。

工廠方法API

圖中黃色部分表示的是Sharding-JDBC的入口API，采用工廠方法的形式提供。 目前有ShardingDataSourceFactory和MasterSlaveDataSourceFactory兩個工廠類。ShardingDataSourceFactory用于建立分庫分表或分庫分表+讀寫分離的JDBC驅動，MasterSlaveDataSourceFactory用于建立獨立使用讀寫分離的JDBC驅動。

配置對象

圖中藍色部分表示的是Sharding-JDBC的配置對象，提供靈活多變的配置方式。 ShardingRuleConfiguration是分庫分表配置的核心和入口，它可以包含多個TableRuleConfiguration和MasterSlaveRuleConfiguration。每一組相同規則分片的表配置一個TableRuleConfiguration。如果需要分庫分表和讀寫分離共同使用，每一個讀寫分離的邏輯庫配置一個MasterSlaveRuleConfiguration。 每個TableRuleConfiguration對應一個ShardingStrategyConfiguration，它有5中實作類可供選擇。

僅讀寫分離使用MasterSlaveRuleConfiguration即可。

内部對象

圖中紅色部分表示的是内部對象，由Sharding-JDBC内部使用，應用開發者無需關注。Sharding-JDBC通過ShardingRuleConfiguration和MasterSlaveRuleConfiguration生成真正供ShardingDataSource和MasterSlaveDataSource使用的規則對象。ShardingDataSource和MasterSlaveDataSource實作了DataSource接口，是JDBC的完整實作方案。

初始化流程

1. 配置Configuration對象。
2. 通過Factory對象将Configuration對象轉化為Rule對象。
3. 通過Factory對象将Rule對象與DataSource對象裝配。
4. Sharding-JDBC使用DataSource對象進行分庫。

分庫分表為了解決一個問題，引入了很多成本，從長久看這種方案會逐漸被新的解決方案替代。目前看來，解決的思路主要分為兩個方向：

• 第一個思路既然分庫的原動力主要是單執行個體的寫入容量限制，那麼我們可以最大程度地提升整個寫入容量，雲計算的發展為這種思路提供了新的可能，以 AWS Aurora 為代表 RDS ，它以 Log is database 為理念，将複雜的随機寫入簡化為順序寫的 Log，并通過将計算與存儲分離，把複雜的資料持久化、一緻性、資料合并都扔給一個高可用的共享存儲系統來完成，進而打開寫入的天花闆，将昂貴的寫入容量提升一個量級；
• 第二種思路承認分片的必要性，将這種分片的政策內建到一套整體的分布式資料庫體系中，同時通過 Paxos/Raft 複制協定加上多執行個體節點來實作資料強一緻的高可用，其中代表産品有 Google 的 Spanner&F1、TiDB（https://github.com/pingcap/tidb）、CockRoachDB（https://github.com/cockroachdb/cockroach） 等，是比較理想的 Sharding + Proxy 的替代方案。

2、項目源碼

項目源碼Dome參考：https://gitee.com/sunlx/qxl-sharding