來(lái)源：https://juejin.im/post/6844903992909103117

數(shù)據(jù)庫(kù)瓶頸

不管是IO瓶頸還是CPU瓶頸，最終都會(huì)導(dǎo)致數(shù)據(jù)庫(kù)的活躍連接數(shù)增加，進(jìn)而逼近甚至達(dá)到數(shù)據(jù)庫(kù)可承載的活躍連接數(shù)的閾值。在業(yè)務(wù)service來(lái)看，

就是可用數(shù)據(jù)庫(kù)連接少甚至無(wú)連接可用，接下來(lái)就可以想象了（并發(fā)量、吞吐量、崩潰）。

IO瓶頸

• 第一種：磁盤(pán)讀IO瓶頸，熱點(diǎn)數(shù)據(jù)太多，數(shù)據(jù)庫(kù)緩存放不下，每次查詢會(huì)產(chǎn)生大量的IO，降低查詢速度->分庫(kù)和垂直分表

• 第二種：網(wǎng)絡(luò)IO瓶頸，請(qǐng)求的數(shù)據(jù)太多，網(wǎng)絡(luò)帶寬不夠 ->分庫(kù)

CPU瓶頸

• 第一種：SQl問(wèn)題：如SQL中包含join,group by, order by，非索引字段條件查詢等，增加CPU運(yùn)算的操作->SQL優(yōu)化，建立合適的索引，在業(yè)務(wù)Service層進(jìn)行業(yè)務(wù)計(jì)算。

• 第二種：?jiǎn)伪頂?shù)據(jù)量太大，查詢時(shí)掃描的行太多，SQl效率低，增加CPU運(yùn)算的操作。->水平分表。

分庫(kù)分表

水平分庫(kù)

1、概念：以字段為依據(jù)，按照一定策略（hash、range等），將一個(gè)庫(kù)中的數(shù)據(jù)拆分到多個(gè)庫(kù)中。

2、結(jié)果：

• 每個(gè)庫(kù)的結(jié)構(gòu)都一樣

• 每個(gè)庫(kù)中的數(shù)據(jù)不一樣，沒(méi)有交集

• 所有庫(kù)的數(shù)據(jù)并集是全量數(shù)據(jù)

3、場(chǎng)景：系統(tǒng)絕對(duì)并發(fā)量上來(lái)了，分表難以根本上解決問(wèn)題，并且還沒(méi)有明顯的業(yè)務(wù)歸屬來(lái)垂直分庫(kù)的情況下。

4、分析：庫(kù)多了，io和cpu的壓力自然可以成倍緩解

水平分表

1、概念：以字段為依據(jù)，按照一定策略（hash、range等），講一個(gè)表中的數(shù)據(jù)拆分到多個(gè)表中。
2、結(jié)果：

• 每個(gè)表的結(jié)構(gòu)都一樣

• 每個(gè)表的數(shù)據(jù)不一樣，沒(méi)有交集，所有表的并集是全量數(shù)據(jù)。

3、場(chǎng)景：系統(tǒng)絕對(duì)并發(fā)量沒(méi)有上來(lái)，只是單表的數(shù)據(jù)量太多，影響了SQL效率，加重了CPU負(fù)擔(dān)，以至于成為瓶頸，可以考慮水平分表。
4、分析：?jiǎn)伪淼臄?shù)據(jù)量少了，單次執(zhí)行SQL執(zhí)行效率高了，自然減輕了CPU的負(fù)擔(dān)。

垂直分庫(kù)

1、概念：以表為依據(jù)，按照業(yè)務(wù)歸屬不同，將不同的表拆分到不同的庫(kù)中。
2、結(jié)果：

• 每個(gè)庫(kù)的結(jié)構(gòu)都不一樣

• 每個(gè)庫(kù)的數(shù)據(jù)也不一樣，沒(méi)有交集

• 所有庫(kù)的并集是全量數(shù)據(jù)

3、場(chǎng)景：系統(tǒng)絕對(duì)并發(fā)量上來(lái)了，并且可以抽象出單獨(dú)的業(yè)務(wù)模塊的情況下。
4、分析：到這一步，基本上就可以服務(wù)化了。例如：隨著業(yè)務(wù)的發(fā)展，一些公用的配置表、字典表等越來(lái)越多，這時(shí)可以將這些表拆到單獨(dú)的庫(kù)中，甚至可以服務(wù)化。再者，隨著業(yè)務(wù)的發(fā)展孵化出了一套業(yè)務(wù)模式，這時(shí)可以將相關(guān)的表拆到單獨(dú)的庫(kù)中，甚至可以服務(wù)化。

垂直分表

1、概念：以字段為依據(jù)，按照字段的活躍性，將表中字段拆到不同的表中（主表和擴(kuò)展表）。

2、結(jié)果：

• 每個(gè)表的結(jié)構(gòu)不一樣。

• 每個(gè)表的數(shù)據(jù)也不一樣，一般來(lái)說(shuō)，每個(gè)表的字段至少有一列交集，一般是主鍵，用于關(guān)聯(lián)數(shù)據(jù)。

• 所有表的并集是全量數(shù)據(jù)。3、場(chǎng)景：系統(tǒng)絕對(duì)并發(fā)量并沒(méi)有上來(lái)，表的記錄并不多，但是字段多，并且熱點(diǎn)數(shù)據(jù)和非熱點(diǎn)數(shù)據(jù)在一起，單行數(shù)據(jù)所需的存儲(chǔ)空間較大，以至于數(shù)據(jù)庫(kù)緩存的數(shù)據(jù)行減少，查詢時(shí)回去讀磁盤(pán)數(shù)據(jù)產(chǎn)生大量隨機(jī)讀IO，產(chǎn)生IO瓶頸。

4、分析：可以用列表頁(yè)和詳情頁(yè)來(lái)幫助理解。垂直分表的拆分原則是將熱點(diǎn)數(shù)據(jù)（可能經(jīng)常會(huì)查詢的數(shù)據(jù)）放在一起作為主表，非熱點(diǎn)數(shù)據(jù)放在一起作為擴(kuò)展表，這樣更多的熱點(diǎn)數(shù)據(jù)就能被緩存下來(lái)，進(jìn)而減少了隨機(jī)讀IO。拆了之后，要想獲取全部數(shù)據(jù)就需要關(guān)聯(lián)兩個(gè)表來(lái)取數(shù)據(jù)。

但記住千萬(wàn)別用join，因?yàn)镴oin不僅會(huì)增加CPU負(fù)擔(dān)并且會(huì)將兩個(gè)表耦合在一起（必須在一個(gè)數(shù)據(jù)庫(kù)實(shí)例上）。關(guān)聯(lián)數(shù)據(jù)應(yīng)該在service層進(jìn)行，分別獲取主表和擴(kuò)展表的數(shù)據(jù)，然后用關(guān)聯(lián)字段關(guān)聯(lián)得到全部數(shù)據(jù)。

分庫(kù)分表工具

• sharding-jdbc（當(dāng)當(dāng)）

• TSharding（蘑菇街）

• Atlas（奇虎360）

• Cobar（阿里巴巴）

• MyCAT（基于Cobar）

• Oceanus（58同城）

• Vitess（谷歌） 各種工具的利弊自查

分庫(kù)分表帶來(lái)的問(wèn)題

分庫(kù)分表能有效緩解單機(jī)和單表帶來(lái)的性能瓶頸和壓力，突破網(wǎng)絡(luò)IO、硬件資源、連接數(shù)的瓶頸，同時(shí)也帶來(lái)一些問(wèn)題，下面將描述這些問(wèn)題和解決思路。

事務(wù)一致性問(wèn)題

分布式事務(wù)

當(dāng)更新內(nèi)容同時(shí)存在于不同庫(kù)找那個(gè)，不可避免會(huì)帶來(lái)跨庫(kù)事務(wù)問(wèn)題?？绶制聞?wù)也是分布式事務(wù)，沒(méi)有簡(jiǎn)單的方案，一般可使用“XA協(xié)議”和“兩階段提交”處理。
分布式事務(wù)能最大限度保證了數(shù)據(jù)庫(kù)操作的原子性。但在提交事務(wù)時(shí)需要協(xié)調(diào)多個(gè)節(jié)點(diǎn)，推后了提交事務(wù)的時(shí)間點(diǎn)，延長(zhǎng)了事務(wù)的執(zhí)行時(shí)間，導(dǎo)致事務(wù)在訪問(wèn)共享資源時(shí)發(fā)生沖突或死鎖的概率增高。隨著數(shù)據(jù)庫(kù)節(jié)點(diǎn)的增多，這種趨勢(shì)會(huì)越來(lái)越嚴(yán)重，從而成為系統(tǒng)在數(shù)據(jù)庫(kù)層面上水平擴(kuò)展的枷鎖。

最終一致性

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

跨節(jié)點(diǎn)關(guān)聯(lián)查詢join問(wèn)題

切分之前，系統(tǒng)中很多列表和詳情表的數(shù)據(jù)可以通過(guò)join來(lái)完成，但是切分之后，數(shù)據(jù)可能分布在不同的節(jié)點(diǎn)上，此時(shí)join帶來(lái)的問(wèn)題就比較麻煩了，考慮到性能，盡量避免使用Join查詢。解決的一些方法：

全局表

全局表，也可看做“數(shù)據(jù)字典表”，就是系統(tǒng)中所有模塊都可能依賴的一些表，為了避免庫(kù)join查詢，可以將這類(lèi)表在每個(gè)數(shù)據(jù)庫(kù)中都保存一份。這些數(shù)據(jù)通常很少修改，所以不必?fù)?dān)心一致性的問(wèn)題。

字段冗余

一種典型的反范式設(shè)計(jì)，利用空間換時(shí)間，為了性能而避免join查詢。例如，訂單表在保存userId的時(shí)候，也將userName也冗余的保存一份，這樣查詢訂單詳情順表就可以查到用戶名userName，就不用查詢買(mǎi)家user表了。但這種方法適用場(chǎng)景也有限，比較適用依賴字段比較少的情況，而冗余字段的一致性也較難保證。

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

在系統(tǒng)service業(yè)務(wù)層面，分兩次查詢，第一次查詢的結(jié)果集找出關(guān)聯(lián)的數(shù)據(jù)id，然后根據(jù)id發(fā)起器二次請(qǐng)求得到關(guān)聯(lián)數(shù)據(jù)，最后將獲得的結(jié)果進(jìn)行字段組裝。這是比較常用的方法。

ER分片

關(guān)系型數(shù)據(jù)庫(kù)中，如果已經(jīng)確定了表之間的關(guān)聯(lián)關(guān)系（如訂單表和訂單詳情表），并且將那些存在關(guān)聯(lián)關(guān)系的表記錄存放在同一個(gè)分片上，那么就能較好地避免跨分片join的問(wèn)題，可以在一個(gè)分片內(nèi)進(jìn)行join。在1:1或1：n的情況下，通常按照主表的ID進(jìn)行主鍵切分。

跨節(jié)點(diǎn)分頁(yè)、排序、函數(shù)問(wèn)題

跨節(jié)點(diǎn)多庫(kù)進(jìn)行查詢時(shí)，會(huì)出現(xiàn)limit分頁(yè)、order by
排序等問(wèn)題。分頁(yè)需要按照指定字段進(jìn)行排序，當(dāng)排序字段就是分頁(yè)字段時(shí)，通過(guò)分片規(guī)則就比較容易定位到指定的分片；當(dāng)排序字段非分片字段時(shí)，就變得比較復(fù)雜.
需要先在不同的分片節(jié)點(diǎn)中將數(shù)據(jù)進(jìn)行排序并返回，然后將不同分片返回的結(jié)果集進(jìn)行匯總和再次排序，最終返回給用戶 如下圖：

上圖只是取第一頁(yè)的數(shù)據(jù)，對(duì)性能影響還不是很大。但是如果取得頁(yè)數(shù)很大，情況就變得復(fù)雜的多，因?yàn)楦鞣制?jié)點(diǎn)中的數(shù)據(jù)可能是隨機(jī)的，為了排序的準(zhǔn)確性，需要將所有節(jié)點(diǎn)的前N頁(yè)數(shù)據(jù)都排序好做合并，最后再進(jìn)行整體排序，這樣的操作很耗費(fèi)CPU和內(nèi)存資源，所以頁(yè)數(shù)越大，系統(tǒng)性能就會(huì)越差。

在使用Max、Min、Sum、Count之類(lèi)的函數(shù)進(jìn)行計(jì)算的時(shí)候，也需要先在每個(gè)分片上執(zhí)行相應(yīng)的函數(shù)，然后將各個(gè)分片的結(jié)果集進(jìn)行匯總再次計(jì)算。

全局主鍵避重問(wèn)題

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

UUID

UUID標(biāo)準(zhǔn)形式是32個(gè)16進(jìn)制數(shù)字，分為5段，形式是8-4-4-4-12的36個(gè)字符。
UUID是最簡(jiǎn)單的方案，本地生成，性能高，沒(méi)有網(wǎng)絡(luò)耗時(shí)，但是缺點(diǎn)明顯，占用存儲(chǔ)空間多，另外作為主鍵建立索引和基于索引進(jìn)行查詢都存在性能問(wèn)題，尤其是InnoDb引擎下，UUID的無(wú)序性會(huì)導(dǎo)致索引位置頻繁變動(dòng)，導(dǎo)致分頁(yè)。

結(jié)合數(shù)據(jù)庫(kù)維護(hù)主鍵ID表

在數(shù)據(jù)庫(kù)中建立sequence表：

CREATE TABLE `sequence` ( `id` bigint(20) unsigned NOT NULL auto_increment, `stub` char(1) NOT NULL default '',??
??????PRIMARY KEY (`id`), UNIQUE KEY `stub` (`stub`)??
????) ENGINE=MyISAM;

stub字段設(shè)置為唯一索引，同一stub值在sequence表中只有一條記錄，可以同時(shí)為多張表生辰全局ID。使用MyISAM引擎而不是InnoDb，已獲得更高的性能。MyISAM使用的是表鎖，對(duì)表的讀寫(xiě)是串行的，所以不用擔(dān)心并發(fā)時(shí)兩次讀取同一個(gè)ID。當(dāng)需要全局唯一的ID時(shí)，執(zhí)行：

REPLACE INTO sequence (stub) VALUES ('a'); SELECT 1561439;

此方案較為簡(jiǎn)單，但缺點(diǎn)較為明顯：存在單點(diǎn)問(wèn)題，強(qiáng)依賴DB，當(dāng)DB異常時(shí)，整個(gè)系統(tǒng)不可用。配置主從可以增加可用性。另外性能瓶頸限制在單臺(tái)Mysql的讀寫(xiě)性能。

另有一種主鍵生成策略，類(lèi)似sequence表方案，更好的解決了單點(diǎn)和性能瓶頸問(wèn)題。這一方案的整體思想是：建立2個(gè)以上的全局ID生成的服務(wù)器，每個(gè)服務(wù)器上只部署一個(gè)數(shù)據(jù)庫(kù)，每個(gè)庫(kù)有一張sequence表用于記錄當(dāng)前全局ID。
表中增長(zhǎng)的步長(zhǎng)是庫(kù)的數(shù)量，起始值依次錯(cuò)開(kāi)，這樣就能將ID的生成散列到各個(gè)數(shù)據(jù)庫(kù)上

這種方案將生成ID的壓力均勻分布在兩臺(tái)機(jī)器上，同時(shí)提供了系統(tǒng)容錯(cuò)，第一臺(tái)出現(xiàn)了錯(cuò)誤，可以自動(dòng)切換到第二臺(tái)獲取ID。但有幾個(gè)缺點(diǎn)：系統(tǒng)添加機(jī)器，水平擴(kuò)展較復(fù)雜；每次獲取ID都要讀取一次DB，DB的壓力還是很大，只能通過(guò)堆機(jī)器來(lái)提升性能。

Snowflake分布式自增ID算法

Twitter的snowfalke算法解決了分布式系統(tǒng)生成全局ID的需求，生成64位Long型數(shù)字，組成部分：

• 第一位未使用

• 接下來(lái)的41位是毫秒級(jí)時(shí)間，41位的長(zhǎng)度可以表示69年的時(shí)間

• 5位datacenterId,5位workerId。10位長(zhǎng)度最多支持部署1024個(gè)節(jié)點(diǎn)

• 最后12位是毫秒內(nèi)計(jì)數(shù)，12位的計(jì)數(shù)順序號(hào)支持每個(gè)節(jié)點(diǎn)每毫秒產(chǎn)生4096個(gè)ID序列。

數(shù)據(jù)遷移、擴(kuò)容問(wèn)題

當(dāng)業(yè)務(wù)高速發(fā)展、面臨性能和存儲(chǔ)瓶頸時(shí)，才會(huì)考慮分片設(shè)計(jì)，此時(shí)就不可避免的需要考慮歷史數(shù)據(jù)的遷移問(wèn)題。一般做法是先讀出歷史數(shù)據(jù)，然后按照指定的分片規(guī)則再將數(shù)據(jù)寫(xiě)入到各分片節(jié)點(diǎn)中。此外還需要根據(jù)當(dāng)前的數(shù)據(jù)量個(gè)QPS，以及業(yè)務(wù)發(fā)展速度，進(jìn)行容量規(guī)劃，推算出大概需要多少分片（一般建議單個(gè)分片的單表數(shù)據(jù)量不超過(guò)1000W）

什么時(shí)候考慮分庫(kù)分表

能不分就不分

并不是所有表都需要切分，主要還是看數(shù)據(jù)的增長(zhǎng)速度。切分后在某種程度上提升了業(yè)務(wù)的復(fù)雜程度。不到萬(wàn)不得已不要輕易使用分庫(kù)分表這個(gè)“大招”，避免“過(guò)度設(shè)計(jì)”和“過(guò)早優(yōu)化”。分庫(kù)分表之前，先盡力做力所能及的優(yōu)化：升級(jí)硬件、升級(jí)網(wǎng)絡(luò)、讀寫(xiě)分離、索引優(yōu)化等。當(dāng)數(shù)據(jù)量達(dá)到單表瓶頸后，在考慮分庫(kù)分表。

數(shù)據(jù)量過(guò)大，正常運(yùn)維影響業(yè)務(wù)訪問(wèn)

這里的運(yùn)維是指：

• 對(duì)數(shù)據(jù)庫(kù)備份，如果單表太大，備份時(shí)需要大量的磁盤(pán)IO和網(wǎng)絡(luò)IO

• 對(duì)一個(gè)很大的表做DDL，MYSQL會(huì)鎖住整個(gè)表，這個(gè)時(shí)間會(huì)很長(zhǎng)，這段時(shí)間業(yè)務(wù)不能訪問(wèn)此表，影響很大。

• 大表經(jīng)常訪問(wèn)和更新，就更有可能出現(xiàn)鎖等待。

隨著業(yè)務(wù)發(fā)展，需要對(duì)某些字段垂直拆分

這里就不舉例了。在實(shí)際業(yè)務(wù)中都可能會(huì)碰到，有些不經(jīng)常訪問(wèn)或者更新頻率低的字段應(yīng)該從大表中分離出去。

數(shù)據(jù)量快速增長(zhǎng)

隨著業(yè)務(wù)的快速發(fā)展，單表中的數(shù)據(jù)量會(huì)持續(xù)增長(zhǎng)，當(dāng)性能接近瓶頸時(shí)，就需要考慮水平切分，做分庫(kù)分表了。

參考鏈接：

• https://www.cnblogs.com/butterfly100/p/9034281.html

• https://www.cnblogs.com/littlecharacter/p/9342129.html