好處 png 表達 連接 esql 部署 中間 構圖 擴展

背景

對於大型的互聯網應用來說，數據庫單表的記錄行數可能達到千萬級甚至是億級，並且數據庫面臨著極高的並發訪問。采用Master-Slave復制模式的MySQL架構，只能夠對數據庫的讀進行擴展，而對數據庫的寫入操作還是集中在Master上，並且單個Master掛載的Slave也不可能無限制多，Slave的數量受到Master能力和負載的限制。因此，需要對數據庫的吞吐能力進行進一步的擴展，以滿足高並發訪問與海量數據存儲的需要！

分表

對於訪問極為頻繁且數據量巨大的單表來說，我們首先要做的就是減少單表的記錄條數，以便減少數據查詢所需要的時間，提高數據庫的吞吐，這就是所謂的分表！

分表又分為垂直分表

和水平分表
垂直分表：表的記錄並不多，但是字段卻很長，表占用空間很大，檢索表的時候需要執行大量的IO，嚴重降低了性能。這時需要把大的字段拆分到另一個表，並且該表與原表是一對一的關系。
水平分表：表的記錄很多，嚴重影響了查詢速度。這時需要把一張表拆分成多張字段相同的表，將記錄分攤到各個表中，以減少單表的記錄數

分庫

分表能夠解決單表數據量過大帶來的查詢效率下降的問題，但是，卻無法給數據庫的並發處理能力帶來質的提升。面對高並發的讀寫訪問，當數據庫master服務器無法承載寫操作壓力時，不管如何擴展slave服務器，此時都沒有意義了。因此，我們必須換一種思路，對數據庫進行拆分，從而提高數據庫寫入能力，這就是所謂的分庫!

分庫+分表

有時數據庫可能既面臨著高並發訪問的壓力，又需要面對海量數據的存儲問題，這時需要對數據庫既采用分表策略，又采用分庫策略，以便同時擴展系統的並發處理能力，以及提升單表的查詢性能，這就是所謂的分庫分表。

常見的分庫分表中間件

1. proxy sharding，目前由cobar，mycat，drds，atlas修改，這幾個產品的起源一般是mysqlproxy 或 ameoba，特點是mysql協議基本兼容，業務不需要做太多修改，缺點是分庫分表的算法很爛，業務要自己做大堆配置
2. jdbc中間件sharding，這個和協議差不多，就是把服務實現為了一個中間件，好處是協議損失時間可以補回來，壞處是只有java可以使用，開源的有當當的 sharding-jdbc

3.mysql的ndbcluster和fabric，這是mysql 引擎層面做的sharding，直接用mysql的協議層和計劃生成，這個做的好處是原生的協議層都是百分百支持，事務用mysql xa支持也算馬馬虎虎，壞處是單機引擎，不能支持大數據的sql

詳細 https://www.cnblogs.com/wangzhongqiu/p/7100332.html

項目簡介

sharding-jdbc是當當的一個開源的項目，屬於輕量級Java框架，使用客戶端直連數據庫，以jar包形式提供服務，未使用中間層，無需額外部署，無其他依賴。

github地址：https://github.com/shardingjdbc/sharding-jdbc

文檔：http://shardingjdbc.io/docs/00-overview

官網提供的功能列表 ：）

1. 分庫分表
SQL解析功能完善，支持聚合，分組，排序，LIMIT，TOP等查詢，並且支持級聯表以及笛卡爾積的表查詢
支持內、外連接查詢
分片策略靈活，可支持=，BETWEEN，IN等多維度分片，也可支持多分片鍵共用，以及自定義分片策略
基於Hint的強制分庫分表路由
2. 讀寫分離
獨立使用讀寫分離支持SQL透傳
一主多從的讀寫分離配置，可配合分庫分表使用
基於Hint的強制主庫路由
3. 柔性事務
最大努力送達型事務
TCC型事務(TBD)
4. 分布式主鍵
統一的分布式基於時間序列的ID生成器
5. 兼容性
可適用於任何基於java的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC
可基於任何第三方的數據庫連接池，如：DBCP, C3P0, BoneCP, Druid等
理論上可支持任意實現JDBC規範的數據庫。目前支持MySQL，Oracle，SQLServer和PostgreSQL
6. 靈活多樣的配置
Java
YAML
Inline表達式
Spring命名空間
Spring boot starter
7. 分布式治理能力 (2.0新功能)
配置集中化與動態化，可支持數據源、表與分片策略的動態切換(2.0.0.M1)
客戶端的數據庫治理，數據源失效自動切換(2.0.0.M2)
基於Open Tracing協議的APM信息輸出(2.0.0.M3)

整體架構圖

sharding-jdbc源碼學習（一）簡介