柚子快報(bào)邀請(qǐng)碼778899分享：分庫(kù)分表的使用場(chǎng)景和中間件

http://yzkb.51969.com/

文章目錄

一、為什么要分庫(kù)分表？分庫(kù)分表的使用場(chǎng)景？二、分庫(kù)分表常用中間件1、Cobar2、TDDL3、Atlas4、Sharding-jdbc5、Mycat6、總結(jié)

一、為什么要分庫(kù)分表？分庫(kù)分表的使用場(chǎng)景？

場(chǎng)景1：注冊(cè)用戶(hù)就 20 萬(wàn)，每天活躍用戶(hù)就 1 萬(wàn)，每天單表數(shù)據(jù)量就 1000，然后高峰期每秒鐘并發(fā)請(qǐng)求最多就 10，不需要分庫(kù)分表，單機(jī)就可以。 場(chǎng)景2：注冊(cè)用戶(hù)數(shù)達(dá)到了 2000 萬(wàn)！每天活躍用戶(hù)數(shù) 100 萬(wàn)！每天單表數(shù)據(jù)量 10 萬(wàn)條！高峰期每秒最大請(qǐng)求達(dá)到 1000，負(fù)載均衡，考慮分庫(kù)。 場(chǎng)景3：每天活躍用戶(hù)數(shù)上千萬(wàn)，每天單表新增數(shù)據(jù)多達(dá) 50 萬(wàn)，目前一個(gè)表總數(shù)據(jù)量都已經(jīng)達(dá)到了兩三千萬(wàn)了，需要分庫(kù)。 分庫(kù)分表跟著你的公司業(yè)務(wù)發(fā)展走，你公司業(yè)務(wù)發(fā)展越好，用戶(hù)就越多，數(shù)據(jù)量越大，請(qǐng)求量越大，就需要考慮分庫(kù)分表、 分表：就是把一個(gè)表的數(shù)據(jù)放到多個(gè)表中，然后查詢(xún)的時(shí)候你就查一個(gè)表。比如按照用戶(hù) id 來(lái)分表，將一個(gè)用戶(hù)的數(shù)據(jù)就放在一個(gè)表中。然后操作的時(shí)候你對(duì)一個(gè)用戶(hù)就操作那個(gè)表就好了。這樣可以控制每個(gè)表的數(shù)據(jù)量在可控的范圍內(nèi)，比如每個(gè)表就固定在 200 萬(wàn)以?xún)?nèi)。 分庫(kù)：般我們經(jīng)驗(yàn)而言，最多支撐到并發(fā) 2000，一定要擴(kuò)容了，而且一個(gè)健康的單庫(kù)并發(fā)值你最好保持在每秒 1000 左右，不要太大。那么你可以將一個(gè)庫(kù)的數(shù)據(jù)拆分到多個(gè)庫(kù)中，訪問(wèn)的時(shí)候就訪問(wèn)一個(gè)庫(kù)好了。

二、分庫(kù)分表常用中間件

比較常見(jiàn)的包括：Cobar、TDDL、Atlas、Sharding-jdbc、Mycat

1、Cobar

阿里 b2b 團(tuán)隊(duì)開(kāi)發(fā)和開(kāi)源的，屬于 proxy 層方案，就是介于應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器之間。應(yīng)用程序通過(guò) JDBC 驅(qū)動(dòng)訪問(wèn) Cobar 集群，Cobar 根據(jù) SQL 和分庫(kù)規(guī)則對(duì) SQL 做分解，然后分發(fā)到 MySQL 集群不同的數(shù)據(jù)庫(kù)實(shí)例上執(zhí)行。早些年還可以用，但是最近幾年都沒(méi)更新了，基本沒(méi)啥人用，差不多算是被拋棄的狀態(tài)吧。而且不支持讀寫(xiě)分離、存儲(chǔ)過(guò)程、跨庫(kù) join 和分頁(yè)等操作。

2、TDDL

淘寶團(tuán)隊(duì)開(kāi)發(fā)的，屬于 client 層方案。支持基本的 crud 語(yǔ)法和讀寫(xiě)分離，但不支持 join、多表查詢(xún)等語(yǔ)法。目前使用的也不多，因?yàn)檫€依賴(lài)淘寶的 diamond 配置管理系統(tǒng)。

3、Atlas

360 開(kāi)源的，屬于 proxy 層方案，以前是有一些公司在用的，但是確實(shí)有一個(gè)很大的問(wèn)題就是社區(qū)最新的維護(hù)都在 5 年前了。所以，現(xiàn)在用的公司基本也很少了。

4、Sharding-jdbc

開(kāi)源的，屬于 client 層方案，目前已經(jīng)更名為 ShardingSphere（后文所提到的 Sharding-jdbc，等同于 ShardingSphere）。確實(shí)之前用的還比較多一些，因?yàn)?SQL 語(yǔ)法支持也比較多，沒(méi)有太多限制，而且截至 2019.4，已經(jīng)推出到了 4.0.0-RC1 版本，支持分庫(kù)分表、讀寫(xiě)分離、分布式 id 生成、柔性事務(wù)（最大努力送達(dá)型事務(wù)、TCC 事務(wù)）。而且確實(shí)之前使用的公司會(huì)比較多一些（這個(gè)在官網(wǎng)有登記使用的公司，可以看到從 2017 年一直到現(xiàn)在，是有不少公司在用的），目前社區(qū)也還一直在開(kāi)發(fā)和維護(hù)，還算是比較活躍，個(gè)人認(rèn)為算是一個(gè)現(xiàn)在也可以選擇的方案。

5、Mycat

基于 Cobar 改造的，屬于 proxy 層方案，支持的功能非常完善，而且目前應(yīng)該是非?；鸬亩也粩嗔餍械臄?shù)據(jù)庫(kù)中間件，社區(qū)很活躍，也有一些公司開(kāi)始在用了。但是確實(shí)相比于 Sharding jdbc 來(lái)說(shuō)，年輕一些，經(jīng)歷的錘煉少一些。

6、總結(jié)

綜上，現(xiàn)在其實(shí)建議考量的，就是 Sharding-jdbc 和 Mycat，這兩個(gè)都可以去考慮使用。

Sharding-jdbc 這種 client 層方案的優(yōu)點(diǎn)在于不用部署，運(yùn)維成本低，不需要代理層的二次轉(zhuǎn)發(fā)請(qǐng)求，性能很高，但是如果遇到升級(jí)啥的需要各個(gè)系統(tǒng)都重新升級(jí)版本再發(fā)布，各個(gè)系統(tǒng)都需要耦合 Sharding-jdbc 的依賴(lài)；

Mycat 這種 proxy 層方案的缺點(diǎn)在于需要部署，自己運(yùn)維一套中間件，運(yùn)維成本高，但是好處在于對(duì)于各個(gè)項(xiàng)目是透明的，如果遇到升級(jí)之類(lèi)的都是自己中間件那里搞就行了。

通常來(lái)說(shuō)，這兩個(gè)方案其實(shí)都可以選用，但是我個(gè)人建議中小型公司選用 Sharding-jdbc，client 層方案輕便，而且維護(hù)成本低，不需要額外增派人手，而且中小型公司系統(tǒng)復(fù)雜度會(huì)低一些，項(xiàng)目也沒(méi)那么多；但是中大型公司最好還是選用 Mycat 這類(lèi) proxy 層方案，因?yàn)榭赡艽蠊鞠到y(tǒng)和項(xiàng)目非常多，團(tuán)隊(duì)很大，人員充足，那么最好是專(zhuān)門(mén)弄個(gè)人來(lái)研究和維護(hù) Mycat，然后大量項(xiàng)目直接透明使用即可。 參考博客：為什么要分庫(kù)分表？用過(guò)哪些分庫(kù)分表中間件？

柚子快報(bào)邀請(qǐng)碼778899分享：分庫(kù)分表的使用場(chǎng)景和中間件

http://yzkb.51969.com/

精彩內(nèi)容