目錄

一、ShardingSphere分庫分表產(chǎn)品介紹

二、客戶端分庫分表與服務(wù)端分庫分表

1、ShardingJDBC客戶端分庫分表

2、ShardingProxy服務(wù)端分庫分表

3、ShardingSphere混合部署架構(gòu)

三、分庫分表，能不分就不分！

1、為什么要分庫分表？

2、分庫分表的優(yōu)勢(shì)

3、分庫分表的挑戰(zhàn)

---

一、ShardingSphere分庫分表產(chǎn)品介紹

shardingsphere官網(wǎng)地址：Apache ShardingSphere

?

ShardingSphere是一款起源于當(dāng)當(dāng)網(wǎng)內(nèi)部的應(yīng)用框架。2015年在當(dāng)當(dāng)網(wǎng)內(nèi)部誕生，最初就叫ShardingJDBC。2016年的時(shí)候，由其中一個(gè)主要的開發(fā)人員張亮，帶入到京東數(shù)科，組件團(tuán)隊(duì)繼續(xù)開發(fā)。在國(guó)內(nèi)歷經(jīng)了當(dāng)當(dāng)網(wǎng)、電信翼支付、京東數(shù)科等多家大型互聯(lián)網(wǎng)企業(yè)的考驗(yàn)，在2017年開始開源。并逐漸由原本只關(guān)注于關(guān)系型數(shù)據(jù)庫增強(qiáng)工具的ShardingJDBC升級(jí)成為一整套以數(shù)據(jù)分片為基礎(chǔ)的數(shù)據(jù)生態(tài)圈，更名為ShardingSphere。到2020年4月，已經(jīng)成為了Apache軟件基金會(huì)的頂級(jí)項(xiàng)目。發(fā)展至今，已經(jīng)成為了業(yè)界分庫分表最成熟的產(chǎn)品。

ShardingSphere這個(gè)詞可以分為兩個(gè)部分，其中Sharding就是我們之前介紹過的數(shù)據(jù)分片。從官網(wǎng)介紹上就能看到，他的核心功能就是可以將任意數(shù)據(jù)庫組合，轉(zhuǎn)換成為一個(gè)分布式的數(shù)據(jù)庫，提供整體的數(shù)據(jù)庫集群服務(wù)。只是給自己的定位并不是Database，而是Database plus。其實(shí)這個(gè)意思是他自己并不做數(shù)據(jù)存儲(chǔ)，而是對(duì)其他數(shù)據(jù)庫產(chǎn)品進(jìn)行整合。整個(gè)ShardingSphere其實(shí)就是圍繞數(shù)據(jù)分片這個(gè)核心功能發(fā)展起來的。

后面的Sphere是生態(tài)的意思。這意味著ShardingSphere不是一個(gè)單獨(dú)的框架或者產(chǎn)品，而是一個(gè)由多個(gè)框架以及產(chǎn)品構(gòu)成的一個(gè)完整的技術(shù)生態(tài)。目前ShardingSphere中比較成型的產(chǎn)品主要包含核心的ShardingJDBC以及ShardingProxy兩個(gè)產(chǎn)品，以及一個(gè)用于數(shù)據(jù)遷移的子項(xiàng)目ElasticJob。另外現(xiàn)在也提供了基于公有云的云上服務(wù)ShardingSphere-on-Cloud。

ShardingSphere經(jīng)過這么多年的發(fā)展，已經(jīng)不僅僅只是用來做分庫分表，而是形成了一個(gè)圍繞分庫分表核心的技術(shù)生態(tài)。他的核心功能已經(jīng)包括了數(shù)據(jù)分片、分布式事務(wù)、讀寫分離、高可用、數(shù)據(jù)遷移、聯(lián)邦查詢、數(shù)據(jù)加密、影子庫、DistSQL龐大的技術(shù)體系。

目前ShardingSphere已經(jīng)演進(jìn)到了5.x大版本。在這個(gè)大版本中，ShardingSphere的核心是可插拔。其核心設(shè)計(jì)哲學(xué)就是連接、增強(qiáng)以及可拔插。這是官網(wǎng)對(duì)于其整個(gè)設(shè)計(jì)哲學(xué)的核心描述。

二、客戶端分庫分表與服務(wù)端分庫分表

ShardingSphere最為核心的產(chǎn)品有兩個(gè)：一個(gè)是ShardingJDBC，這是一個(gè)進(jìn)行客戶端分庫分表的框架。另一個(gè)是ShardingProxy，這是一個(gè)進(jìn)行服務(wù)端分庫分表的產(chǎn)品。他們代表了兩種不同的分庫分表的實(shí)現(xiàn)思路。

1、ShardingJDBC客戶端分庫分表

ShardingSphere-JDBC 定位為輕量級(jí) Java 框架，在 Java 的 JDBC 層提供的額外服務(wù)。 它使用客戶端直連數(shù)據(jù)庫，以 jar 包形式提供服務(wù)，無需額外部署和依賴，可理解為增強(qiáng)版的 JDBC 驅(qū)動(dòng)，完全兼容 JDBC 和各種 ORM 框架。

• 適用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC；
• 支持任何第三方的數(shù)據(jù)庫連接池，如：DBCP, C3P0, BoneCP, HikariCP 等；
• 支持任意實(shí)現(xiàn) JDBC 規(guī)范的數(shù)據(jù)庫，目前支持 MySQL，PostgreSQL，Oracle，SQLServer 以及任何可使用 JDBC 訪問的數(shù)據(jù)庫。

這是ShardingSphere最初的產(chǎn)品形態(tài)。

2、ShardingProxy服務(wù)端分庫分表

ShardingSphere-Proxy 定位為透明化的數(shù)據(jù)庫代理端，通過實(shí)現(xiàn)數(shù)據(jù)庫二進(jìn)制協(xié)議，對(duì)異構(gòu)語言提供支持。 目前提供 MySQL 和 PostgreSQL 協(xié)議，透明化數(shù)據(jù)庫操作，對(duì) DBA 更加友好。

• 向應(yīng)用程序完全透明，可直接當(dāng)做 MySQL/PostgreSQL 使用；
• 兼容 MariaDB 等基于 MySQL 協(xié)議的數(shù)據(jù)庫，以及 openGauss 等基于 PostgreSQL 協(xié)議的數(shù)據(jù)庫；
• 適用于任何兼容 MySQL/PostgreSQL 協(xié)議的客戶端，如：MySQL Command Client, MySQL Workbench, Navicat 等。

3、ShardingSphere混合部署架構(gòu)

這兩個(gè)產(chǎn)品都各有優(yōu)勢(shì)。ShardingJDBC跟客戶端在一起，使用更加靈活。而ShardingProxy是一個(gè)獨(dú)立部署的服務(wù)，所以他的功能相對(duì)就比較固定。他們的整體區(qū)別如下：

	ShardingSphere-JDBC	ShardingSphere-Proxy
數(shù)據(jù)庫	任意	MySQL/PostgreSQL
連接消耗數(shù)	高	低
異構(gòu)語言	僅 Java	任意
性能	損耗低	損耗略高
無中心化	是	否
靜態(tài)入口	無	有

另外，在產(chǎn)品圖中，Governance Center也是其中重要的部分。他的作用有點(diǎn)類似于微服務(wù)架構(gòu)中的配置中心，可以使用第三方服務(wù)統(tǒng)一管理分庫分表的配置信息，當(dāng)前建議使用的第三方服務(wù)是Zookeeper，同時(shí)也支持Nacos，Etcd等其他第三方產(chǎn)品。

由于ShardingJDBC和ShardingProxy都支持通過Governance Center，將配置信息交個(gè)第三方服務(wù)管理，因此，也就自然支持了通過Governance Center進(jìn)行整合的混合部署架構(gòu)。

三、分庫分表，能不分就不分！

1、為什么要分庫分表？

數(shù)據(jù)庫，應(yīng)該是一個(gè)應(yīng)用當(dāng)中最為核心的價(jià)值所在，也是開發(fā)過程中必須熟練掌握的工具。之前我們就學(xué)習(xí)過很多對(duì)MySQL的調(diào)優(yōu)。但是隨著現(xiàn)在互聯(lián)網(wǎng)應(yīng)用越來越大，數(shù)據(jù)庫會(huì)頻繁的成為整個(gè)應(yīng)用的性能瓶頸。我們經(jīng)常使用的MySQL數(shù)據(jù)庫，也就不斷面臨數(shù)據(jù)量太大、數(shù)據(jù)訪問太頻繁、數(shù)據(jù)讀寫速度太快等一系列的問題。而傳統(tǒng)的這些調(diào)優(yōu)方式，在真正面對(duì)海量數(shù)據(jù)沖擊時(shí)，往往就會(huì)顯得很無力。因此，現(xiàn)在互聯(lián)網(wǎng)對(duì)于數(shù)據(jù)庫的使用也越來越小心謹(jǐn)慎。例如添加Redis緩存、增加MQ進(jìn)行流量削峰等。但是，數(shù)據(jù)庫本身如果性能得不到提升，這就相當(dāng)于是水桶理論中的最短板。

要提升數(shù)據(jù)庫的性能，最直接的思路，當(dāng)然是對(duì)數(shù)據(jù)庫本身進(jìn)行優(yōu)化。例如對(duì)MySQL進(jìn)行調(diào)優(yōu)，優(yōu)化SQL邏輯，優(yōu)化索引結(jié)構(gòu)，甚至像阿里等互聯(lián)網(wǎng)大廠一樣，直接優(yōu)化MySQL的源碼。但是這種思路在面對(duì)互聯(lián)網(wǎng)環(huán)境時(shí)，會(huì)有很多非常明顯的弊端。

• 數(shù)據(jù)量和業(yè)務(wù)量快速增長(zhǎng)，會(huì)帶來性能瓶頸、服務(wù)宕機(jī)等很多問題。
• 單點(diǎn)部署的數(shù)據(jù)庫無法保證服務(wù)高可用。
• 單點(diǎn)部署的數(shù)據(jù)庫無法進(jìn)行水平擴(kuò)展，難以應(yīng)對(duì)業(yè)務(wù)爆發(fā)式的增長(zhǎng)。

這些問題背后的核心還是數(shù)據(jù)。數(shù)據(jù)庫不同于上層的一些服務(wù)，他所管理的數(shù)據(jù)甚至比服務(wù)本身更重要。即要保證數(shù)據(jù)能夠持續(xù)穩(wěn)定的寫入，又不能因?yàn)榉?wù)故障造成數(shù)據(jù)丟失。現(xiàn)在互聯(lián)網(wǎng)上的大型應(yīng)用，動(dòng)輒幾千萬上億的數(shù)據(jù)量，就算做好數(shù)據(jù)的壓縮，隨隨便便也可以超過任何服務(wù)器的存儲(chǔ)能力。并且，服務(wù)器單點(diǎn)部署，也無法真正解決把雞蛋放在一個(gè)籃子里的問題。將數(shù)據(jù)放在同一個(gè)服務(wù)器上，如果服務(wù)器出現(xiàn)崩潰，就很難保證數(shù)據(jù)的安全性。這些都不是光靠?jī)?yōu)化MySQL產(chǎn)品，優(yōu)化服務(wù)器配置能夠解決的問題。

2、分庫分表的優(yōu)勢(shì)

那么自然就需要換另外一種思路了。我們可以像微服務(wù)架構(gòu)一樣，來維護(hù)數(shù)據(jù)庫的服務(wù)。把數(shù)據(jù)庫從單體服務(wù)升級(jí)到數(shù)據(jù)庫集群，這樣才能真正全方位解放數(shù)據(jù)庫的性能瓶頸，并且能夠通過水平擴(kuò)展的方式，靈活提升數(shù)據(jù)庫的存儲(chǔ)能力。這也就是我們常說的分庫分表。通過分庫分表可以給數(shù)據(jù)庫帶來很大的好處：

• 提高系統(tǒng)性能：分庫分表可以將大型數(shù)據(jù)庫分成多個(gè)小型數(shù)據(jù)庫，每個(gè)小型數(shù)據(jù)庫只需要處理部分?jǐn)?shù)據(jù)，因此可以提高數(shù)據(jù)庫的并發(fā)處理能力和查詢性能。
• 提高系統(tǒng)可用性：分庫分表可以將數(shù)據(jù)復(fù)制到多個(gè)數(shù)據(jù)庫中，以提高數(shù)據(jù)的可用性和可靠性。如果一個(gè)數(shù)據(jù)庫崩潰了，其他數(shù)據(jù)庫可以接管其工作，以保持系統(tǒng)的正常運(yùn)行。
• 提高系統(tǒng)可擴(kuò)展性：分庫分表可以使系統(tǒng)更容易擴(kuò)展。當(dāng)數(shù)據(jù)量增加時(shí)，只需要增加更多的數(shù)據(jù)庫和表，而不是替換整個(gè)數(shù)據(jù)庫，因此系統(tǒng)的可擴(kuò)展性更高。
• 提高系統(tǒng)靈活性：分庫分表可以根據(jù)數(shù)據(jù)的使用情況，對(duì)不同的數(shù)據(jù)庫和表進(jìn)行不同的優(yōu)化。例如，可以將經(jīng)常使用的數(shù)據(jù)存儲(chǔ)在性能更好的數(shù)據(jù)庫中，或者將特定類型的數(shù)據(jù)存儲(chǔ)在特定的表中，以提高系統(tǒng)的靈活性。
• 降低系統(tǒng)成本：分庫分表可以使系統(tǒng)更加高效，因此可以降低系統(tǒng)的運(yùn)營(yíng)成本。此外，分庫分表可以使用更便宜的硬件和存儲(chǔ)設(shè)備，因?yàn)槊總€(gè)小型數(shù)據(jù)庫和表需要的資源更少。

3、分庫分表的挑戰(zhàn)

可能你會(huì)說，分庫分表嘛， 也不是很難。一個(gè)庫存不下，那就把數(shù)據(jù)拆分到多個(gè)庫。一張表數(shù)據(jù)太多了，就把同一張表的數(shù)據(jù)拆分到多張。至于怎么做，也不難啊。要操作多個(gè)數(shù)據(jù)庫，那么建立多個(gè)JDBC連接就行了。要寫到多張表，修改下SQL語句就行了。

如果你也這么覺得，那么就大錯(cuò)特錯(cuò)了。分庫分表也并不是字面意義上的將數(shù)據(jù)分到多個(gè)庫或者多個(gè)表這么簡(jiǎn)單，他需要的是一系列的分布式解決方案。

因?yàn)閿?shù)據(jù)的特殊性，造成數(shù)據(jù)庫服務(wù)其實(shí)是幾乎沒有試錯(cuò)的成本的。在微服務(wù)階段，從單機(jī)架構(gòu)升級(jí)到微服務(wù)架構(gòu)是很靈活的，中間很多細(xì)節(jié)步驟都可以隨時(shí)做調(diào)整。比如對(duì)于微服務(wù)的接口限流功能，你并不需要一上來就用Sentinel這樣復(fù)雜的流控工具。一開始不考慮性能，自己進(jìn)行限流是很容易的事情。然后你可以慢慢嘗試用Guava等框架提供的一些簡(jiǎn)單的流控工具進(jìn)行零散的接口限流。直到整個(gè)應(yīng)用的負(fù)載真正上來了之后，流控的要求更高更復(fù)雜了，再開始引入Sentinel，進(jìn)行統(tǒng)一流控，這都沒有問題。這種試錯(cuò)的過程其實(shí)是你能夠真正用好一項(xiàng)技術(shù)的基礎(chǔ)。

但是對(duì)于數(shù)據(jù)庫就不一樣了。當(dāng)應(yīng)用中用來存儲(chǔ)數(shù)據(jù)的數(shù)據(jù)庫，從一個(gè)單機(jī)的數(shù)據(jù)庫服務(wù)升級(jí)到多個(gè)數(shù)據(jù)庫組成的集群服務(wù)時(shí)，需要考慮的，除了分布式的各種讓人摸不著邊際的復(fù)雜問題外，還要考慮到一個(gè)更重要的因素，數(shù)據(jù)。數(shù)據(jù)的安全性甚至比數(shù)據(jù)庫服務(wù)本身更重要！因此，如果你在一開始做分庫分表時(shí)的方案不太成熟，對(duì)數(shù)據(jù)的規(guī)劃不是很合理，那么這些問題大概率會(huì)隨著數(shù)據(jù)永遠(yuǎn)沉淀下去，成為日后對(duì)分庫分表方案進(jìn)行調(diào)整時(shí)最大的攔路虎。

所以在決定進(jìn)行分庫分表之前，一定需要提前對(duì)于所需要面對(duì)的各種問題進(jìn)行考量。如果你沒有考慮清楚數(shù)據(jù)要如何存儲(chǔ)、計(jì)算、使用，或者你對(duì)于分庫分表的各種問題都還沒有進(jìn)行過思考，那么千萬不要在真實(shí)項(xiàng)目中貿(mào)然的進(jìn)行分庫分表。

分庫分表，也稱為Sharding。Sharding表示將數(shù)據(jù)拆分到不同的數(shù)據(jù)片中。由于數(shù)據(jù)往往是一個(gè)應(yīng)用的基礎(chǔ)，隨著數(shù)據(jù)從單體服務(wù)拆分到多個(gè)數(shù)據(jù)分片，應(yīng)用層面也需要面臨很多新的問題。比如：

• 主鍵避重問題

在分庫分表環(huán)境中，由于表中數(shù)據(jù)同時(shí)存在不同數(shù)據(jù)庫中，某個(gè)分區(qū)數(shù)據(jù)庫生成的ID就無法保證全局唯一。因此需要單獨(dú)設(shè)計(jì)全局主鍵，以避免跨庫主鍵重復(fù)問題。

• 數(shù)據(jù)備份問題

隨著數(shù)據(jù)庫由單機(jī)變?yōu)榧?#xff0c;整體服務(wù)的穩(wěn)定性也會(huì)隨之降低。如何保證集群在各個(gè)服務(wù)不穩(wěn)定的情況下，依然保持整體服務(wù)穩(wěn)定就是數(shù)據(jù)庫集群需要面對(duì)的重要問題。而對(duì)于數(shù)據(jù)庫，還需要對(duì)數(shù)據(jù)安全性做更多的考量。

• 數(shù)據(jù)遷移問題

當(dāng)數(shù)據(jù)庫集群需要進(jìn)行擴(kuò)縮容時(shí)，集群中的數(shù)據(jù)也需要隨著服務(wù)進(jìn)行遷移。如何在不影響業(yè)務(wù)穩(wěn)定性的情況下進(jìn)行數(shù)據(jù)遷移也是數(shù)據(jù)庫集群化后需要考慮的問題。

• 分布式事務(wù)問題

原本單機(jī)數(shù)據(jù)庫有很好的事務(wù)機(jī)制能夠幫我們保證數(shù)據(jù)一致性。但是分庫分表后，由于數(shù)據(jù)分布在不同庫甚至不同服務(wù)器，不可避免會(huì)帶來分布式事務(wù)問題。

• SQL路由問題

數(shù)據(jù)被拆分到多個(gè)分散的數(shù)據(jù)庫服務(wù)當(dāng)中，每個(gè)數(shù)據(jù)庫服務(wù)只能保存一部分的數(shù)據(jù)。這時(shí)，在執(zhí)行SQL語句檢索數(shù)據(jù)時(shí)，如何快速定位到目標(biāo)數(shù)據(jù)所在的數(shù)據(jù)庫服務(wù)，并將SQL語句轉(zhuǎn)到對(duì)應(yīng)的數(shù)據(jù)庫服務(wù)中執(zhí)行，也是提升檢索效率必須要考慮的問題。

• 跨節(jié)點(diǎn)查詢，歸并問題

跨節(jié)點(diǎn)進(jìn)行查詢時(shí)，每個(gè)分散的數(shù)據(jù)庫中只能查出一部分的數(shù)據(jù)，這時(shí)要對(duì)整體結(jié)果進(jìn)行歸并時(shí)，就會(huì)變得非常復(fù)雜。比如常見的limit、order by等操作。

在實(shí)際項(xiàng)目中，遇到的問題還會(huì)更多。從這里可以看出，Sharding其實(shí)是一個(gè)很復(fù)雜的問題，往往很難通過項(xiàng)目定制的方式整體解決。因此，大部分情況下，都是通過第三方的服務(wù)來解決Sharding的問題。比如像TiDB、ClickHouse、Hadoop這一類的NewSQL產(chǎn)品，大部分情況下是將數(shù)據(jù)問題整體封裝到一起，從而提供Sharding方案。但是這些產(chǎn)品畢竟太重了。更靈活的方式還是使用傳統(tǒng)數(shù)據(jù)庫，通過軟件層面來解決多個(gè)數(shù)據(jù)庫之間的數(shù)據(jù)問題。這也誕生了很多的產(chǎn)品，比如早前的MyCat，還有后面我們要學(xué)習(xí)的ShardingSphere等。

另外，關(guān)于何時(shí)要開始考慮分庫分表呢？當(dāng)然是數(shù)據(jù)太大了，數(shù)據(jù)庫服務(wù)器壓力太大了就要進(jìn)行分庫分表。但是這其實(shí)是沒有一個(gè)具體的標(biāo)準(zhǔn)的，需要根據(jù)項(xiàng)目情況進(jìn)行靈活設(shè)計(jì)。業(yè)界目前唯一比較值得參考的詳細(xì)標(biāo)準(zhǔn)，是阿里公開的開發(fā)手冊(cè)中提到的，建議預(yù)估三年內(nèi)，單表數(shù)據(jù)超過500W，或者單表數(shù)據(jù)大小超過2G，就需要考慮分庫分表。