使用 查詢分離 後 從20s最佳化到500ms

對於業務主表讀寫緩慢的解決方案有這樣一個解決方法：冷熱分離

冷熱分離固然是一個價效比高的解決方案，但也並不是銀彈，仍然有諸多限制，比如：

1. 查詢冷資料慢
2. 業務無法修改冷資料
3. 冷資料多到一定程度系統依舊扛不住

此時如果需要解決以上問題，可以採用另外一種方案：使用 查詢分離 最佳化業務主表資料大查詢緩慢的問題

什麼是查詢分離？

查詢分離從字面上來說非常容易理解，其實就是在寫資料時儲存一個備份資料到另外的儲存系統，在查詢時直接從另外的儲存系統中獲取資料，如下圖：

以上只是簡單的架構圖，其中有些細節還是需要深究，如下：

1. 什麼時候觸發查詢分離？
2. 如何實現查詢分離？
3. 查詢資料的儲存系統選型？
4. 查詢資料如何使用？

查詢分離的適用場景？

當你在實際業務中遇到以下情形，則可以考慮使用查詢分離解決方案。

• 資料量大；

• 所有寫資料的請求效率尚可；

• 查詢資料的請求效率很低；

• 所有的資料任何時候都可能被修改；

• 業務希望我們最佳化查詢資料的功能。

曾做過 SaaS 客服系統的架構最佳化，系統裡有一個工單查詢功能，工單表中存放了幾千萬條資料，且查詢工單表資料時需要關聯十幾個子表，每個子表的資料也是超億條。

面對如此龐大的資料量，跟前面的冷熱分離一樣，每次客戶查詢資料時幾十秒才能返回結果，即便我們使用了索引、SQL 等資料庫最佳化技巧，效果依然不明顯。

工單表中有些資料是幾年前的，客戶說這些資料涉及訴訟問題，需要繼續保持更新，因此我們無法將這些舊資料封存到別的地方，也就沒法透過前面的冷熱分離方案來解決。

最終我們採用了查詢分離的解決方案，才得以將這個問題順利解決：將更新的資料放在一個資料庫裡，而查詢的資料放在另外一個系統裡。因為資料的更新都是單表更新，不需要關聯也沒有外來鍵，所以更新速度立馬得到提升，每次客戶查詢資料時，500ms 內就可得到返回結果。

什麼時候觸發查詢分離？

簡單的來說就是什麼時候應該儲存一份資料到查詢資料庫中，其實也就是資料異構的過程，詳細文章可以看我前面一篇文章：資料異構就該這樣做，yyds~

這裡介紹三種方式，如下：

1. 同步建立
2. 非同步建立
3. binlog方式

1、 同步建立

修改業務程式碼：在寫入常規資料後，同步建立查詢資料。

該種方案優缺點也非常明顯：

優點：查詢資料的一致性和實時性得到了保證

缺點：業務程式碼侵入比較強；減緩寫操作的效率

2、 非同步建立

修改業務程式碼：寫入資料後，非同步建立查詢資料

該種方案的優缺點如下：

優點：不影響主流程

缺點：資料一致性存在問題

3、 binlog的方式

該種方案也是業界常用的一種方案，對於程式碼是無侵入的，透過監聽資料庫日誌的方式建立查詢資料，如下：

該種方案的優缺點如下：

優點：不影響主流程；程式碼侵入為0

缺點：資料一致性存在問題；架構相對複雜

如何實現查詢分離？

對於上述三種方案都算是比較常見的方案，對於第一種同步的方式比較簡單，這裡不再介紹；對於第三種binlog的方式在資料異構的文章中介紹過，詳情見：資料異構就該這樣做，yyds~

這篇文章來介紹一下非同步的方式，非同步的方式有很多，可以放在記憶體中進行操作，但是這有些弊端：

1. 資料過多，記憶體有限
2. 服務重啟，記憶體資料將會丟失

因此最終我們可以選擇MQ的方式，那麼此時就涉及到了MQ的技術選型，這裡給兩個建議：

1. 如果你的公司已經用了MQ，那麼直接接著用即可
2. 如果公司目前未引入MQ，則需要架構組考量選型了，對於MQ的選型可以看我之前文章：聊聊 MQ 技術選型

當然一旦引入了MQ還需要考慮的問題很多，如下：

1、 MQ突然當機了怎麼辦？

MQ當機意味著查詢資料不能繼續建立了，我們可以在寫入資料的同時給該條資料加一個標誌欄位（已搬運、未搬運），當MQ啟動後，查詢所有未搬運的資料，繼續建立查詢資料

“

這裡的方案很多，按照業務實際情況考量

”

2、訊息的冪等消費

訊息的冪等消費一定要保證，避免資料重複建立，比如：主資料的訂單 A 更新後，我們在查詢資料中插入了 A，可是此時系統出問題了，系統誤以為查詢資料沒更新，又把訂單 A 插入更新了一次。

3、訊息的時序性問題

比如某個訂單 A 更新了 1 次資料變成 A1，執行緒甲將 A1 的資料搬到查詢資料中。不一會兒，後臺訂單 A 又更新了 1 次資料變成 A2，執行緒乙也啟動工作，將 A2 的資料搬到查詢資料中。

所謂的時序性就是如果執行緒甲啟動比乙早，但搬運資料動作比執行緒乙還晚完成，就有可能出現查詢資料最終變成過期的 A1

查詢資料的儲存系統選型？

既然為了解決表資料量大查詢緩慢的問題，肯定是不能選用關係型資料庫了，那麼還有其他選擇嗎？

記憶體資料庫雖然效能非常高，比如Redis，但是不適合海量資料，太費錢了

那麼這裡比較適用的有如下三種：

1. MongoDB
2. HBase
3. Elasticsearch

這裡選型還是要根據自己公司業務選擇，如果已經有在用的，則直接用即可；另外就是選擇自己熟悉的，比如當初我們設計架構方案時，為什麼選擇用 Elasticsearch，除 ES 對查詢的擴充套件性支援外，最關鍵的一點是我們團隊對 Elasticsearch 很熟悉。

查詢資料如何使用？

查詢資料很簡單，每個資料庫都有對應的API，直接呼叫查詢

但是，這裡有一個問題：資料查詢更新完前，查詢資料不一致怎麼辦？，給出兩種方案：

1. 在查詢資料更新到最新前，不允許使用者查詢。（我們沒用過這種設計，但我確實見過市面上有這樣的設計。）

2. 給使用者提示：您目前查詢到的資料可能是 1 秒前的資料，如果發現資料不準確，可以嘗試重新整理一下，這種提示使用者一般比較容易接受。

總結

本篇文章介紹了表資料量大查詢緩慢的一種解決方案：查詢分離，但這也不是銀彈，仍然是存在一些不足，比如表資料量大，寫入緩慢怎麼辦？這個後面再介紹吧

當然查詢分離還有一個重要的問題：歷史資料如何遷移？這個處理也是非常簡單，但是也有許多需要考慮的點