狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

本講將要介紹如何存儲(chǔ)這些海量數(shù)據(jù)，同時(shí)保證相對(duì)應(yīng)的寫(xiě)入和查詢的性能，以及業(yè)務(wù)流程不發(fā)生太大變化。

不管是打車的訂單、電商里的支付訂單，還是外賣(mài)或團(tuán)購(gòu)的支付訂單，都是后臺(tái)服務(wù)中最重要的一環(huán)，關(guān)乎公司的營(yíng)收。因此，本講及本模塊都將以 訂單業(yè)務(wù) 作為案例進(jìn)行分析。

是否真的要分庫(kù)？

分庫(kù)當(dāng)然能夠解決存儲(chǔ)的問(wèn)題，假設(shè)原先單庫(kù)只能最多存儲(chǔ) 2 千萬(wàn)的數(shù)據(jù)量。采用分庫(kù)之后，存儲(chǔ)架構(gòu)變成下圖 1 所示的分庫(kù)架構(gòu)，每個(gè)分庫(kù)都可以存儲(chǔ) 2 千萬(wàn)數(shù)據(jù)量，容量的上限一下提升了。

容量提升了，但也帶來(lái)了很多其他問(wèn)題。比如：

1. 1. 分庫(kù)數(shù)據(jù)間的數(shù)據(jù)無(wú)法再通過(guò)數(shù)據(jù)庫(kù)直接查詢了。比如跨多個(gè)分庫(kù)的數(shù)據(jù)需要多次查詢或借助其他存儲(chǔ)進(jìn)行聚合再查詢。

2. 2. 分庫(kù)越多，出現(xiàn)問(wèn)題的可能性越大，維護(hù)成本也變得更高。

3. 3. 無(wú)法保障跨庫(kù)間事務(wù)，只能借助其他中間件實(shí)現(xiàn)最終一致性。

所以在解決容量問(wèn)題上，可以根據(jù)業(yè)務(wù)場(chǎng)景選擇，不要一上來(lái)就要考慮分庫(kù)，分表也是一種選擇。

分表是指所有的數(shù)據(jù)均存在同一個(gè)數(shù)據(jù)庫(kù)實(shí)例中，只是將原先的一張大表按一定規(guī)則，劃分成多張行數(shù)較少的表。它與分庫(kù)的區(qū)別是，分表后的子表仍在原有庫(kù)中，而分庫(kù)則是子表移動(dòng)到新的數(shù)據(jù)庫(kù)實(shí)例里并在物理上單獨(dú)部署。分表的拆分架構(gòu)如下圖 2 所示：

以本模塊的訂單案例來(lái)說(shuō)，假設(shè)訂單只是 單量多而每一單的數(shù)據(jù)量較小，這就適合采用分表。單條數(shù)據(jù)量小但行數(shù)多，會(huì)導(dǎo)致寫(xiě)入（因?yàn)橐獦?gòu)建索引）和查詢非常慢，但整體對(duì)于容量的占用是可控的。采用分表后，大表變成小表，寫(xiě)入時(shí)構(gòu)建索引的性能消耗會(huì)變小，其次小表的查詢性能也更好。如果采用了分庫(kù)，雖然解決了寫(xiě)入和查詢的問(wèn)題，但每張表所占有的磁盤(pán)空間很少，也會(huì)產(chǎn)生資源浪費(fèi)。兩種方案的對(duì)比如下圖 3 所示：

在實(shí)際場(chǎng)景里，因?yàn)橐敿?xì)記錄用戶的提單信息，單個(gè)訂單記錄的數(shù)據(jù)量均較多，所以不存在行數(shù)多但單條數(shù)據(jù)量小的情況。但在其他寫(xiě)入服務(wù)里，經(jīng)常會(huì)出現(xiàn)上述場(chǎng)景，你可以優(yōu)先采用分表的方案。因?yàn)?分表除了能解決容量問(wèn)題，還能在一定程度上解決分庫(kù)所帶來(lái)的三個(gè)問(wèn)題。

1. 1. 分表后可以通過(guò) join 等完成一些富查詢，相比分庫(kù)簡(jiǎn)單得多。

2. 2. 分表的數(shù)據(jù)仍存儲(chǔ)在一個(gè)數(shù)據(jù)庫(kù)里，不會(huì)出現(xiàn)很多分庫(kù)。無(wú)須引入一些分庫(kù)中間件，因此維護(hù)成本和開(kāi)發(fā)成本均較低。

3. 3. 因?yàn)樵谕粋€(gè)數(shù)據(jù)庫(kù)里，也可以很好地解決事務(wù)問(wèn)題。

接下來(lái)將介紹如何應(yīng)對(duì)行數(shù)多且單行數(shù)據(jù)量較大的場(chǎng)景。通過(guò)我們前面的分析，我想你已經(jīng)知道答案了——采用分庫(kù)的方案。

如何實(shí)現(xiàn)分庫(kù)？

在決定對(duì)數(shù)據(jù)庫(kù)進(jìn)行分庫(kù)后，首先要解決的問(wèn)題便是 如何選擇分庫(kù)維度。不同的分庫(kù)維度 決定了部分查詢是否能直接使用數(shù)據(jù)庫(kù)，以及是否存在數(shù)據(jù)傾斜的問(wèn)題。

分庫(kù)維度選擇

下面以訂單為案例，介紹兩種常見(jiàn)不同維度的分庫(kù)方式：按 直接滿足最重要的業(yè)務(wù)場(chǎng)景劃分和最細(xì)粒度隨機(jī)分。

首先我們來(lái)看按 直接滿足最重要的業(yè)務(wù)場(chǎng)景劃分。在業(yè)務(wù)上，所有的訂單數(shù)據(jù)都是隸屬于某一個(gè)用戶的。在選擇分庫(kù)維度時(shí)，可以按訂單歸屬的用戶 這個(gè)字段進(jìn)行分庫(kù)。按此維度分庫(kù)后，同一個(gè)用戶的訂單都在某一個(gè)分庫(kù)里。分庫(kù)后的場(chǎng)景如下圖 4 所示：

訂單模塊除了提供提交訂單接口外，還會(huì)提供給售賣(mài)商家對(duì)自己店鋪的訂單進(jìn)行查詢及修改等功能。這些維度的查詢和修改需求，在采用了按購(gòu)買(mǎi)用戶進(jìn)行分庫(kù)之后，均無(wú)法直接滿足了。

這里請(qǐng)你思考一個(gè)問(wèn)題， 訂單模塊最重要的功能是什么？

答案是保證客戶（即買(mǎi)家）的各項(xiàng)訂單功能能夠正常使用，比如下單、下單后立刻（無(wú)延遲）查看已購(gòu)的訂單信息、待支付、待發(fā)貨、待配送的訂單列表等。相對(duì)來(lái)說(shuō)，訂單里的商品售賣(mài)方（即賣(mài)家）所使用的功能并不是優(yōu)先級(jí)最高的。因?yàn)楫?dāng)我們要對(duì)賣(mài)家和買(mǎi)家的功能做取舍時(shí)，賣(mài)家是愿意降低優(yōu)先級(jí)的，畢竟賣(mài)家是買(mǎi)賣(mài)的受益方。

按購(gòu)買(mǎi)用戶劃分后，用戶的使用場(chǎng)景都可以直接通過(guò)分庫(kù)支持，而不需要通過(guò)異構(gòu)數(shù)據(jù)（存在數(shù)據(jù)延遲）等手段解決，對(duì)用戶來(lái)說(shuō)體驗(yàn)較好。其次，在同一個(gè)分庫(kù)中，便于修改同一用戶的多條數(shù)據(jù)，因此也不存在分布式事務(wù)問(wèn)題。

我們可以通過(guò)上述訂單案例抽象出一個(gè)分庫(kù)準(zhǔn)則，即 在確定分庫(kù)字段時(shí)應(yīng)該以直接滿足最重要的業(yè)務(wù)場(chǎng)景為準(zhǔn)。很多其他的業(yè)務(wù)都參考了這一準(zhǔn)則，比如：

1. 1. 對(duì)于微博和知乎等用戶生產(chǎn)內(nèi)容（UGC）的業(yè)務(wù)，均會(huì)按用戶進(jìn)行分庫(kù)。因?yàn)橛脩粜掳l(fā)布文章后就會(huì)去查看列表。

2. 2. 支付系統(tǒng)里，也會(huì)按用戶的支付記錄進(jìn)行分庫(kù)。

3. 3. 在技術(shù)上，比如一個(gè)微服務(wù)下的監(jiān)控?cái)?shù)據(jù)，同樣會(huì)按微服務(wù)進(jìn)行劃分。同一個(gè)微服務(wù)的監(jiān)控?cái)?shù)據(jù)均存儲(chǔ)在一個(gè)分庫(kù)里，你可以直接在一個(gè)分庫(kù)里查看微服務(wù)下的所有監(jiān)控?cái)?shù)據(jù)。

上述劃分方法雖然直接滿足了最重要的場(chǎng)景，但可能會(huì)出現(xiàn)數(shù)據(jù)傾斜的問(wèn)題，比如出現(xiàn)一個(gè)超級(jí)客戶（如企業(yè)客戶），購(gòu)買(mǎi)的訂單量非常大，導(dǎo)致某一個(gè)分庫(kù)數(shù)據(jù)量巨多，就會(huì)重現(xiàn)分庫(kù)前的場(chǎng)景。這屬于最極端的情況之一。

對(duì)于傾斜的問(wèn)題，可以采用 最細(xì)粒度的拆分，即按數(shù)據(jù)的唯一標(biāo)示進(jìn)行拆分，對(duì)于訂單來(lái)說(shuō)唯一標(biāo)示即為訂單號(hào)。采用訂單號(hào)進(jìn)行分庫(kù)之后，用戶的訂單會(huì)按 Hash 隨機(jī)均勻地分散到某一個(gè)分庫(kù)里。這樣就解決了某一個(gè)分庫(kù)數(shù)據(jù)不均勻的問(wèn)題。

對(duì)于上個(gè)小節(jié)里的案例，也可以用此手段進(jìn)行處理。比如：

1. 1. 按用戶的每一條微博隨機(jī)分庫(kù)；

2. 2. 按用戶的每一筆支付記錄隨機(jī)分庫(kù)；

3. 3. 同一個(gè)微服務(wù)里的每一個(gè)監(jiān)控點(diǎn)的數(shù)據(jù)隨機(jī)分庫(kù)。

采用最細(xì)粒度分庫(kù)后，雖然解決了數(shù)據(jù)均衡的問(wèn)題，但又帶來(lái)了其他問(wèn)題。

1. 1. 首先便是除了細(xì)粒度查詢外，其他任何維度的查詢均不支持。這就需要通過(guò)異構(gòu)等方式解決，但異構(gòu)有延遲、對(duì)業(yè)務(wù)是有損的。

2. 2. 其次采用最細(xì)粒度后，對(duì)于防重邏輯在數(shù)據(jù)庫(kù)層面已經(jīng)無(wú)法支持。比如用戶對(duì)同一個(gè)訂單在業(yè)務(wù)上只能支付一次這一訴求，在支付系統(tǒng)按支付號(hào)進(jìn)行分庫(kù)后便不能直接滿足了。因?yàn)樯鲜龇謳?kù)方式會(huì)導(dǎo)致不同支付單分散在不同的分庫(kù)里，此時(shí)，期望在數(shù)據(jù)庫(kù)中通過(guò)訂單號(hào)的唯一索引進(jìn)行支付防重就不可實(shí)施了。

上述兩種分庫(kù)的方式，在解決問(wèn)題的同時(shí)又帶來(lái)一些新的問(wèn)題。在架構(gòu)中，沒(méi)有一種方案可以解決所有問(wèn)題的，更多的是根據(jù)場(chǎng)景去選擇更適合自己的方案。

全局唯一標(biāo)示

不管采用何種維度的分庫(kù)方式，使用原有單庫(kù)的數(shù)據(jù)庫(kù)自增主鍵生產(chǎn)數(shù)據(jù)標(biāo)示的方案已經(jīng)不可以使用了。對(duì)于全局的數(shù)據(jù)唯一標(biāo)示，有兩種常見(jiàn)的生成方式。

1. 使用算法隨機(jī)生成。

比如使用機(jī)器 IP、時(shí)間戳、隨機(jī)數(shù)等進(jìn)行組合，生成一個(gè)唯一編號(hào)。業(yè)界成熟的有 Twitter 推出的雪花算法。需要注意的是，為了保證唯一性，雪花算法增加了很多隨機(jī)因子，導(dǎo)致計(jì)算出來(lái)的唯一標(biāo)示特別長(zhǎng)，達(dá)到 19 位。

在 JavaScript 里，數(shù)據(jù)精度和 Java 等語(yǔ)言不完全一致，太長(zhǎng)的雪花 ID 在前端存在溢出的問(wèn)題。因?yàn)檠┗ㄋ惴ㄉ傻?ID 為 Long 類型，可以采用類似 Base64 等算法，對(duì)原始 ID 進(jìn)行壓縮轉(zhuǎn)換為 String 類型，降低長(zhǎng)度并避免和 JavaScript 精度不統(tǒng)一導(dǎo)致的問(wèn)題。

2. 基于數(shù)據(jù)庫(kù)主鍵構(gòu)建一個(gè) ID 生成服務(wù)。

雖然不能在插入的時(shí)候使用數(shù)據(jù)庫(kù)唯一主鍵，但可以在插入前通過(guò)一個(gè)服務(wù)獲取全局唯一的 ID。ID 生產(chǎn)服務(wù)可以基于一張單表實(shí)現(xiàn)，每一次外部請(qǐng)求時(shí)，均生產(chǎn)一個(gè)新的 ID。通過(guò)此方式，可以獲得長(zhǎng)度較短且為數(shù)值類型的全局唯一編號(hào)。

但如果每次獲取 ID 時(shí)，ID 生成服務(wù)都需要從數(shù)據(jù)庫(kù)實(shí)時(shí)獲取，性能會(huì)比較差。為了解決性能問(wèn)題，可以在生成 ID 的數(shù)據(jù)庫(kù)前置一個(gè)具備持久化功能的內(nèi)存緩存，預(yù)生成一批 ID。具體架構(gòu)如下圖 5 所示：

分庫(kù)中間件選擇

現(xiàn)在開(kāi)源提供分庫(kù)支持的中間件較多，如 MyCat 等， 整體上各類分庫(kù)中間件可以分為兩大類：一種是代理式、另外一種是內(nèi)嵌式。

代理式分庫(kù)中間件 對(duì)于業(yè)務(wù)應(yīng)用無(wú)任何侵入，業(yè)務(wù)應(yīng)用和未分庫(kù)時(shí)一樣使用數(shù)據(jù)庫(kù)，分庫(kù)的選擇及分庫(kù)的維度對(duì)業(yè)務(wù)層完全隱藏，接入和使用成本極低。代理式的架構(gòu)如下圖 6 所示：

代理式雖有使用成本低的好處，但也存在其他一些問(wèn)題。

1. 1. 代理式在業(yè)務(wù)應(yīng)用和數(shù)據(jù)庫(kù)間增加了一層，導(dǎo)致了性能下降。

2. 2. 代理式需要解析業(yè)務(wù)應(yīng)用的 SQL，并根據(jù) SQL 中的分庫(kù)字段進(jìn)行路由。它需要解析和適配所有 SQL 語(yǔ)法，增加了代理模塊復(fù)雜度和出錯(cuò)的可能性。

3. 3. 代理層是單獨(dú)進(jìn)程，需要部署占用資源，帶來(lái)一定的成本。

內(nèi)嵌式分庫(kù)中間件 是將分庫(kù)中間件內(nèi)置在業(yè)務(wù)應(yīng)用中，它只負(fù)責(zé)分庫(kù)的選擇，并不會(huì)解析用戶的 SQL。在使用時(shí)，業(yè)務(wù)應(yīng)用需將分庫(kù)字段傳遞給內(nèi)嵌中間件去計(jì)算具體對(duì)應(yīng)的分庫(kù)。它相比代理式性能更好。內(nèi)嵌式的架構(gòu)如下圖 7 所示：

除了性能優(yōu)勢(shì)外，內(nèi)嵌式同樣存在問(wèn)題。

1. 1. 有一定侵入性，業(yè)務(wù)應(yīng)用與原始單庫(kù)模式相比，需要進(jìn)行一定的改造去適配內(nèi)嵌式的 API。

2. 2. 分庫(kù)在故障轉(zhuǎn)移、數(shù)據(jù)遷移等運(yùn)維工作時(shí)，需要業(yè)務(wù)應(yīng)用感知。不過(guò)現(xiàn)在的一些內(nèi)嵌式代理，已經(jīng)具備非常良好的配置功能，在分庫(kù)運(yùn)維時(shí)，業(yè)務(wù)應(yīng)用需要配合的內(nèi)容較少。

其他問(wèn)題

接下來(lái)，再來(lái)看幾個(gè)常見(jiàn)問(wèn)題的應(yīng)對(duì)策略。

1. 是否一定需要進(jìn)行分表或者分庫(kù)呢？

不一定。雖然很多互聯(lián)網(wǎng)公司的體量很大，用戶非常多，但你千萬(wàn)不要被這些現(xiàn)象迷惑了。實(shí)際上，90% 以上的系統(tǒng)能夠發(fā)展到上百萬(wàn)、上千萬(wàn)數(shù)據(jù)量已經(jīng)很不錯(cuò)了。對(duì)于千萬(wàn)的數(shù)據(jù)量，開(kāi)源的 MySQL 都可以很好地應(yīng)對(duì)，更別說(shuō)一些商業(yè)數(shù)據(jù)庫(kù)了。

另外，當(dāng)數(shù)據(jù)增長(zhǎng)到一定量級(jí)后，可以在業(yè)務(wù)層面做一些處理。比如根據(jù)業(yè)務(wù)特點(diǎn)，對(duì)無(wú)效數(shù)據(jù)、軟刪除數(shù)據(jù)，以及業(yè)務(wù)上不會(huì)再查詢的數(shù)據(jù)進(jìn)行統(tǒng)一歸檔，這也是一個(gè)成本低、效果明顯的方式了。

2. 使用業(yè)務(wù)字段分庫(kù)后，如何處理數(shù)據(jù)傾斜？

如果數(shù)據(jù)量不是特別大，可以在分庫(kù)基礎(chǔ)上，再進(jìn)行分表。針對(duì)數(shù)據(jù)量較大的場(chǎng)景，可以使用二次分庫(kù)的方式。對(duì)于訂單量較多的用戶，可以在用戶賬號(hào)基礎(chǔ)上再增加一個(gè)字段，做進(jìn)一步的分庫(kù)，但此用戶的查詢就會(huì)有損了。

此外，還有另外兩個(gè)問(wèn)題，由于需要用到暫未講解的知識(shí)，所以我將放在后面的章節(jié)結(jié)合相關(guān)知識(shí)詳細(xì)講解，今天僅做提及。

3. 如何滿足富查詢？

富查詢是一個(gè)無(wú)法回避的問(wèn)題，即采用分庫(kù)分表之后，如何滿足跨越分庫(kù)的查詢？對(duì)于此問(wèn)題，我將在“ 第 11 講”進(jìn)行詳細(xì)講解。

4. 如何解決跨多庫(kù)的修改導(dǎo)致的分布式事務(wù)？

跨多庫(kù)的修改及多個(gè)微服務(wù)間的寫(xiě)操作導(dǎo)致的分布式事務(wù)問(wèn)題，我將在“ 第 19 講”里集中講解。

總結(jié)

不斷進(jìn)行分庫(kù)分表一定能解決容量問(wèn)題，但“殺敵一千，自損八百”的事情少做為宜。使用分庫(kù)分表會(huì)將代碼和架構(gòu)的復(fù)雜度變高，帶來(lái)資源成本上升等問(wèn)題。另外，在使用系統(tǒng)時(shí)，用戶（不管是客戶還是管理員）的查詢體驗(yàn)也存在一定的降級(jí)。

在使用分庫(kù)分表前，你需要確定這是否是最優(yōu)選擇，是否能通過(guò)其他更簡(jiǎn)單的手段處理無(wú)效數(shù)據(jù)清理？架構(gòu)是通過(guò)最小代價(jià)解決問(wèn)題，而不是技術(shù)工具的比拼。

最后，我再給你留一道討論題，你知道的分庫(kù)分表的問(wèn)題還有哪些或者上述問(wèn)題你還有哪些解決方案？