本文轉(zhuǎn)載自微信公眾號「有關(guān)SQL」，作者Lenis 。轉(zhuǎn)載本文請聯(lián)系有關(guān)SQL公眾號。

“你們最大的表，有多少數(shù)據(jù)量?”

圈子里幾個常玩的伙伴，聚在一起吃火鍋，或者喝咖啡，通常都會問些特技術(shù)范兒的問題。上面這個，就是常問的問題之一。

其實，倒也不是真對數(shù)據(jù)量感興趣，而是量大了之后，碰到什么特別有意思的事情，以及，用了什么特別的方法解決。

上億了之后，怎么解決;上 TB 級別的存儲量，又怎么解決。

就這樣的問題，如果是在星巴克，大家伙兒都能吹到下半夜去。我記得，最帶勁的劉哥，一言不合，就打開黑乎乎的 shell, 給我們演示。

像這樣的大表場景，如果分庫分表，就是最終殺器。剛開始，幾個外企和民企的朋友，還經(jīng)常吵嘴。一波人說分庫分表，另一波說 sharding, partitioning, 吵來吵去，都是一個意思。

Partition 不是數(shù)據(jù)庫中常說的表分區(qū)，實際上它和分庫分表一個意思。而 Sharding (分片)則是 MongoDB, ElasticSearch 等這類 NoSQL 數(shù)據(jù)庫針對分庫分表的專有術(shù)語。

那么，分庫分表究竟該怎么用呢，涉及到的原理都有哪些呢?說實話，這個話題太大，在本文中，并不能全部一一說到，我只挑自己理解的來說。

讀和寫，數(shù)據(jù)庫之本

這看起來是句廢話。數(shù)據(jù)庫可不就用來存儲，和返回數(shù)據(jù)的嘛!是的，同學你可以把搬磚放下，還不到砸我的時候。

讀和寫是基本，就和人要吃飯運動一樣，是最基本生理活動。人吃飯吃多了，或者運動過多了，那問題就大了。一旦讀和寫，都開始多起來了，同樣也會帶來一系列的問題。

讀自己的數(shù)據(jù)，讓別人無數(shù)據(jù)可讀

這，并不是玩笑話。但它有個前提，數(shù)據(jù)庫的連接數(shù)，是有限的。一旦超額，就再也無法新建連接。此時，只有先連上的用戶，才能讀取數(shù)據(jù)。之后的請求，只能排隊等待，或者干脆收到 timeout(超時) 警告。

說到這，順便再提下，前兩天我在談到 Replication(復制時)， 提到農(nóng)村里看電影的例子。

80年代的農(nóng)村，經(jīng)常有戲班子來放露天電影。所謂“露天”，就是臨時在村頭，搭個舞臺，吊塊幕布，把電影投射上去，支個功放，村民就開始看電影了。

畫個草圖，大概就是這樣子：

這露天電影有個難受的地方，前排的人，耳朵炸聾，后排的人，啥都聽不見。觀影體驗賊差，所以整場下來，只有小孩和真正的影迷，能堅持到最后。其他人中途都跑了。

所以戲班子想了個法兒，在村頭村尾各搭個舞臺。這樣容納的人就多了。有些村實在口人太大，那就村東村西，再放兩個舞臺。這樣村子里所有人，都可以照顧到了。而實現(xiàn)這個目的，就只需復刻 3 份膠卷。

這就是數(shù)據(jù)庫復制原理所在。把數(shù)據(jù)復刻多份的時候，就可以供更多人讀取。

所謂“做人留一線，日后好相見”?？磦€電影而已，沒必要傷害鄉(xiāng)里鄉(xiāng)親的感情。大家為了搶一個好位置，最后結(jié)局只能是誰都看得不爽。所以這里看不了，我就去別的場地看。

復制技術(shù)出來之后，讀數(shù)據(jù)就不搶占一個庫了。這臺服務(wù)器讀請求，在排隊，那就去另一臺服務(wù)器。假設(shè)網(wǎng)絡(luò)里，服務(wù)器夠多，那么總有一臺能讀到數(shù)據(jù)。

SQL Server 可以支持 8 臺服務(wù)器同時服務(wù)讀，而 MySQL 通過中間件，則可以支持更多，比如 MySQL Proxy, MySQL Cat, MySQL DAL等等。

寫入時代大爆炸

之前欣賞電影，只能在電影院，生產(chǎn)這些電影，往往都是大團隊。那時，看電影，純屬于消費時代。

但4G, 5G來了之后，消費時代悄然變化了。小團隊，甚至個人，開始制作電影。小眾視頻，勝在長尾效應(yīng)。比如 Youtube, B 站，這個時代，人人兼可創(chuàng)作。

如此之多的視頻，僅靠電影制片廠，是完全來不及生產(chǎn)了。網(wǎng)民集體的創(chuàng)作狂熱，必須由民間力量，B站，愛奇藝，騰訊視頻等等，來 Hold 住。

就像，你的數(shù)據(jù)庫，在經(jīng)歷了 7， 8年的發(fā)展后，受眾越來越多，大家寫入的熱情也越來越高漲。此時，數(shù)據(jù)庫，也將面臨跟視頻網(wǎng)站一樣的困擾，究竟該如何支撐主這些 “洪流”?

經(jīng)歷了大爆炸后，視頻平臺痛下決心，把視頻服務(wù)器分散，開到全國去。在全國各個重要的大城市，組建視頻中心，讓周圍的視頻創(chuàng)作者，把視頻傳到這些服務(wù)器上。

這就是分庫分表的模式。

雖然華東南西北中，是相互獨立的，但它們的視頻始終都以邏輯整體存在。一個VLOG作者，在北京上傳了個視頻，如果坐飛機到了廣州，他就訪問不到在北京上傳的那個視頻，那怎么也說不過去。

所以，所有這些視頻，都是維護在一張邏輯表中。根據(jù)這些視頻的上傳者GIS地址，傳到最近的服務(wù)器上。這就是分庫分表常用的，按 Key 值分區(qū)策略。雖然這樣的策略，會有一系列問題，但暫且這么理解。

分庫分表好處非常明顯，一來可以容納更多數(shù)據(jù)量，二來訪問更快捷。

怎么實現(xiàn)分庫分表呢?

有人說，可以用客戶端代碼來控制訪問數(shù)據(jù)庫;也有人說，我就愛寫中間件，讓服務(wù)器自動支持分庫分表，并且沒有語言限制，也很極客;還有人說，用云原生，程序員負責實現(xiàn)邏輯，運維這檔子事交給供應(yīng)商。

當然，統(tǒng)統(tǒng)都可以。但是本文還是著重講講中間件。畢竟，供應(yīng)商費銀子，客戶端費腦子，只有中間件，可以一勞永逸。

分享 2 種方法：

Percona XtraDB Cluster方案

Percona XtraDB Cluster簡稱PXC。Percona Xtradb Cluster的實現(xiàn)是在原mysql代碼上通過Galera包將不同的mysql實例連接起來，實現(xiàn)了multi-master的集群架構(gòu)。

上圖中有三個實例，組成了一個集群，而這三個節(jié)點與普通的主從架構(gòu)不同，它們都可以作為主節(jié)點，三個節(jié)點是對等的，這種一般稱為multi-master架構(gòu)，當有客戶端要寫入或者讀取數(shù)據(jù)時，隨便連接哪個實例都是一樣的，讀到的數(shù)據(jù)是相同的，寫入某一個節(jié)點之后，集群自己會將新數(shù)據(jù)同步到其它節(jié)點上面，這種架構(gòu)不共享任何數(shù)據(jù)，是一種高冗余架構(gòu)。

作者：羅阿紅 出處：http://www.cnblogs.com/luoahong/

MySQL DAL (Data Access Layer )

當年手機之家高春輝領(lǐng)導開發(fā)的產(chǎn)品。它解決了單臺計算機容量有限的難題。真正實現(xiàn)了分庫分表的優(yōu)勢。

DAL 有三大組件，Java Netty 框架，ZooKeep 控態(tài)，SQL 處理模塊( 通過分解 SQL 生成語法樹，依據(jù) SQL 路由表，生成對應(yīng)的執(zhí)行路徑)

由于 MySQL DAL 是閉源產(chǎn)品，相關(guān)的實現(xiàn)沒有源碼可看。但我看到這篇論文有提及部分原理：

嗯，上次有微信群水友問，數(shù)據(jù)庫開發(fā)與數(shù)據(jù)庫開發(fā)有什么區(qū)別。大概在這里，可以說的明白了。

一類人，是做CRUD應(yīng)用系統(tǒng)的開發(fā)，比如做個報表，寫個ETL;另一類數(shù)據(jù)庫開發(fā)，是實現(xiàn)數(shù)據(jù)庫的某項功能，比如分庫分表組件。