原大眾點評的訂單單表早就已經(jīng)突破兩百G，由于查詢維度較多，即使加了兩個從庫，優(yōu)化索引，仍然存在很多查詢不理想的情況。去年大量搶購活動的開展，使數(shù)據(jù)庫達到瓶頸，應(yīng)用只能通過限速、異步隊列等對其進行保護；業(yè)務(wù)需求層出不窮，原有的訂單模型很難滿足業(yè)務(wù)需求，但是基于原訂單表的DDL又非常吃力，無法達到業(yè)務(wù)要求。隨著這些問題越來越突出，訂單數(shù)據(jù)庫的切分就愈發(fā)急迫了。

這次切分，我們的目標(biāo)是未來十年內(nèi)不需要擔(dān)心訂單容量的問題。

先對訂單庫進行垂直切分，將原有的訂單庫分為基礎(chǔ)訂單庫、訂單流程庫等，本文就不展開講了。

垂直切分緩解了原來單集群的壓力，但是在搶購時依然捉襟見肘。原有的訂單模型已經(jīng)無法滿足業(yè)務(wù)需求，于是我們設(shè)計了一套新的統(tǒng)一訂單模型，為同時滿足C端用戶、B端商戶、客服、運營等的需求，我們分別通過用戶ID和商戶ID進行切分，并通過PUMA（我們內(nèi)部開發(fā)的MySQL binlog實時解析服務(wù)）同步到一個運營庫。

切分策略

1. 查詢切分

將ID和庫的Mapping關(guān)系記錄在一個單獨的庫中。

優(yōu)點：ID和庫的Mapping算法可以隨意更改。
缺點：引入額外的單點。

2. 范圍切分

比如按照時間區(qū)間或ID區(qū)間來切分。

優(yōu)點：單表大小可控，天然水平擴展。
缺點：無法解決集中寫入瓶頸的問題。

3. Hash切分

一般采用Mod來切分，下面著重講一下Mod的策略。

數(shù)據(jù)水平切分后我們希望是一勞永逸或者是易于水平擴展的，所以推薦采用mod 2^n這種一致性Hash。

以統(tǒng)一訂單庫為例，我們分庫分表的方案是32*32的，即通過UserId后四位mod 32分到32個庫中，同時再將UserId后四位Div 32 Mod 32將每個庫分為32個表，共計分為1024張表。線上部署情況為8個集群(主從)，每個集群4個庫。

為什么說這種方式是易于水平擴展的呢？我們分析如下兩個場景。

場景一：數(shù)據(jù)庫性能達到瓶頸

方法一

按照現(xiàn)有規(guī)則不變，可以直接擴展到32個數(shù)據(jù)庫集群。

方法二

如果32個集群也無法滿足需求，那么將分庫分表規(guī)則調(diào)整為(32*2^n)*(³²?₂^n)，可以達到最多1024個集群。

場景二：單表容量達到瓶頸（或者1024已經(jīng)無法滿足你）

方法：

假如單表都已突破200G，200*1024=200T（按照現(xiàn)有的訂單模型算了算，大概一萬千億訂單，相信這一天，嗯，指日可待！），沒關(guān)系，32*(32*2^n)，這時分庫規(guī)則不變，單庫里的表再進行裂變，當(dāng)然，在目前訂單這種規(guī)則下（用userId后四位 mod）還是有極限的，因為只有四位，所以最多拆8192個表，至于為什么只取后四位，后面會有篇幅講到。

另外一個維度是通過ShopID進行切分，規(guī)則8*8和UserID比較類似，就不再贅述，需要注意的是Shop庫我們僅存儲了訂單主表，用來滿足Shop維度的查詢。

唯一ID方案

這個方案也很多，主流的有那么幾種:

1. 利用數(shù)據(jù)庫自增ID

優(yōu)點：最簡單。 缺點：單點風(fēng)險、單機性能瓶頸。

2. 利用數(shù)據(jù)庫集群并設(shè)置相應(yīng)的步長（Flickr方案）

優(yōu)點：高可用、ID較簡潔。 缺點：需要單獨的數(shù)據(jù)庫集群。

3. Twitter Snowflake

優(yōu)點：高性能高可用、易拓展。 缺點：需要獨立的集群以及ZK。

4. 一大波GUID、Random算法

優(yōu)點：簡單。 缺點：生成ID較長，有重復(fù)幾率。

我們的方案

為了減少運營成本并減少額外的風(fēng)險我們排除了所有需要獨立集群的方案，采用了帶有業(yè)務(wù)屬性的方案： > 時間戳+用戶標(biāo)識碼+隨機數(shù)

有下面幾個好處：

• 方便、成本低。
• 基本無重復(fù)的可能。
• 自帶分庫規(guī)則，這里的用戶標(biāo)識碼即為用戶ID的后四位，在查詢的場景下，只需要訂單號就可以匹配到相應(yīng)的庫表而無需用戶ID，只取四位是希望訂單號盡可能的短一些，并且評估下來四位已經(jīng)足夠。
• 可排序，因為時間戳在最前面。
  

當(dāng)然也有一些缺點，比如長度稍長，性能要比int/bigint的稍差等。

其他問題

• 事務(wù)支持：我們是將整個訂單領(lǐng)域聚合體切分，維度一致，所以對聚合體的事務(wù)是支持的。
• 復(fù)雜查詢：垂直切分后，就跟join說拜拜了；水平切分后，查詢的條件一定要在切分的維度內(nèi)，比如查詢具體某個用戶下的各位訂單等；禁止不帶切分的維度的查詢，即使中間件可以支持這種查詢，可以在內(nèi)存中組裝，但是這種需求往往不應(yīng)該在在線庫查詢，或者可以通過其他方法轉(zhuǎn)換到切分的維度來實現(xiàn)。

數(shù)據(jù)遷移

數(shù)據(jù)庫拆分一般是業(yè)務(wù)發(fā)展到一定規(guī)模后的優(yōu)化和重構(gòu)，為了支持業(yè)務(wù)快速上線，很難一開始就分庫分表，垂直拆分還好辦，改改數(shù)據(jù)源就搞定了，一旦開始水平拆分，數(shù)據(jù)清洗就是個大問題，為此，我們經(jīng)歷了以下幾個階段。

第一階段

• 數(shù)據(jù)庫雙寫（事務(wù)成功以老模型為準(zhǔn)），查詢走老模型。
• 每日job數(shù)據(jù)對賬（通過DW），并將差異補平。
• 通過job導(dǎo)歷史數(shù)據(jù)。

第二階段

• 歷史數(shù)據(jù)導(dǎo)入完畢并且數(shù)據(jù)對賬無誤。
• 依然是數(shù)據(jù)庫雙寫，但是事務(wù)成功與否以新模型為準(zhǔn)，在線查詢切新模型。
• 每日job數(shù)據(jù)對賬，將差異補平。

第三階段

• 老模型不再同步寫入，僅當(dāng)訂單有終態(tài)時才會異步補上。
• 此階段只有離線數(shù)據(jù)依然依賴?yán)系哪Ｐ?#xff0c;并且下游的依賴非常多，待DW改造完就可以完全廢除老模型了。

總結(jié)

并非所有表都需要水平拆分，要看增長的類型和速度，水平拆分是大招，拆分后會增加開發(fā)的復(fù)雜度，不到萬不得已不使用。

在大規(guī)模并發(fā)的業(yè)務(wù)上，盡量做到在線查詢和離線查詢隔離，交易查詢和運營/客服查詢隔離。

拆分維度的選擇很重要，要盡可能在解決拆分前問題的基礎(chǔ)上，便于開發(fā)。

數(shù)據(jù)庫沒你想象的那么堅強，需要保護，盡量使用簡單的、良好索引的查詢，這樣數(shù)據(jù)庫整體可控，也易于長期容量規(guī)劃以及水平擴展。

最后感謝一下棒棒的DBA團隊和數(shù)據(jù)庫中間件團隊對項目的大力協(xié)助！

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的大众点评订单系统分库分表实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。