冷熱分離固然是一個(gè)性價(jià)比高的解決方案，但也并不是銀彈，仍然有諸多限制，比如：

1. 查詢冷數(shù)據(jù)慢
2. 業(yè)務(wù)無(wú)法修改冷數(shù)據(jù)
3. 冷數(shù)據(jù)多到一定程度系統(tǒng)依舊扛不住

此時(shí)如果需要解決以上問(wèn)題，可以采用另外一種方案：使用 查詢分離 優(yōu)化業(yè)務(wù)主表數(shù)據(jù)大查詢緩慢的問(wèn)題

什么是查詢分離？

查詢分離從字面上來(lái)說(shuō)非常容易理解，其實(shí)就是在寫數(shù)據(jù)時(shí)保存一個(gè)備份數(shù)據(jù)到另外的存儲(chǔ)系統(tǒng)，在查詢時(shí)直接從另外的存儲(chǔ)系統(tǒng)中獲取數(shù)據(jù)，如下圖：

查詢分離

以上只是簡(jiǎn)單的架構(gòu)圖，其中有些細(xì)節(jié)還是需要深究，如下：

1. 什么時(shí)候觸發(fā)查詢分離？
2. 如何實(shí)現(xiàn)查詢分離？
3. 查詢數(shù)據(jù)的存儲(chǔ)系統(tǒng)選型？
4. 查詢數(shù)據(jù)如何使用？

查詢分離的適用場(chǎng)景？

當(dāng)你在實(shí)際業(yè)務(wù)中遇到以下情形，則可以考慮使用查詢分離解決方案。

• 數(shù)據(jù)量大；
• 所有寫數(shù)據(jù)的請(qǐng)求效率尚可；
• 查詢數(shù)據(jù)的請(qǐng)求效率很低；
• 所有的數(shù)據(jù)任何時(shí)候都可能被修改；
• 業(yè)務(wù)希望我們優(yōu)化查詢數(shù)據(jù)的功能。

曾做過(guò) SaaS 客服系統(tǒng)的架構(gòu)優(yōu)化，系統(tǒng)里有一個(gè)工單查詢功能，工單表中存放了幾千萬(wàn)條數(shù)據(jù)，且查詢工單表數(shù)據(jù)時(shí)需要關(guān)聯(lián)十幾個(gè)子表，每個(gè)子表的數(shù)據(jù)也是超億條。

面對(duì)如此龐大的數(shù)據(jù)量，跟前面的冷熱分離一樣，每次客戶查詢數(shù)據(jù)時(shí)幾十秒才能返回結(jié)果，即便我們使用了索引、SQL 等數(shù)據(jù)庫(kù)優(yōu)化技巧，效果依然不明顯。

工單表中有些數(shù)據(jù)是幾年前的，客戶說(shuō)這些數(shù)據(jù)涉及訴訟問(wèn)題，需要繼續(xù)保持更新，因此我們無(wú)法將這些舊數(shù)據(jù)封存到別的地方，也就沒法通過(guò)前面的冷熱分離方案來(lái)解決。

最終我們采用了查詢分離的解決方案，才得以將這個(gè)問(wèn)題順利解決：將更新的數(shù)據(jù)放在一個(gè)數(shù)據(jù)庫(kù)里，而查詢的數(shù)據(jù)放在另外一個(gè)系統(tǒng)里。因?yàn)閿?shù)據(jù)的更新都是單表更新，不需要關(guān)聯(lián)也沒有外鍵，所以更新速度立馬得到提升，每次客戶查詢數(shù)據(jù)時(shí)，500ms 內(nèi)就可得到返回結(jié)果。

什么時(shí)候觸發(fā)查詢分離？

簡(jiǎn)單的來(lái)說(shuō)就是什么時(shí)候應(yīng)該保存一份數(shù)據(jù)到查詢數(shù)據(jù)庫(kù)中，其實(shí)也就是數(shù)據(jù)異構(gòu)的過(guò)程。

• 同步建立
• 異步建立
• binlog方式

1、 同步建立

修改業(yè)務(wù)代碼：在寫入常規(guī)數(shù)據(jù)后，同步建立查詢數(shù)據(jù)。

圖片

該種方案優(yōu)缺點(diǎn)也非常明顯：

優(yōu)點(diǎn)：查詢數(shù)據(jù)的一致性和實(shí)時(shí)性得到了保證

缺點(diǎn)：業(yè)務(wù)代碼侵入比較強(qiáng)；減緩寫操作的效率

2、 異步建立

修改業(yè)務(wù)代碼：寫入數(shù)據(jù)后，異步建立查詢數(shù)據(jù)

圖片

該種方案的優(yōu)缺點(diǎn)如下：

優(yōu)點(diǎn)：不影響主流程

缺點(diǎn)：數(shù)據(jù)一致性存在問(wèn)題

3、 binlog的方式

該種方案也是業(yè)界常用的一種方案，對(duì)于代碼是無(wú)侵入的，通過(guò)監(jiān)聽數(shù)據(jù)庫(kù)日志的方式建立查詢數(shù)據(jù)，如下：

圖片

該種方案的優(yōu)缺點(diǎn)如下：

優(yōu)點(diǎn)：不影響主流程；代碼侵入為0

缺點(diǎn)：數(shù)據(jù)一致性存在問(wèn)題；架構(gòu)相對(duì)復(fù)雜

如何實(shí)現(xiàn)查詢分離？

對(duì)于上述三種方案都算是比較常見的方案，對(duì)于第一種同步的方式比較簡(jiǎn)單，這里不再介紹；

這篇文章來(lái)介紹一下異步的方式，異步的方式有很多，可以放在內(nèi)存中進(jìn)行操作，但是這有些弊端：

• 數(shù)據(jù)過(guò)多，內(nèi)存有限
• 服務(wù)重啟，內(nèi)存數(shù)據(jù)將會(huì)丟失

因此最終我們可以選擇MQ的方式，那么此時(shí)就涉及到了MQ的技術(shù)選型，這里給兩個(gè)建議：

1. 如果你的公司已經(jīng)用了MQ，那么直接接著用即可
2. 如果公司目前未引入MQ，則需要架構(gòu)組考量選型了，對(duì)于MQ的選型可以看我之前文章：聊聊 MQ 技術(shù)選型

當(dāng)然一旦引入了MQ還需要考慮的問(wèn)題很多，如下：

1、 MQ突然宕機(jī)了怎么辦？

MQ宕機(jī)意味著查詢數(shù)據(jù)不能繼續(xù)建立了，我們可以在寫入數(shù)據(jù)的同時(shí)給該條數(shù)據(jù)加一個(gè)標(biāo)志字段（已搬運(yùn)、未搬運(yùn)），當(dāng)MQ啟動(dòng)后，查詢所有未搬運(yùn)的數(shù)據(jù)，繼續(xù)建立查詢數(shù)據(jù)

這里的方案很多，按照業(yè)務(wù)實(shí)際情況考量

2、消息的冪等消費(fèi)

消息的冪等消費(fèi)一定要保證，避免數(shù)據(jù)重復(fù)建立，比如：主數(shù)據(jù)的訂單 A 更新后，我們?cè)诓樵償?shù)據(jù)中插入了 A，可是此時(shí)系統(tǒng)出問(wèn)題了，系統(tǒng)誤以為查詢數(shù)據(jù)沒更新，又把訂單 A 插入更新了一次。

3、消息的時(shí)序性問(wèn)題

比如某個(gè)訂單 A 更新了 1 次數(shù)據(jù)變成 A1，線程甲將 A1 的數(shù)據(jù)搬到查詢數(shù)據(jù)中。不一會(huì)兒，后臺(tái)訂單 A 又更新了 1 次數(shù)據(jù)變成 A2，線程乙也啟動(dòng)工作，將 A2 的數(shù)據(jù)搬到查詢數(shù)據(jù)中。

所謂的時(shí)序性就是如果線程甲啟動(dòng)比乙早，但搬運(yùn)數(shù)據(jù)動(dòng)作比線程乙還晚完成，就有可能出現(xiàn)查詢數(shù)據(jù)最終變成過(guò)期的 A1

查詢數(shù)據(jù)的存儲(chǔ)系統(tǒng)選型？

既然為了解決表數(shù)據(jù)量大查詢緩慢的問(wèn)題，肯定是不能選用關(guān)系型數(shù)據(jù)庫(kù)了，那么還有其他選擇嗎？

內(nèi)存數(shù)據(jù)庫(kù)雖然性能非常高，比如Redis，但是不適合海量數(shù)據(jù)，太費(fèi)錢了

那么這里比較適用的有如下三種：

• MongoDB
• HBase
• Elasticsearch

這里選型還是要根據(jù)自己公司業(yè)務(wù)選擇，如果已經(jīng)有在用的，則直接用即可；另外就是選擇自己熟悉的，比如當(dāng)初我們?cè)O(shè)計(jì)架構(gòu)方案時(shí)，為什么選擇用 Elasticsearch，除 ES 對(duì)查詢的擴(kuò)展性支持外，最關(guān)鍵的一點(diǎn)是我們團(tuán)隊(duì)對(duì) Elasticsearch 很熟悉。

查詢數(shù)據(jù)如何使用？

查詢數(shù)據(jù)很簡(jiǎn)單，每個(gè)數(shù)據(jù)庫(kù)都有對(duì)應(yīng)的API，直接調(diào)用查詢

但是，這里有一個(gè)問(wèn)題：數(shù)據(jù)查詢更新完前，查詢數(shù)據(jù)不一致怎么辦？，給出兩種方案：

1. 在查詢數(shù)據(jù)更新到最新前，不允許用戶查詢。（我們沒用過(guò)這種設(shè)計(jì)，但我確實(shí)見過(guò)市面上有這樣的設(shè)計(jì)。）
2. 給用戶提示：您目前查詢到的數(shù)據(jù)可能是 1 秒前的數(shù)據(jù)，如果發(fā)現(xiàn)數(shù)據(jù)不準(zhǔn)確，可以嘗試刷新一下，這種提示用戶一般比較容易接受。

總結(jié)

本篇文章介紹了表數(shù)據(jù)量大查詢緩慢的一種解決方案：查詢分離，但這也不是銀彈，仍然是存在一些不足，比如表數(shù)據(jù)量大，寫入緩慢怎么辦？

當(dāng)然查詢分離還有一個(gè)重要的問(wèn)題：歷史數(shù)據(jù)如何遷移？這個(gè)處理也是非常簡(jiǎn)單，但是也有許多需要考慮的點(diǎn)，