背景

之前看過(guò)公司的商城系統(tǒng)，當(dāng)時(shí)遇到一個(gè)問(wèn)題，就是我拿到一個(gè)訂單號(hào)，我竟然不知道怎么去查到這個(gè)訂單號(hào)的詳細(xì)信息，尷尬了。后來(lái)問(wèn)了商城那邊的同事，才知道，公司對(duì)訂單系統(tǒng)中的表做了分表操作。下面來(lái)聊聊。

分庫(kù)分表的作用

只分庫(kù)不分表

當(dāng)數(shù)據(jù)庫(kù)的讀或者寫的QPS過(guò)高導(dǎo)致數(shù)據(jù)庫(kù)的連接不足了這時(shí)候就需要考慮做分庫(kù)了。通過(guò)增加數(shù)據(jù)庫(kù)實(shí)例的方式，提高系統(tǒng)的并發(fā)度

分布式系統(tǒng)，每個(gè)系統(tǒng)都有自己一個(gè)獨(dú)立的庫(kù)，其實(shí)這是一種 垂直分庫(kù) 。將業(yè)務(wù)雜糅的表，解耦成獨(dú)立業(yè)務(wù)的表，放在不同的數(shù)據(jù)庫(kù)中，從而解決分布式系統(tǒng)訪問(wèn)壓力，原來(lái)十個(gè)系統(tǒng)都要訪問(wèn)一個(gè)數(shù)據(jù)庫(kù)，現(xiàn)在十個(gè)系統(tǒng)訪問(wèn)不同的十個(gè)庫(kù)。

讀寫分離，數(shù)據(jù)庫(kù)做主從數(shù)據(jù)庫(kù)的時(shí)候，主庫(kù)用來(lái)寫數(shù)據(jù)，從庫(kù)用來(lái)讀數(shù)據(jù)，從庫(kù)同步主庫(kù)的數(shù)據(jù)，用主庫(kù)的binlog日志來(lái)同步數(shù)據(jù)變更。這是一種 水平分庫(kù) 的方式。主庫(kù)和從庫(kù)的表結(jié)構(gòu)一致，數(shù)據(jù)也一致，僅僅是為了解決數(shù)據(jù)庫(kù)讀多寫少的場(chǎng)景。

只分表不分庫(kù)

當(dāng)數(shù)據(jù)庫(kù)的單表數(shù)據(jù)量特別的大的時(shí)候，因?yàn)椴l(fā)不高，數(shù)據(jù)庫(kù)的連接夠用，但是存儲(chǔ)查詢的性能會(huì)特別的低，這個(gè)時(shí)候就需要做分表了，將數(shù)據(jù)拆分到多張表中，提高讀寫的性能

大表（字段多）拆成多個(gè)小表（字段少），這就是一種 垂直分表 。

訂單表的分表，這其實(shí)就是一種 水平分表 。因?yàn)橛唵伪黼S著時(shí)間的積累，數(shù)據(jù)會(huì)越來(lái)越多，到那時(shí)候一個(gè)訂單表的查詢和寫入會(huì)變得特別的慢。例如現(xiàn)在訂單表有200億條數(shù)據(jù)，但是水平分表成1024張表，每張表大概只有2000萬(wàn)條數(shù)據(jù)，這個(gè)時(shí)候的查詢與寫入操作效率還是很好的。

既分庫(kù)也分表

兩種情況都產(chǎn)生的時(shí)候：

當(dāng)數(shù)據(jù)庫(kù)的讀或者寫的QPS過(guò)高導(dǎo)致數(shù)據(jù)庫(kù)的連接不足了這時(shí)候就需要考慮做分庫(kù)了。通過(guò)增加數(shù)據(jù)庫(kù)實(shí)例的方式，提高系統(tǒng)的并發(fā)度

當(dāng)數(shù)據(jù)庫(kù)的單表數(shù)據(jù)量特別的大的時(shí)候，因?yàn)椴l(fā)不高，數(shù)據(jù)庫(kù)的連接夠用，但是存儲(chǔ)查詢的性能會(huì)特別的低，這個(gè)時(shí)候就需要做分表了，將數(shù)據(jù)拆分到多張表中，提高讀寫的性能

訂單表的分庫(kù)分表如何做呢？

訂單表分表思路

分庫(kù)這里不闡述，公司只做了分表，沒有做分庫(kù)。其實(shí)效果是一樣的
公司主要是用用戶的UID作為分表的依據(jù)。將用戶的UID對(duì)1024取模，算出對(duì)應(yīng)的下標(biāo)，然后將該用戶的訂單存入對(duì)應(yīng)的分表中，主表也會(huì)異步寫入一份。

訂單表.png

       訂單號(hào)：  全局唯一ID + 分表下標(biāo) + 時(shí)間戳

存在的問(wèn)題

分表后，查詢會(huì)存在一定的問(wèn)題

買家（用戶UID）維度查詢

由于我們是根據(jù)用戶UID來(lái)做分表的，同一個(gè)用戶的所有訂單，都是在同一張表中，每次查詢前，使用用戶UID對(duì)1024取模，得到對(duì)應(yīng)分表的下標(biāo)，然后進(jìn)入對(duì)應(yīng)的分表做簡(jiǎn)單查詢就可以了。

訂單號(hào)維度查詢

由于我們的訂單號(hào)是組合式的，我們可以拿到對(duì)應(yīng)的分表下標(biāo)，所以在查詢前做一步解析訂單號(hào)操作，拿到分表下標(biāo)，去對(duì)應(yīng)的分表里面做簡(jiǎn)單查詢就可以了

賣家UID維度查詢

方案一：

需要根據(jù)賣家UID去不同的分表里面做查詢，這個(gè)代價(jià)太大了。因?yàn)槲覀冞€有一張主表，所以可以從主表里面查詢，這樣可能會(huì)性能不好，但是這的確是一種解決方案。

方案二：

給每個(gè)賣家分配一張表，然后將訂單數(shù)據(jù)同步到對(duì)應(yīng)的賣家UID的數(shù)據(jù)表中，然后查詢的時(shí)候針對(duì)當(dāng)前這個(gè)賣家對(duì)應(yīng)的訂單表查詢。代價(jià)也是不小的，像淘寶，有幾千萬(wàn)的賣家，就需要幾千萬(wàn)張賣家訂單表，這也很麻煩。

方案三：

借助HBase，ES這樣的技術(shù)，去單獨(dú)的存。代價(jià)就是需要多使用一種技術(shù)，增加一種風(fēng)險(xiǎn)。

總結(jié)：

不管如何分庫(kù)分表都是會(huì)存在針對(duì)某一維度的查詢難得問(wèn)題，具體就看你的業(yè)務(wù)能容忍哪種了。

其他字段維度的查詢

這個(gè)就可以將其他維度的字段作為分詞存到ES里面，借助ES的搜索功能做對(duì)應(yīng)的查詢操作。