1、什么是可擴(kuò)展性

可擴(kuò)展性。 即通過增加資源提升整個(gè)系統(tǒng)吞吐量的能力

一般會(huì)有如下的角度影響負(fù)載：

• 數(shù)據(jù)量
• 用戶量 更多的用戶，意味著更多的數(shù)據(jù)充甚，更復(fù)雜的查詢，更多的事務(wù)
• 用戶活躍度 容易造成熱點(diǎn)
• 相關(guān)數(shù)據(jù)集的大小 即關(guān)聯(lián)數(shù)據(jù)霸褒，比如好友

可擴(kuò)展性的數(shù)學(xué)表現(xiàn)：

• 最簡(jiǎn)單的是線性的伴找，資源翻倍，吞吐量翻倍
• 但是由于有些工作是線性的废菱，無法通過并發(fā)來提升技矮，這樣曲線就會(huì)趨于平緩
• 再引入擴(kuò)展帶來的內(nèi)部節(jié)點(diǎn)或者是線程間的通信，會(huì)造成曲線的不降反升
• 考慮到有一些I/O密集型的應(yīng)用殊轴，擴(kuò)展只會(huì)可能變成全都讀取內(nèi)存衰倦，還有可能造成曲線上揚(yáng)

2、擴(kuò)展mysql

通常系統(tǒng)初建時(shí)要考慮一點(diǎn)可擴(kuò)展性旁理。在擴(kuò)展之前樊零，要先壓榨單機(jī)性能，比如算法調(diào)優(yōu)等等

2.1 向上擴(kuò)展（Scale Up）

向上擴(kuò)展（也叫垂直擴(kuò)展）就是換CPU孽文，磁盤等等驻襟。對(duì)部分應(yīng)用來說這是唯一需要做的。

優(yōu)點(diǎn)：

• 單臺(tái)服務(wù)器比多臺(tái)服務(wù)器更加容易開發(fā)和維護(hù)芋哭，能顯著節(jié)省開銷
• 在單臺(tái)服務(wù)器上備份和恢復(fù)應(yīng)用同樣簡(jiǎn)單沉衣；
• 無需關(guān)心一致性；

為了能夠更好的在大型服務(wù)器上運(yùn)行MySQL,一定要盡量使用最新的版本减牺。
如果應(yīng)用變得非常龐大豌习，向上擴(kuò)展可能就沒有辦法。

2.2 向外擴(kuò)展（Scale Out）

向外擴(kuò)展有時(shí)也稱為橫向擴(kuò)展或者水平擴(kuò)展拔疚，策略劃分為三個(gè)部分：復(fù)制肥隆、拆分，以及數(shù)據(jù)分片（sharding）稚失。

最常見的向外擴(kuò)展就是讀寫分離巷屿。通過復(fù)制將數(shù)據(jù)分發(fā)到多個(gè)服務(wù)器上，然后將備庫用于讀查詢墩虹。這種技術(shù)對(duì)于以讀為主的應(yīng)用很有效嘱巾。

另一個(gè)比較常見的向外擴(kuò)展方法是將工作負(fù)載分布到多個(gè) “節(jié)點(diǎn)”。接下來我們要了解的主要是這種擴(kuò)展方法诫钓。

在此之前旬昭，我們先明確下節(jié)點(diǎn)的概念。在 MySQL 架構(gòu)中菌湃，一個(gè)節(jié)點(diǎn)就是一個(gè)功能部件问拘。一般的，我們會(huì)將一臺(tái)服務(wù)器作為一個(gè)幾點(diǎn)。但如果我們考慮到節(jié)點(diǎn)的高可用性骤坐，那么一個(gè)節(jié)點(diǎn)通承餍樱可能是下面的幾種：

• 一個(gè)主 - 主 復(fù)制雙機(jī)結(jié)構(gòu)，擁有一個(gè)主動(dòng)服務(wù)器和被動(dòng)服務(wù)器纽绍。
• 一個(gè)主庫和多個(gè)備庫蕾久。
• 一個(gè)主動(dòng)服務(wù)器，并使用分布式復(fù)制塊設(shè)備（DRBD）作為備用服務(wù)器拌夏。
• 一個(gè)基于存儲(chǔ)區(qū)域網(wǎng)絡(luò)（SAN）的 “集群”僧著。

2.2.1、按功能拆分

按功能拆分障簿，或者說按職責(zé)拆分盹愚，意味著不同的節(jié)點(diǎn)執(zhí)行不同的任務(wù)。

例如站故，如果有一個(gè)網(wǎng)站皆怕，各個(gè)部分無需共享數(shù)據(jù)，那么可以按照網(wǎng)站的功能區(qū)域進(jìn)行劃分西篓。像我們常見的門戶網(wǎng)站愈腾，一般都是把不同欄目放在一起，但實(shí)際上可以將網(wǎng)站新聞污淋、論壇、尋求支持等功能放到專用的 MySQL 服務(wù)器余掖。如圖：

image

2.2.2寸爆、數(shù)據(jù)分片

Sharding 是把數(shù)據(jù)庫橫向擴(kuò)展（Scale Out）到多個(gè)物理節(jié)點(diǎn)上的一種有效的方式，其主要目的是為突破單節(jié)點(diǎn)數(shù)據(jù)庫服務(wù)器的 I/O 能力限制盐欺，解決數(shù)據(jù)庫擴(kuò)展性問題赁豆。Shard這個(gè)詞的意思是“碎片”。如果將一個(gè)數(shù)據(jù)庫當(dāng)作一塊大玻璃或颊，將這塊玻璃打碎溃论，那么每一小塊都稱為數(shù)據(jù)庫的碎片擎勘。將整個(gè)數(shù)據(jù)庫打碎的過程就叫做sharding，可以翻譯為分片节预。

 **一個(gè)shard可以包含多個(gè)表的內(nèi)容甚至可以包含多個(gè)數(shù)據(jù)庫實(shí)例中的內(nèi)容**。每個(gè)shard被放置在一個(gè)數(shù)據(jù)庫服務(wù)器上安拟。**一個(gè)數(shù)據(jù)庫服務(wù)器可以處理一個(gè)或多個(gè)shard的數(shù)據(jù)**。系統(tǒng)中需要有服務(wù)器進(jìn)行查詢路由轉(zhuǎn)發(fā)糠赦，負(fù)責(zé)將查詢轉(zhuǎn)發(fā)到包含該查詢所訪問數(shù)據(jù)的shard或shards節(jié)點(diǎn)上去執(zhí)行。

MySql的Sharding策略包括垂直切分和水平切分兩種淌山。
垂直(縱向)拆分：是指按功能模塊拆分顾瞻，以解決表與表之間的io競(jìng)爭(zhēng)泼疑。比如分為訂單庫、商品庫朋其、用戶庫...這種方式多個(gè)數(shù)據(jù)庫之間的表結(jié)構(gòu)不同王浴。

表結(jié)構(gòu)設(shè)計(jì)垂直切分。常見的一些場(chǎng)景包括：
a). 大字段的垂直切分梅猿。單獨(dú)將大字段建在另外的表中氓辣，提高基礎(chǔ)表的訪問性能，原則上在性能關(guān)鍵的應(yīng)用中應(yīng)當(dāng)避免數(shù)據(jù)庫的大字段
b). 按照使用用途垂直切分袱蚓。例如企業(yè)物料屬性钞啸，可以按照基本屬性、銷售屬性喇潘、采購屬性体斩、生產(chǎn)制造屬性、財(cái)務(wù)會(huì)計(jì)屬性等用途垂直切分
c). 按照訪問頻率垂直切分颖低。例如電子商務(wù)絮吵、Web 2.0系統(tǒng)中，如果用戶屬性設(shè)置非常多忱屑，可以將基本蹬敲、使用頻繁的屬性和不常用的屬性垂直切分開

水平(橫向)拆分：將同一個(gè)表的數(shù)據(jù)進(jìn)行分塊保存到不同的數(shù)據(jù)庫中，來解決單表中數(shù)據(jù)量增長(zhǎng)出現(xiàn)的壓力莺戒。這些數(shù)據(jù)庫中的表結(jié)構(gòu)完全相同伴嗡。

表結(jié)構(gòu)設(shè)計(jì)水平切分。常見的一些場(chǎng)景包括：
a). 比如在線電子商務(wù)網(wǎng)站从铲，訂單表數(shù)據(jù)量過大瘪校，按照年度、月度水平切分
b). Web 2.0網(wǎng)站注冊(cè)用戶名段、在線活躍用戶過多阱扬，按照用戶ID范圍等方式价认，將相關(guān)用戶以及該用戶緊密關(guān)聯(lián)的表做水平切分
c). 例如論壇的置頂帖子用踩，因?yàn)樯婕暗椒猪搯栴}脐彩，每頁都需要顯示置頂貼惠奸，這種情況可以把置頂貼水平切分開來梗掰，避免取置頂帖子時(shí)從所有帖子的表中讀取

2.3及穗、通過多實(shí)例擴(kuò)展

上面提到過埂陆，MySQL 不能完全發(fā)揮現(xiàn)代硬件的性能焚虱。當(dāng)擴(kuò)展到超過 24 個(gè) CPU 核心時(shí)鹃栽，MySQL 的性能開始趨于平緩民鼓，不再上升摹察。當(dāng)內(nèi)存超過 128G 時(shí)也同樣如此。對(duì)于此種情況峭状，我們可以通過多實(shí)例策略充分發(fā)揮硬件的性能优床。

多實(shí)例策略的基本思路是：

1. 數(shù)據(jù)分片足夠小，可以使得在每臺(tái)機(jī)器上都能放置多個(gè)分片移层；
2. 每臺(tái)服務(wù)器運(yùn)行多個(gè)實(shí)例观话；
3. 給每個(gè)實(shí)例劃分服務(wù)器的硬件資源灵迫；

可以看出瀑粥，這是一種向上擴(kuò)展和向外擴(kuò)展的組合方案利凑。這種方案還可以通過將每個(gè) MySQL 實(shí)例綁定到特定的 CPU 核心上來優(yōu)化性能。這種優(yōu)化度气，主要有兩個(gè)好處：

1. 由于 MySQL 內(nèi)部的可擴(kuò)展性限制适荣，當(dāng)核心數(shù)較少時(shí)弛矛，能夠在每個(gè)核心上獲得更好的性能丈氓；
2. 當(dāng)實(shí)例在多個(gè)核心上運(yùn)行線程時(shí)，由于需要在多核心上同步共享數(shù)據(jù)闰歪，因而會(huì)有額外的開銷库倘。

而我們把實(shí)例和 CPU 核心綁定后教翩，可以減少 CPU 核心直接的切換和交互。要注意的靶橱，將進(jìn)程綁定到具有相同物理套接字的核心上可以獲得最優(yōu)的效果。

2.4队寇、向內(nèi)擴(kuò)展

對(duì)于不斷增長(zhǎng)的數(shù)據(jù)和負(fù)載佳遣，最簡(jiǎn)單的方法是對(duì)不再需要的數(shù)據(jù)進(jìn)行歸檔和清理。這種操作可能會(huì)帶來顯著的效果诵盼。這種做法并不能代替其他策略风宁，但可以作為爭(zhēng)取時(shí)間的短期策略，也可以作為處理大數(shù)據(jù)量的長(zhǎng)期計(jì)劃之一饮寞。

在設(shè)計(jì)歸檔和清理策略時(shí)需要考慮如下幾點(diǎn)：

1. 對(duì)應(yīng)用的影響骂际。設(shè)計(jì)良好的歸檔系統(tǒng)能夠在不影響事務(wù)處理的情況下，從一個(gè)高負(fù)債的 OLTP 服務(wù)器上移除數(shù)據(jù)太示。
2. 要?dú)w檔的行类缤。考慮清楚哪些數(shù)據(jù)可以清理或歸檔囱晴。
3. 維護(hù)數(shù)據(jù)一致性驮瞧。數(shù)據(jù)間存在聯(lián)系時(shí)论笔，歸檔任務(wù)系統(tǒng)要能夠保證數(shù)據(jù)的邏輯一致性。
4. 避免數(shù)據(jù)丟失淫痰。歸檔時(shí)要保證歸檔數(shù)據(jù)已經(jīng)成功保存管嬉，再講源數(shù)據(jù)刪除蚯撩。
5. 解除歸檔∮坦剑考慮清楚歸檔系統(tǒng)中的解除歸檔策略揭芍。可以通過設(shè)置一些檢查點(diǎn)讓系統(tǒng)檢查是否有需要?dú)w檔的數(shù)據(jù)卸例。

如果不能及時(shí)的把老數(shù)據(jù)歸檔和清理時(shí)称杨，我們也可以通過以下隔離冷熱數(shù)據(jù)的方式來提高性能：

1. 將表劃分為幾個(gè)部分肌毅。分割大表中的冷熱數(shù)據(jù)，保證加載到內(nèi)存中的數(shù)據(jù)中姑原，熱數(shù)據(jù)的比例悬而；
2. MySQL 分區(qū)。使用MySQL 自帶的分區(qū)的功能锭汛，可以幫助我們把最近的數(shù)據(jù)留在內(nèi)存中眨八；
3. 基于時(shí)間的數(shù)據(jù)分區(qū)闰蚕。如果應(yīng)用不斷有新數(shù)據(jù)盡量盼玄，一般新數(shù)據(jù)總是比舊數(shù)據(jù)更加活躍。因此幼东，我們可以將新數(shù)據(jù)完整的保留在內(nèi)存中，同時(shí)使用復(fù)制來保證主庫失效時(shí)有一份可以的備份吼畏，而舊數(shù)據(jù)就而言放到別的地方没卸。

3、負(fù)載均衡

前端負(fù)載均衡器，根據(jù)服務(wù)器性能情況分發(fā)請(qǐng)求插勤。
目的： 更有效的使用資源。 可用性提高(保證有服務(wù)有用)， 透明膝昆。
跟分片和復(fù)制關(guān)系密切，可以部署在任何一個(gè)環(huán)節(jié)哆致，比如應(yīng)用前端，數(shù)據(jù)庫前端等
可選的方案： DNS, LVS, TCP代理等等酣胀。普遍使用F5， HAProxy

3.1、直接連接

應(yīng)用直連瘫证。不使用中間件完全用業(yè)務(wù)來判斷負(fù)載坑赡，如選擇不同的備庫做不同的邏輯亚铁。

1. 讀寫分離
   寫用主庫然爆，讀用主備分擔(dān)，實(shí)時(shí)性的用主庫肯污，其他用備庫
   讓應(yīng)用檢查復(fù)制延遲拆又，提高容忍臟數(shù)據(jù)的能力
   基于會(huì)話，自己修改的數(shù)據(jù)查看時(shí)查主庫挡爵。
   基于版本竖般，查看下備庫的時(shí)間戳版本類型的字段查看下如果太舊就查主庫
2. 修改DNS
   比較粗的方式，把主庫和備庫綁定在不同的DNS中茶鹃，然后切換涣雕。但是因?yàn)椴皇窃拥模瑫?huì)被緩存等等原因并不是很好用前计。

3.2胞谭、引入中間件

1. 負(fù)載均衡器
   1.一般的負(fù)載均衡器都是HTTP協(xié)議的，但是Mysql需要TCP協(xié)議的男杈，因此要使用能支持TCP協(xié)議的丈屹，但是這不是專門為Mysql設(shè)計(jì)的，還是會(huì)有一些限制伶棒。
   不能很好的均衡旺垒，因?yàn)闊o法知道負(fù)載權(quán)重
   2.均衡器并不能很好的分辨Mysql連接的狀態(tài)，保證他能盡量練到固定的服務(wù)器肤无，提高緩存效率
   3.線程池可能用不到負(fù)載分發(fā)
   4.要求均衡器支持TCP分發(fā)及TCP端口監(jiān)測(cè)等等先蒋。
2. 負(fù)載均衡算法
   1.隨機(jī)
   2.輪詢 依次發(fā)送請(qǐng)求
   3.最少連接數(shù)
   4.最快響應(yīng)
   5.哈希 對(duì)源IP進(jìn)行hash
   6.權(quán)重
   7.排隊(duì)，設(shè)置最大連接數(shù)宛渐。排隊(duì)處理

3.3竞漾、一主多備間的負(fù)載均衡

1. 功能分區(qū)
   報(bào)表眯搭，分析，數(shù)據(jù)倉庫业岁，全文索引等
2. 過濾和數(shù)據(jù)分區(qū)
   通過復(fù)制的過濾功能鳞仙，將不同的數(shù)據(jù)分配在不同的備庫上
3. 保證備庫跟上主庫 MASTER_POS_WAIT()可以保證主庫等待備庫同步
4. 同步寫操作， 有半同步機(jī)制

4笔时、分片和分區(qū)的區(qū)別

Sharding 的思想是從分區(qū)的思想而來棍好，但數(shù)據(jù)庫分區(qū)基本上是數(shù)據(jù)對(duì)象級(jí)別的處理，比如表和索引的分區(qū)允耿，每個(gè)子數(shù)據(jù)集上能夠有不同的物理存儲(chǔ)屬性借笙，還是單個(gè)數(shù)據(jù)庫范圍內(nèi)的操作，而 Sharding 是能夠跨數(shù)據(jù)庫较锡，甚至跨越物理機(jī)器的业稼。

 MySQL5.1提供的分區(qū)(Partition)功能確實(shí)可以實(shí)現(xiàn)表的分區(qū)，但是這種**分區(qū)是局限在單個(gè)數(shù)據(jù)庫范圍里的念链，它不能跨越服務(wù)器的限制盼忌。**如果能夠保證數(shù)據(jù)量很難超過現(xiàn)有數(shù)據(jù)庫服務(wù)器的物理承載量积糯，那么只需利用MySQL5.1提供的分區(qū)(Partition)功能來改善數(shù)據(jù)庫性能即可掂墓；否則，還是考慮應(yīng)用Sharding理念吧看成，spider storage engine就是一個(gè)不錯(cuò)的選擇君编。

image

1、什么是分庫分表川慌？

將一個(gè)表結(jié)構(gòu)分為多個(gè)表吃嘿，或者將一個(gè)表數(shù)據(jù)分片后放入多個(gè)表，這些表可以放在同一個(gè)數(shù)據(jù)庫里梦重，也可以放到不同的數(shù)據(jù)庫中兑燥，甚至可以放到不同的數(shù)據(jù)庫實(shí)例中

2、為什么分庫分表琴拧？

隨著我們的系統(tǒng)運(yùn)行降瞳，存儲(chǔ)在關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)量會(huì)越來越大，系統(tǒng)的訪問的壓力也會(huì)隨之增大蚓胸，如果一個(gè)庫中的表數(shù)據(jù)超過了一定的數(shù)量挣饥，比如說mysql中的表數(shù)據(jù)達(dá)到千萬級(jí)別，就需要考慮進(jìn)行分庫分表沛膳。

比如我們有一張表扔枫，隨著業(yè)務(wù)的不斷進(jìn)行，mysql中表中數(shù)據(jù)量達(dá)到了10億锹安，若是將數(shù)據(jù)存放在一張表中短荐，則性能一定不會(huì)太好倚舀，根據(jù)我們使用的經(jīng)驗(yàn)，mysql數(shù)據(jù)庫一張表的數(shù)據(jù)記錄極限一般在5000萬左右(500w-1000w之間性能比較好)忍宋，所以我們需要對(duì)進(jìn)行分片存儲(chǔ)（水平拆分）瞄桨，按照5000萬一個(gè)單位來拆分的話，需要切片數(shù)量20個(gè)讶踪，也就是20個(gè)數(shù)據(jù)庫表芯侥。

如果將20個(gè)相同業(yè)務(wù)表存放在同一個(gè)數(shù)據(jù)庫中，那么**單個(gè)數(shù)據(jù)庫實(shí)例的網(wǎng)卡I/O乳讥、內(nèi)存柱查、CPU和磁盤性能是有限的，隨著數(shù)據(jù)庫訪問頻率的增加云石，會(huì)導(dǎo)致單個(gè)數(shù)據(jù)庫實(shí)例和數(shù)據(jù)庫達(dá)到性能瓶頸**唉工，因此我們需要將20個(gè)表分到多個(gè)數(shù)據(jù)庫和多個(gè)數(shù)據(jù)庫實(shí)例中

image

3、如何分庫分表汹忠？

3.1淋硝、垂直拆分

根據(jù)業(yè)務(wù)的維度，將原本一個(gè)庫中的表拆分多個(gè)表宽菜，每個(gè)庫中表與原有的結(jié)構(gòu)不同

3.1.1谣膳、垂直分庫

垂直分庫就是根據(jù)業(yè)務(wù)耦合性，將關(guān)聯(lián)度低的不同表存儲(chǔ)在不同的數(shù)據(jù)庫铅乡。做法與大系統(tǒng)拆分為多個(gè)小系統(tǒng)類似继谚，按業(yè)務(wù)分類進(jìn)行獨(dú)立劃分。與"微服務(wù)治理"的做法相似阵幸，每個(gè)微服務(wù)使用單獨(dú)的一個(gè)數(shù)據(jù)庫花履。如圖：

image

3.1.2、垂直分表

垂直分表是基于數(shù)據(jù)庫中的"列"進(jìn)行挚赊，某個(gè)表字段較多诡壁，可以新建一張擴(kuò)展表，將不經(jīng)常用或字段長(zhǎng)度較大的字段拆分出去到擴(kuò)展表中荠割。在字段很多的情況下（例如一個(gè)大表有100多個(gè)字段）妹卿，通過"大表拆小表"，更便于開發(fā)與維護(hù)涨共，也能避免跨頁問題纽帖，MySQL底層是通過數(shù)據(jù)頁存儲(chǔ)的，一條記錄占用空間過大會(huì)導(dǎo)致跨頁举反，造成額外的性能開銷懊直。另外數(shù)據(jù)庫以行為單位將數(shù)據(jù)加載到內(nèi)存中，這樣表中字段長(zhǎng)度較短且訪問頻率較高火鼻，內(nèi)存能加載更多的數(shù)據(jù)室囊，命中率更高雕崩，減少了磁盤IO，從而提升了數(shù)據(jù)庫性能融撞。

image

3.1.3盼铁、優(yōu)缺點(diǎn)

垂直切分的優(yōu)點(diǎn)：

• 解決業(yè)務(wù)系統(tǒng)層面的耦合，業(yè)務(wù)清晰
• 與微服務(wù)的治理類似尝偎，也能對(duì)不同業(yè)務(wù)的數(shù)據(jù)進(jìn)行分級(jí)管理饶火、維護(hù)、監(jiān)控致扯、擴(kuò)展等
• 高并發(fā)場(chǎng)景下肤寝，垂直切分一定程度的提升IO、數(shù)據(jù)庫連接數(shù)抖僵、單機(jī)硬件資源的瓶頸

缺點(diǎn)：

• 部分表無法join鲤看，只能通過接口聚合方式解決，提升了開發(fā)的復(fù)雜度
• 分布式事務(wù)處理復(fù)雜
• 依然存在單表數(shù)據(jù)量過大的問題（需要水平切分）

3.2耍群、水平拆分

根據(jù)分片算法义桂，將一個(gè)庫拆分成多個(gè)庫，每個(gè)庫依舊保留原有的結(jié)構(gòu)

當(dāng)一個(gè)應(yīng)用難以再細(xì)粒度的垂直切分蹈垢，或切分后數(shù)據(jù)量行數(shù)巨大慷吊，存在單庫讀寫、存儲(chǔ)性能瓶頸耘婚，這時(shí)候就需要進(jìn)行水平切分了罢浇。

水平切分分為庫內(nèi)分表和分庫分表陆赋，是根據(jù)表內(nèi)數(shù)據(jù)內(nèi)在的邏輯關(guān)系沐祷，將同一個(gè)表按不同的條件分散到多個(gè)數(shù)據(jù)庫或多個(gè)表中，每個(gè)表中只包含一部分?jǐn)?shù)據(jù)攒岛，從而使得單個(gè)表的數(shù)據(jù)量變小赖临，達(dá)到分布式的效果。如圖所示：

image

庫內(nèi)分表只解決了單一表數(shù)據(jù)量過大的問題灾锯，但沒有將表分布到不同機(jī)器的庫上兢榨，因此對(duì)于減輕MySQL數(shù)據(jù)庫的壓力來說，幫助不是很大顺饮，大家還是競(jìng)爭(zhēng)同一個(gè)物理機(jī)的CPU吵聪、內(nèi)存、網(wǎng)絡(luò)IO兼雄，最好通過分庫分表來解決吟逝。

3.2.1、優(yōu)缺點(diǎn)

水平切分的優(yōu)點(diǎn)：

• 不存在單庫數(shù)據(jù)量過大赦肋、高并發(fā)的性能瓶頸块攒，提升系統(tǒng)穩(wěn)定性和負(fù)載能力
• 應(yīng)用端改造較小励稳，不需要拆分業(yè)務(wù)模塊

缺點(diǎn)：

• 跨分片的事務(wù)一致性難以保證
• 跨庫的join關(guān)聯(lián)查詢性能較差
• 數(shù)據(jù)多次擴(kuò)展難度和維護(hù)量極大

3.2.2、幾種分片規(guī)則

水平切分后同一張表會(huì)出現(xiàn)在多個(gè)數(shù)據(jù)庫/表中囱井，每個(gè)庫/表的內(nèi)容不同驹尼。幾種典型的數(shù)據(jù)分片規(guī)則為：

1、根據(jù)數(shù)值范圍

按照時(shí)間區(qū)間或ID區(qū)間來切分庞呕。例如：按日期將不同月甚至是日的數(shù)據(jù)分散到不同的庫中新翎；將userId為1_{9999的記錄分到第一個(gè)庫，10000}20000的分到第二個(gè)庫住练，以此類推料祠。某種意義上，某些系統(tǒng)中使用的"冷熱數(shù)據(jù)分離"澎羞，將一些使用較少的歷史數(shù)據(jù)遷移到其他庫中髓绽，業(yè)務(wù)功能上只提供熱點(diǎn)數(shù)據(jù)的查詢，也是類似的實(shí)踐妆绞。

這樣的優(yōu)點(diǎn)在于：

• 單表大小可控
• 天然便于水平擴(kuò)展顺呕，后期如果想對(duì)整個(gè)分片集群擴(kuò)容時(shí)，只需要添加節(jié)點(diǎn)即可括饶，無需對(duì)其他分片的數(shù)據(jù)進(jìn)行遷移
• 使用分片字段進(jìn)行范圍查找時(shí)株茶，連續(xù)分片可快速定位分片進(jìn)行快速查詢，有效避免跨分片查詢的問題图焰。

缺點(diǎn)：

• 熱點(diǎn)數(shù)據(jù)成為性能瓶頸启盛。連續(xù)分片可能存在數(shù)據(jù)熱點(diǎn)，例如按時(shí)間字段分片技羔，有些分片存儲(chǔ)最近時(shí)間段內(nèi)的數(shù)據(jù)僵闯，可能會(huì)被頻繁的讀寫，而有些分片存儲(chǔ)的歷史數(shù)據(jù)藤滥，則很少被查詢

image

2鳖粟、根據(jù)數(shù)值取模

一般采用hash取模mod的切分方式，例如：將 Customer 表根據(jù) cusno 字段切分到4個(gè)庫中拙绊，余數(shù)為0的放到第一個(gè)庫向图，余數(shù)為1的放到第二個(gè)庫，以此類推标沪。這樣同一個(gè)用戶的數(shù)據(jù)會(huì)分散到同一個(gè)庫中榄攀，如果查詢條件帶有cusno字段，則可明確定位到相應(yīng)庫去查詢金句。

優(yōu)點(diǎn)：

• 數(shù)據(jù)分片相對(duì)比較均勻檩赢，不容易出現(xiàn)熱點(diǎn)和并發(fā)訪問的瓶頸

缺點(diǎn)：

• 后期分片集群擴(kuò)容時(shí)，需要遷移舊的數(shù)據(jù)（使用一致性hash算法能較好的避免這個(gè)問題）
• 容易面臨跨分片查詢的復(fù)雜問題趴梢。比如上例中漠畜，如果頻繁用到的查詢條件中不帶cusno時(shí)币他，將會(huì)導(dǎo)致無法定位數(shù)據(jù)庫，從而需要同時(shí)向4個(gè)庫發(fā)起查詢憔狞，再在內(nèi)存中合并數(shù)據(jù)蝴悉，取最小集返回給應(yīng)用，分庫反而成為拖累瘾敢。

image

4拍冠、分庫分表帶來的問題

分庫分表能有效的緩解單機(jī)和單庫帶來的性能瓶頸和壓力，突破網(wǎng)絡(luò)IO簇抵、硬件資源庆杜、連接數(shù)的瓶頸，同時(shí)也帶來了一些問題碟摆。下面將描述這些技術(shù)挑戰(zhàn)以及對(duì)應(yīng)的解決思路晃财。

4.1、事務(wù)一致性問題

• 分布式事務(wù)

當(dāng)更新內(nèi)容同時(shí)分布在不同庫中典蜕，不可避免會(huì)帶來跨庫事務(wù)問題断盛。跨分片事務(wù)也是分布式事務(wù)愉舔，沒有簡(jiǎn)單的方案钢猛，一般可使用"XA協(xié)議"和"兩階段提交"處理。

分布式事務(wù)能最大限度保證了數(shù)據(jù)庫操作的原子性轩缤。但在提交事務(wù)時(shí)需要協(xié)調(diào)多個(gè)節(jié)點(diǎn)命迈，推后了提交事務(wù)的時(shí)間點(diǎn)，延長(zhǎng)了事務(wù)的執(zhí)行時(shí)間火的。導(dǎo)致事務(wù)在訪問共享資源時(shí)發(fā)生沖突或死鎖的概率增高壶愤。隨著數(shù)據(jù)庫節(jié)點(diǎn)的增多，這種趨勢(shì)會(huì)越來越嚴(yán)重卫玖，從而成為系統(tǒng)在數(shù)據(jù)庫層面上水平擴(kuò)展的枷鎖公你。

• 最終一致性

對(duì)于那些性能要求很高，但對(duì)一致性要求不高的系統(tǒng)假瞬，往往不苛求系統(tǒng)的實(shí)時(shí)一致性，只要在允許的時(shí)間段內(nèi)達(dá)到最終一致性即可迂尝，可采用事務(wù)補(bǔ)償?shù)姆绞酵衍浴Ｅc事務(wù)在執(zhí)行中發(fā)生錯(cuò)誤后立即回滾的方式不同，事務(wù)補(bǔ)償是一種事后檢查補(bǔ)救的措施垄开，一些常見的實(shí)現(xiàn)方法有：對(duì)數(shù)據(jù)進(jìn)行對(duì)賬檢查琴许，基于日志進(jìn)行對(duì)比，定期同標(biāo)準(zhǔn)數(shù)據(jù)來源進(jìn)行同步等等溉躲。事務(wù)補(bǔ)償還要結(jié)合業(yè)務(wù)系統(tǒng)來考慮

4.2榜田、跨節(jié)點(diǎn)關(guān)聯(lián)查詢 join 問題

切分之前益兄，系統(tǒng)中很多列表和詳情頁所需的數(shù)據(jù)可以通過sql join來完成。而切分之后箭券，數(shù)據(jù)可能分布在不同的節(jié)點(diǎn)上净捅，此時(shí)join帶來的問題就比較麻煩了，考慮到性能辩块，盡量避免使用join查詢蛔六。

解決這個(gè)問題的一些方法：

1）全局表

全局表，也可看做是"數(shù)據(jù)字典表"废亭，就是系統(tǒng)中所有模塊都可能依賴的一些表国章，為了避免跨庫join查詢，可以將這類表在每個(gè)數(shù)據(jù)庫中都保存一份豆村。這些數(shù)據(jù)通常很少會(huì)進(jìn)行修改液兽，所以也不擔(dān)心一致性的問題。

2）字段冗余

一種典型的反范式設(shè)計(jì)掌动，利用空間換時(shí)間抵碟，為了性能而避免join查詢。例如：訂單表保存userId時(shí)候坏匪，也將userName冗余保存一份拟逮，這樣查詢訂單詳情時(shí)就不需要再去查詢"買家user表"了。

但這種方法適用場(chǎng)景也有限适滓，比較適用于依賴字段比較少的情況敦迄。而冗余字段的數(shù)據(jù)一致性也較難保證，就像上面訂單表的例子凭迹，買家修改了userName后罚屋，是否需要在歷史訂單中同步更新呢？這也要結(jié)合實(shí)際業(yè)務(wù)場(chǎng)景進(jìn)行考慮嗅绸。

3）數(shù)據(jù)組裝

在系統(tǒng)層面脾猛，分兩次查詢，第一次查詢的結(jié)果集中找出關(guān)聯(lián)數(shù)據(jù)id鱼鸠，然后根據(jù)id發(fā)起第二次請(qǐng)求得到關(guān)聯(lián)數(shù)據(jù)猛拴。最后將獲得到的數(shù)據(jù)進(jìn)行字段拼裝。

4）ER分片

關(guān)系型數(shù)據(jù)庫中蚀狰，如果可以先確定表之間的關(guān)聯(lián)關(guān)系愉昆，并將那些存在關(guān)聯(lián)關(guān)系的表記錄存放在同一個(gè)分片上，那么就能較好的避免跨分片join問題麻蹋。在1:1或1:n的情況下跛溉，通常按照主表的ID主鍵切分。如下圖所示：

image

4.3、全局主鍵避重問題

在分庫分表環(huán)境中芳室，由于表中數(shù)據(jù)同時(shí)存在不同數(shù)據(jù)庫中专肪，主鍵值平時(shí)使用的自增長(zhǎng)將無用武之地，某個(gè)分區(qū)數(shù)據(jù)庫自生成的ID無法保證全局唯一堪侯。因此需要單獨(dú)設(shè)計(jì)全局主鍵嚎尤，以避免跨庫主鍵重復(fù)問題。