柚子快報邀請碼778899分享:分庫分表的使用場景和中間件
柚子快報邀請碼778899分享:分庫分表的使用場景和中間件
文章目錄
一、為什么要分庫分表?分庫分表的使用場景?二、分庫分表常用中間件1、Cobar2、TDDL3、Atlas4、Sharding-jdbc5、Mycat6、總結(jié)
一、為什么要分庫分表?分庫分表的使用場景?
場景1:注冊用戶就 20 萬,每天活躍用戶就 1 萬,每天單表數(shù)據(jù)量就 1000,然后高峰期每秒鐘并發(fā)請求最多就 10,不需要分庫分表,單機就可以。 場景2:注冊用戶數(shù)達到了 2000 萬!每天活躍用戶數(shù) 100 萬!每天單表數(shù)據(jù)量 10 萬條!高峰期每秒最大請求達到 1000,負(fù)載均衡,考慮分庫。 場景3:每天活躍用戶數(shù)上千萬,每天單表新增數(shù)據(jù)多達 50 萬,目前一個表總數(shù)據(jù)量都已經(jīng)達到了兩三千萬了,需要分庫。 分庫分表跟著你的公司業(yè)務(wù)發(fā)展走,你公司業(yè)務(wù)發(fā)展越好,用戶就越多,數(shù)據(jù)量越大,請求量越大,就需要考慮分庫分表、 分表:就是把一個表的數(shù)據(jù)放到多個表中,然后查詢的時候你就查一個表。比如按照用戶 id 來分表,將一個用戶的數(shù)據(jù)就放在一個表中。然后操作的時候你對一個用戶就操作那個表就好了。這樣可以控制每個表的數(shù)據(jù)量在可控的范圍內(nèi),比如每個表就固定在 200 萬以內(nèi)。 分庫:般我們經(jīng)驗而言,最多支撐到并發(fā) 2000,一定要擴容了,而且一個健康的單庫并發(fā)值你最好保持在每秒 1000 左右,不要太大。那么你可以將一個庫的數(shù)據(jù)拆分到多個庫中,訪問的時候就訪問一個庫好了。
二、分庫分表常用中間件
比較常見的包括:Cobar、TDDL、Atlas、Sharding-jdbc、Mycat
1、Cobar
阿里 b2b 團隊開發(fā)和開源的,屬于 proxy 層方案,就是介于應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器之間。應(yīng)用程序通過 JDBC 驅(qū)動訪問 Cobar 集群,Cobar 根據(jù) SQL 和分庫規(guī)則對 SQL 做分解,然后分發(fā)到 MySQL 集群不同的數(shù)據(jù)庫實例上執(zhí)行。早些年還可以用,但是最近幾年都沒更新了,基本沒啥人用,差不多算是被拋棄的狀態(tài)吧。而且不支持讀寫分離、存儲過程、跨庫 join 和分頁等操作。
2、TDDL
淘寶團隊開發(fā)的,屬于 client 層方案。支持基本的 crud 語法和讀寫分離,但不支持 join、多表查詢等語法。目前使用的也不多,因為還依賴淘寶的 diamond 配置管理系統(tǒng)。
3、Atlas
360 開源的,屬于 proxy 層方案,以前是有一些公司在用的,但是確實有一個很大的問題就是社區(qū)最新的維護都在 5 年前了。所以,現(xiàn)在用的公司基本也很少了。
4、Sharding-jdbc
開源的,屬于 client 層方案,目前已經(jīng)更名為 ShardingSphere(后文所提到的 Sharding-jdbc,等同于 ShardingSphere)。確實之前用的還比較多一些,因為 SQL 語法支持也比較多,沒有太多限制,而且截至 2019.4,已經(jīng)推出到了 4.0.0-RC1 版本,支持分庫分表、讀寫分離、分布式 id 生成、柔性事務(wù)(最大努力送達型事務(wù)、TCC 事務(wù))。而且確實之前使用的公司會比較多一些(這個在官網(wǎng)有登記使用的公司,可以看到從 2017 年一直到現(xiàn)在,是有不少公司在用的),目前社區(qū)也還一直在開發(fā)和維護,還算是比較活躍,個人認(rèn)為算是一個現(xiàn)在也可以選擇的方案。
5、Mycat
基于 Cobar 改造的,屬于 proxy 層方案,支持的功能非常完善,而且目前應(yīng)該是非?;鸬亩也粩嗔餍械臄?shù)據(jù)庫中間件,社區(qū)很活躍,也有一些公司開始在用了。但是確實相比于 Sharding jdbc 來說,年輕一些,經(jīng)歷的錘煉少一些。
6、總結(jié)
綜上,現(xiàn)在其實建議考量的,就是 Sharding-jdbc 和 Mycat,這兩個都可以去考慮使用。
Sharding-jdbc 這種 client 層方案的優(yōu)點在于不用部署,運維成本低,不需要代理層的二次轉(zhuǎn)發(fā)請求,性能很高,但是如果遇到升級啥的需要各個系統(tǒng)都重新升級版本再發(fā)布,各個系統(tǒng)都需要耦合 Sharding-jdbc 的依賴;
Mycat 這種 proxy 層方案的缺點在于需要部署,自己運維一套中間件,運維成本高,但是好處在于對于各個項目是透明的,如果遇到升級之類的都是自己中間件那里搞就行了。
通常來說,這兩個方案其實都可以選用,但是我個人建議中小型公司選用 Sharding-jdbc,client 層方案輕便,而且維護成本低,不需要額外增派人手,而且中小型公司系統(tǒng)復(fù)雜度會低一些,項目也沒那么多;但是中大型公司最好還是選用 Mycat 這類 proxy 層方案,因為可能大公司系統(tǒng)和項目非常多,團隊很大,人員充足,那么最好是專門弄個人來研究和維護 Mycat,然后大量項目直接透明使用即可。 參考博客:為什么要分庫分表?用過哪些分庫分表中間件?
柚子快報邀請碼778899分享:分庫分表的使用場景和中間件
精彩內(nèi)容
本文內(nèi)容根據(jù)網(wǎng)絡(luò)資料整理,出于傳遞更多信息之目的,不代表金鑰匙跨境贊同其觀點和立場。
轉(zhuǎn)載請注明,如有侵權(quán),聯(lián)系刪除。