在高并發(fā)場(chǎng)景下，為提升數(shù)據(jù)庫(kù)性能和安全性，常采用讀寫分離的優(yōu)化方案。這種方法利用主從復(fù)制技術(shù)，將數(shù)據(jù)復(fù)制為多份，從而提升對(duì)大量并發(fā)讀請(qǐng)求的處理能力，增強(qiáng)數(shù)據(jù)庫(kù)的查詢性能。同時(shí)，通過(guò)在多個(gè)節(jié)點(diǎn)中存儲(chǔ)完整數(shù)據(jù)，進(jìn)一步保障數(shù)據(jù)的安全性。當(dāng)某個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)（主庫(kù)或從庫(kù)）發(fā)生故障時(shí)，系統(tǒng)仍能依賴其他節(jié)點(diǎn)的完整數(shù)據(jù)來(lái)保證數(shù)據(jù)的可用性，不會(huì)造成數(shù)據(jù)丟失。

在電商系統(tǒng)中引入讀寫分離后，架構(gòu)示例如下：

• 主庫(kù)：負(fù)責(zé)所有寫操作（如新增、更新、刪除等），并將數(shù)據(jù)同步至多個(gè)從庫(kù)。
• 從庫(kù)：專用于處理讀操作，從而分擔(dān)主庫(kù)的查詢壓力。
• 負(fù)載均衡：在處理讀請(qǐng)求時(shí)，系統(tǒng)將流量分配至不同的從庫(kù)節(jié)點(diǎn)，以提高查詢性能。
• 故障恢復(fù)：若某個(gè)節(jié)點(diǎn)宕機(jī)，系統(tǒng)仍能利用其他節(jié)點(diǎn)的數(shù)據(jù)來(lái)提供正常服務(wù)。

圖片

在電商系統(tǒng)的訂單量突破五千萬(wàn)后，盡管流量的提升是好消息，但也帶來(lái)了前所未有的數(shù)據(jù)庫(kù)壓力?，F(xiàn)有的單表存儲(chǔ)方式難以承載如此龐大的數(shù)據(jù)量，查詢和寫入性能都在下降，且磁盤空間告警頻發(fā)。為保證系統(tǒng)正常運(yùn)轉(zhuǎn)，我分析了當(dāng)前面臨的主要問(wèn)題，并尋求相應(yīng)的解決方案。

1. 查詢性能問(wèn)題

系統(tǒng)正在持續(xù)擴(kuò)展，用戶和訂單數(shù)據(jù)迅速增長(zhǎng)，導(dǎo)致數(shù)據(jù)庫(kù)單表數(shù)據(jù)量突破千萬(wàn)甚至億級(jí)別。這時(shí)，即便使用了索引，隨著數(shù)據(jù)量的增加，索引占用的空間也逐漸增大。當(dāng)數(shù)據(jù)庫(kù)無(wú)法緩存全量索引信息時(shí)，查詢便需要頻繁從磁盤讀取索引數(shù)據(jù)，從而降低查詢性能。

解決方案：優(yōu)化查詢性能的關(guān)鍵在于減少索引的壓力。一種方法是對(duì)數(shù)據(jù)進(jìn)行分片，將數(shù)據(jù)按一定規(guī)則分散到多個(gè)表或庫(kù)中，縮小單個(gè)表的索引范圍。此外，也可考慮將查詢請(qǐng)求引導(dǎo)至專門的從庫(kù)，進(jìn)一步分?jǐn)傊鲙?kù)壓力。

2. 數(shù)據(jù)量增長(zhǎng)引發(fā)的存儲(chǔ)問(wèn)題

隨著訂單數(shù)據(jù)的持續(xù)增加，數(shù)據(jù)庫(kù)的磁盤空間消耗加劇，備份和恢復(fù)時(shí)間變長(zhǎng)，給系統(tǒng)帶來(lái)了存儲(chǔ)和恢復(fù)的雙重壓力。

解決方案：為了讓數(shù)據(jù)庫(kù)支持大規(guī)模數(shù)據(jù)量，可以采用分庫(kù)分表策略，將數(shù)據(jù)分散存儲(chǔ)到不同的物理庫(kù)中，緩解單機(jī)磁盤存儲(chǔ)的瓶頸。這不僅減少了備份時(shí)間，也縮短了數(shù)據(jù)恢復(fù)時(shí)間，從而保障系統(tǒng)的高可用性。

3. 模塊故障隔離問(wèn)題

當(dāng)前系統(tǒng)中，不同模塊的數(shù)據(jù)（如用戶數(shù)據(jù)和用戶關(guān)系數(shù)據(jù)）都存儲(chǔ)在同一個(gè)主庫(kù)中。一旦主庫(kù)發(fā)生故障，所有模塊的服務(wù)都會(huì)受到影響。

解決方案：為實(shí)現(xiàn)模塊的故障隔離，可以對(duì)不同模塊的數(shù)據(jù)進(jìn)行邏輯分庫(kù)，將各模塊的數(shù)據(jù)分散到不同的數(shù)據(jù)庫(kù)實(shí)例中。這樣，即便某個(gè)模塊的數(shù)據(jù)庫(kù)出現(xiàn)問(wèn)題，其他模塊依然能夠正常運(yùn)行，增強(qiáng)了系統(tǒng)的魯棒性。

4. 高并發(fā)寫入帶來(lái)的性能瓶頸

基于測(cè)試數(shù)據(jù)，當(dāng)前在 4 核 8G 的云服務(wù)器上，MySQL 5.7 的寫入性能（約 500 TPS）遠(yuǎn)低于查詢性能（約 10000 QPS）。隨著系統(tǒng)寫入請(qǐng)求量的增加，寫入壓力日益加重，單一數(shù)據(jù)庫(kù)實(shí)例難以支撐更高的并發(fā)寫入。

解決方案：為解決高并發(fā)寫入問(wèn)題，分庫(kù)分表是一種有效手段。通過(guò)將數(shù)據(jù)水平切分到多個(gè)數(shù)據(jù)庫(kù)實(shí)例或表中，分?jǐn)倲?shù)據(jù)庫(kù)的寫入壓力，提升整體并發(fā)寫入能力，突破單機(jī)存儲(chǔ)和性能瓶頸。

總結(jié)來(lái)看，上述問(wèn)題主要?dú)w結(jié)為數(shù)據(jù)庫(kù)的寫入壓力和可用性問(wèn)題。采用數(shù)據(jù)分片策略，進(jìn)行合理的“分庫(kù)分表”設(shè)計(jì)，可以有效緩解這些問(wèn)題，提升系統(tǒng)的整體性能和可用性。

分庫(kù)分表是一個(gè)很常見的技術(shù)方案，你應(yīng)該有所了解。那你會(huì)說(shuō)了：“既然這個(gè)技術(shù)很普遍，而我又有所了解，那你為什么還要提及這個(gè)話題呢？”因?yàn)橐晕疫^(guò)往的經(jīng)驗(yàn)來(lái)看，不少人會(huì)在“分庫(kù)分表”這里踩坑，主要體現(xiàn)在：1. 對(duì)如何使用正確的分庫(kù)分表方式一知半解，沒(méi)有明白使用場(chǎng)景和方法。比如，一些同學(xué)會(huì)在查詢時(shí)不使用分區(qū)鍵；2. 分庫(kù)分表引入了一些問(wèn)題后，沒(méi)有找到合適的解決方案。比如，會(huì)在查詢時(shí)使用大量連表查詢等等。

如何對(duì)數(shù)據(jù)庫(kù)做垂直拆分

分庫(kù)分表是一種常見的數(shù)據(jù)分片方式，其核心思想是通過(guò)一定策略將數(shù)據(jù)盡可能均勻地分布在多個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)或表中。這種方式不同于主從復(fù)制，后者將數(shù)據(jù)全量復(fù)制到多個(gè)節(jié)點(diǎn)，而分庫(kù)分表則是讓每個(gè)節(jié)點(diǎn)只保存部分?jǐn)?shù)據(jù)，從而有效減少了單個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)和表中的數(shù)據(jù)量。這不僅解決了存儲(chǔ)瓶頸問(wèn)題，還大幅提升了數(shù)據(jù)查詢性能。

此外，數(shù)據(jù)被分散到多個(gè)節(jié)點(diǎn)后，寫入請(qǐng)求也不再集中在單一主庫(kù)，而是分散到多個(gè)數(shù)據(jù)分片節(jié)點(diǎn)上，增強(qiáng)了并發(fā)寫入的能力。比如，在我曾負(fù)責(zé)的一個(gè)直播項(xiàng)目中，我們需要存儲(chǔ)用戶和系統(tǒng)在直播間的消息。熱門直播間的留言量常常上萬(wàn)，長(zhǎng)期積累下來(lái)，數(shù)據(jù)量達(dá)到了數(shù)億級(jí)別，查詢性能和存儲(chǔ)空間都難以承受。為此，我們不得不重構(gòu)系統(tǒng)，通過(guò)分庫(kù)分表來(lái)分?jǐn)倢懭牒痛鎯?chǔ)壓力。項(xiàng)目中我們啟動(dòng)了多個(gè)數(shù)據(jù)庫(kù)并完成了單庫(kù)數(shù)據(jù)的遷移和分片校驗(yàn)，這項(xiàng)工作雖然耗時(shí)費(fèi)力，但最終成功地提升了系統(tǒng)的穩(wěn)定性和效率。

數(shù)據(jù)庫(kù)分庫(kù)分表的方式主要有兩種：垂直拆分和水平拆分。掌握拆分方式的應(yīng)用場(chǎng)景是關(guān)鍵，而理解其原理是掌握數(shù)據(jù)分片的核心。在學(xué)習(xí)時(shí)，最好結(jié)合自身的業(yè)務(wù)需求，思考如何更有效地進(jìn)行拆分。

垂直拆分

垂直拆分，顧名思義，是將數(shù)據(jù)庫(kù)“豎著”拆分，即按照業(yè)務(wù)類型將表分配到不同的數(shù)據(jù)庫(kù)中。其核心理念是專庫(kù)專用，將耦合度較高的表放在同一個(gè)庫(kù)中。可以把垂直拆分類比為整理衣物：把羽絨服、毛衣、T恤分別放入不同的格子中。這種方式能夠有效解決數(shù)據(jù)層面的故障隔離問(wèn)題。例如，當(dāng)某一模塊的數(shù)據(jù)庫(kù)發(fā)生故障時(shí)，影響的僅是該模塊的功能，而不會(huì)波及其他模塊的功能。

我還是以微博系統(tǒng)為例來(lái)給你說(shuō)明一下。

在微博系統(tǒng)中有和用戶相關(guān)的表，有和內(nèi)容相關(guān)的表，有和關(guān)系相關(guān)的表，這些表都存儲(chǔ)在主庫(kù)中。在拆分后，我們期望用戶相關(guān)的表分拆到用戶庫(kù)中，內(nèi)容相關(guān)的表分拆到內(nèi)容庫(kù)中，關(guān)系相關(guān)的表分拆到關(guān)系庫(kù)中。

圖片

對(duì)數(shù)據(jù)庫(kù)進(jìn)行垂直拆分是一種較為常規(guī)的處理方式，且在實(shí)際業(yè)務(wù)中較為常見。垂直拆分后，雖然能暫時(shí)緩解數(shù)據(jù)庫(kù)在存儲(chǔ)容量上的瓶頸，但這并不意味著問(wèn)題完全解決。垂直拆分只能在一定程度上減少存儲(chǔ)壓力，但它并不能應(yīng)對(duì)單個(gè)業(yè)務(wù)模塊數(shù)據(jù)量劇增的情況。

當(dāng)某一業(yè)務(wù)庫(kù)數(shù)據(jù)量暴增時(shí)，比如在微博系統(tǒng)中，用戶關(guān)系數(shù)據(jù)已達(dá)到千億級(jí)別，單個(gè)數(shù)據(jù)庫(kù)或數(shù)據(jù)表遠(yuǎn)遠(yuǎn)無(wú)法滿足存儲(chǔ)和查詢需求。這時(shí)，僅僅依賴垂直拆分是不夠的，你還需要進(jìn)一步將數(shù)據(jù)拆分到多個(gè)數(shù)據(jù)庫(kù)和數(shù)據(jù)表中。這種方法就是水平拆分，用來(lái)應(yīng)對(duì)單表或單庫(kù)內(nèi)數(shù)據(jù)量過(guò)大的問(wèn)題。

水平拆分可以有效地將數(shù)據(jù)分布在多個(gè)數(shù)據(jù)庫(kù)和表中，從而進(jìn)一步提升系統(tǒng)的擴(kuò)展性和查詢性能。

如何對(duì)數(shù)據(jù)庫(kù)做水平拆分

拆分的規(guī)則有下面這兩種：

一種常見的水平拆分方法是基于某個(gè)字段的哈希值進(jìn)行分片，這種方法尤其適用于實(shí)體表，如用戶表、內(nèi)容表等。通常，我們會(huì)選擇這些表的 ID 字段作為拆分依據(jù)。

例如，假設(shè)需要將用戶表拆分為 16 個(gè)庫(kù)，每個(gè)庫(kù)下有 64 張表。具體步驟如下：

• 計(jì)算哈希值：先對(duì)用戶 ID 進(jìn)行哈希處理，將 ID 值盡量打散以便均勻分布。
• 確定分庫(kù)索引：將哈希值對(duì) 16 取余，得到分庫(kù)的索引值。
• 確定分表索引：再將哈希值對(duì) 64 取余，得出分表的索引值。

通過(guò)這種方式，數(shù)據(jù)被均勻地分配到多個(gè)庫(kù)和表中，從而減輕了單一庫(kù)和表的存儲(chǔ)與查詢壓力

另一種常用的水平拆分方式是基于某個(gè)字段的區(qū)間進(jìn)行拆分，通常選擇時(shí)間字段來(lái)劃分。例如，在內(nèi)容表中有“創(chuàng)建時(shí)間”字段，我們常常需要根據(jù)時(shí)間查看某人發(fā)布的內(nèi)容，可能是昨天的內(nèi)容，也可能是一個(gè)月前的內(nèi)容。

在這種場(chǎng)景下，可以按照創(chuàng)建時(shí)間的區(qū)間進(jìn)行分庫(kù)分表。例如，將一個(gè)月的數(shù)據(jù)放在一張表中，這樣在查詢時(shí)，可以先根據(jù)創(chuàng)建時(shí)間快速定位數(shù)據(jù)所在的表，然后再根據(jù)其他查詢條件獲取數(shù)據(jù)。這種方式特別適合列表型數(shù)據(jù)的存儲(chǔ)，比如用戶在一段時(shí)間內(nèi)的訂單或發(fā)布的內(nèi)容。

不過(guò)，這種區(qū)間劃分方法也有可能導(dǎo)致熱點(diǎn)問(wèn)題。因?yàn)橛脩敉ǔ?huì)更關(guān)注近期的內(nèi)容或訂單，因此查詢最新數(shù)據(jù)的請(qǐng)求會(huì)更多，從而對(duì)系統(tǒng)性能造成一定壓力。

此外，這種方式還要求提前創(chuàng)建好數(shù)據(jù)表。否則，如果到了2020年元旦，數(shù)據(jù)庫(kù)管理員（DBA）忘記建立新的表，就會(huì)導(dǎo)致2020年數(shù)據(jù)無(wú)表可寫，進(jìn)而引發(fā)故障。因此，做好表的提前規(guī)劃和維護(hù)非常重要。

圖片

數(shù)據(jù)庫(kù)在分庫(kù)分表之后，數(shù)據(jù)的訪問(wèn)方式也有了極大的改變，原先只需要根據(jù)查詢條件到從庫(kù)中查詢數(shù)據(jù)即可，現(xiàn)在則需要先確認(rèn)數(shù)據(jù)在哪一個(gè)庫(kù)表中，再到那個(gè)庫(kù)表中查詢數(shù)據(jù)。這種復(fù)雜度也可以通過(guò)數(shù)據(jù)庫(kù)中間件來(lái)解決，我們?cè)?8 講中已經(jīng)有所講解，這里就不再贅述了，不過(guò)，我想再次強(qiáng)調(diào)的是，你需要對(duì)所使用數(shù)據(jù)庫(kù)中間件的原理有足夠的了解，和足夠強(qiáng)的運(yùn)維上的把控能力。不過(guò)，你要知道的是，分庫(kù)分表雖然能夠解決數(shù)據(jù)庫(kù)擴(kuò)展性的問(wèn)題，但是它也給我們的使用帶來(lái)了一些問(wèn)題。

解決分庫(kù)分表引入的問(wèn)題

分庫(kù)分表帶來(lái)的一個(gè)主要問(wèn)題是分庫(kù)分表鍵（也稱為分區(qū)鍵）的引入，即對(duì)數(shù)據(jù)庫(kù)進(jìn)行分庫(kù)分表時(shí)所依據(jù)的字段。無(wú)論是通過(guò)哈希分片還是區(qū)間分片，首先都需要選擇一個(gè)字段作為分區(qū)鍵。然而，這也帶來(lái)了一個(gè)限制：之后的所有查詢都必須包含該分區(qū)鍵才能找到數(shù)據(jù)所在的庫(kù)和表。否則，查詢將不得不遍歷所有庫(kù)和表。

例如，如果我們將數(shù)據(jù)拆分成 16 個(gè)庫(kù)，每個(gè)庫(kù)包含 64 張表，那么一次查詢可能會(huì)擴(kuò)展為 16 × 64 = 1024 次查詢，導(dǎo)致查詢性能急劇下降。

當(dāng)然，對(duì)于這個(gè)問(wèn)題，也有一些解決方法。比如，在用戶庫(kù)中可以使用 ID 作為分區(qū)鍵，但如果之后需要按昵稱查詢用戶，理論上可以再按昵稱做一次拆分。然而，這會(huì)大幅增加存儲(chǔ)成本。如果以后還需要按注冊(cè)時(shí)間查詢，是否要繼續(xù)進(jìn)行新的拆分呢？這種方法顯然不具備長(zhǎng)遠(yuǎn)性，因此需要更加靈活的解決思路。

因此，較為合適的解決方案是建立一個(gè)昵稱和 ID 的映射表。在查詢時(shí)，可以先通過(guò)昵稱查找到對(duì)應(yīng)的 ID，再利用 ID 獲取完整的數(shù)據(jù)。這個(gè)映射表同樣可以采用分庫(kù)分表策略，雖然需要一定的存儲(chǔ)空間，但由于表中僅包含昵稱和 ID 兩個(gè)字段，所需空間相比重新拆分主表要少得多。

分庫(kù)分表引入的另一個(gè)問(wèn)題是某些數(shù)據(jù)庫(kù)特性的實(shí)現(xiàn)可能變得更加復(fù)雜。例如，多表的 JOIN 操作在單庫(kù)情況下可以通過(guò)一條 SQL 語(yǔ)句完成，但拆分到多個(gè)數(shù)據(jù)庫(kù)后，無(wú)法跨庫(kù)執(zhí)行 JOIN。不過(guò)好在我們對(duì) JOIN 的需求并不高，即使有，也通常是將兩個(gè)表的數(shù)據(jù)提取到業(yè)務(wù)代碼中，再進(jìn)行數(shù)據(jù)篩選，盡管實(shí)現(xiàn)稍顯復(fù)雜，但仍然可行。

另外，在未進(jìn)行分庫(kù)分表之前，獲取數(shù)據(jù)總數(shù)只需在 SQL 中執(zhí)行 count() 即可；而數(shù)據(jù)分散到多個(gè)庫(kù)表中后，就需要其他方案來(lái)實(shí)現(xiàn)。例如，可以將計(jì)數(shù)數(shù)據(jù)單獨(dú)存儲(chǔ)在一張表中，或?qū)⑵溆涗浀?Redis 中。

盡管分庫(kù)分表會(huì)帶來(lái)一定的操作復(fù)雜性，但相比它對(duì)系統(tǒng)擴(kuò)展性和性能的提升，依然值得實(shí)施。經(jīng)過(guò)分庫(kù)分表的系統(tǒng)，能夠突破單機(jī)的容量和請(qǐng)求量瓶頸。正如我們電商系統(tǒng)中的訂單表，正是通過(guò)分庫(kù)分表，才解決了因數(shù)據(jù)量激增導(dǎo)致的性能衰減和存儲(chǔ)容量瓶頸。

所以，從我的經(jīng)驗(yàn)出發(fā)，對(duì)于分庫(kù)分表的原則主要有以下幾點(diǎn)：

在考慮分庫(kù)分表時(shí)，首先要遵循一個(gè)原則：如果系統(tǒng)在性能上還沒(méi)有遇到瓶頸，那么盡量不要實(shí)施分庫(kù)分表。

如果確實(shí)需要分庫(kù)分表，那么應(yīng)盡量一次到位，比如選擇 16 個(gè)庫(kù)、每個(gè)庫(kù)包含 64 張表，這樣的方案基本可以滿足未來(lái)幾年內(nèi)的業(yè)務(wù)需求，避免頻繁調(diào)整帶來(lái)的復(fù)雜性。

另外，許多 NoSQL 數(shù)據(jù)庫(kù)（如 HBase、MongoDB）提供了自動(dòng)分片（auto-sharding）功能。如果團(tuán)隊(duì)對(duì)這些組件有較強(qiáng)的熟悉度和運(yùn)維能力，可以考慮使用這些 NoSQL 數(shù)據(jù)庫(kù)來(lái)替代傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)，從而更高效地管理大規(guī)模數(shù)據(jù)。

在我看來(lái)，許多人并沒(méi)有真正理解拆分的必要性及其潛在影響，只是盲目跟隨大廠的拆分方法，導(dǎo)致問(wèn)題頻出。因此，在使用某個(gè)方案解決問(wèn)題時(shí)，務(wù)必要弄清原理，了解方案可能帶來(lái)的問(wèn)題，并提前考慮應(yīng)對(duì)之道。做到知其然并知其所以然，才能在解決問(wèn)題的同時(shí)避免踩坑。