回答列表
查詢分離從字面上來說非常容易理解，其實就是在寫數據時保存一個備份數據到另外的存儲系統，在查詢時直接從另外的存儲系統中獲取數據，如下圖：
以上只是簡單的架構圖，其中有些細節還是需要深究，如下：
什麼時候觸發查詢分離？如何實現查詢分離？查詢數據的存儲系統選型？查詢數據如何使用？查詢分離的適用場景。
當你在實際業務中遇到以下情形，則可以考慮使用查詢分離解決方案。
數據量大。
所有寫數據的請求效率尚可。
查詢數據的請求效率很低。
所有的數據任何時候都可能被修改。
業務希望我們優化查詢數據的功能。
曾做過 saas 客服系統的架構優化，系統里有一個工單查詢功能，工單表中存放了幾千萬條數據，且查詢工單表數據時需要關聯十幾個子表，每個子表的數據也是超億條。
面對如此龐大的數據量，跟前面的冷熱分離一樣，每次客戶查詢數據時幾十秒才能返回結果，即便我們使用了索引、sql 等資料庫優化技巧，效果依然不明顯。
工單表中有些數據是幾年前的，客戶說這些數據涉及訴訟問題，需要繼續保持更新，因此我們無法將這些舊數據封存到別的地方，也就沒法通過前面的冷熱分離方案來解決。
最終我們採用了查詢分離的解決方案，才得以將這個問題順利解決：將更新的數據放在一個資料庫里，而查詢的數據放在另外一個系統里。因為數據的更新都是單表更新，不需要關聯也沒有外鍵，所以更新速度立馬得到提升，每次客戶查詢數據時，500ms 內就可得到返回結果。
什麼時候觸發查詢分離。
簡單的來說就是什麼時候應該保存一份數據到查詢資料庫中，其實也就是數據異構的過程，詳細文章可以看我前面一篇文章：數據異構就該這樣做，yyds~。
這裡介紹三種方式，如下：
同步建立異步建立binlog方式1、 同步建立。
修改業務代碼：在寫入常規數據後，同步建立查詢數據。
該種方案優缺點也非常明顯：
優點：查詢數據的一致性和實時性得到了保證。
缺點：業務代碼侵入比較強；減緩寫操作的效率。
2、 異步建立。
修改業務代碼：寫入數據後，異步建立查詢數據。
該種方案的優缺點如下：
優點：不影響主流程。
缺點：數據一致性存在問題。
3、 binlog的方式。
該種方案也是業界常用的一種方案，對於代碼是無侵入的，通過監聽資料庫日誌的方式建立查詢數據，如下：
該種方案的優缺點如下：
優點：不影響主流程；代碼侵入為0。
缺點：數據一致性存在問題；架構相對複雜。
如何實現查詢分離。
對於上述三種方案都算是比較常見的方案，對於第一種同步的方式比較簡單，這裡不再介紹；對於第三種binlog的方式在數據異構的文章中介紹過，詳情見：數據異構就該這樣做，yyds~。
這篇文章來介紹一下異步的方式，異步的方式有很多，可以放在內存中進行操作，但是這有些弊端：
數據過多，內存有限服務重啟，內存數據將會丟失。
因此最終我們可以選擇mq的方式，那麼此時就涉及到了mq的技術選型，這裡給兩個建議：
如果你的公司已經用了mq，那麼直接接著用即可如果公司目前未引入mq，則需要架構組考量選型了，對於mq的選型可以看我之前文章：聊聊 mq 技術選型。
當然一旦引入了mq還需要考慮的問題很多，如下：
1、 mq突然宕機了怎麼辦。
mq宕機意味著查詢數據不能繼續建立了，我們可以在寫入數據的同時給該條數據加一個標誌欄位（已搬運、未搬運），當mq啟動後，查詢所有未搬運的數據，繼續建立查詢數據。
「。
這裡的方案很多，按照業務實際情況考量。
」2、消息的冪等消費。
消息的冪等消費一定要保證，避免數據重複建立，比如：主數據的訂單 a 更新後，我們在查詢數據中插入了 a，可是此時系統出問題了，系統誤以為查詢數據沒更新，又把訂單 a 插入更新了一次。
3、消息的時序性問題。
比如某個訂單 a 更新了 1 次數據變成 a1，線程甲將 a1 的數據搬到查詢數據中。不一會兒，後台訂單 a 又更新了 1 次數據變成 a2，線程乙也啟動工作，將 a2 的數據搬到查詢數據中。
所謂的時序性就是如果線程甲啟動比乙早，但搬運數據動作比線程乙還晚完成，就有可能出現查詢數據最終變成過期的 a1。
查詢數據的存儲系統選型。
既然為了解決表數據量大查詢緩慢的問題，肯定是不能選用關係型資料庫了，那麼還有其他選擇嗎？
內存資料庫雖然性能非常高，比如redis，但是不適合海量數據，太費錢了。
那麼這裡比較適用的有如下三種：
mongodbhbaseelasticsearch、這裡選型還是要根據自己公司業務選擇，如果已經有在用的，則直接用即可；另外就是選擇自己熟悉的，比如當初我們設計架構方案時，為什麼選擇用 elasticsearch，除 es 對查詢的擴展性支持外，最關鍵的一點是我們團隊對 elasticsearch 很熟悉。
查詢數據如何使用。
查詢數據很簡單，每個資料庫都有對應的api，直接調用查詢。
但是，這裡有一個問題：數據查詢更新完前，查詢數據不一致怎麼辦？，給出兩種方案：
在查詢數據更新到最新前，不允許用戶查詢。（我們沒用過這種設計，但我確實見過市面上有這樣的設計。）。
給用戶提示：您目前查詢到的數據可能是 1 秒前的數據，如果發現數據不準確，可以嘗試刷新一下，這種提示用戶一般比較容易接受。
以上只是簡單的架構圖，其中有些細節還是需要深究，如下：
什麼時候觸發查詢分離？如何實現查詢分離？查詢數據的存儲系統選型？查詢數據如何使用？查詢分離的適用場景。
當你在實際業務中遇到以下情形，則可以考慮使用查詢分離解決方案。
數據量大。
所有寫數據的請求效率尚可。
查詢數據的請求效率很低。
所有的數據任何時候都可能被修改。
業務希望我們優化查詢數據的功能。
曾做過 saas 客服系統的架構優化，系統里有一個工單查詢功能，工單表中存放了幾千萬條數據，且查詢工單表數據時需要關聯十幾個子表，每個子表的數據也是超億條。
面對如此龐大的數據量，跟前面的冷熱分離一樣，每次客戶查詢數據時幾十秒才能返回結果，即便我們使用了索引、sql 等資料庫優化技巧，效果依然不明顯。
工單表中有些數據是幾年前的，客戶說這些數據涉及訴訟問題，需要繼續保持更新，因此我們無法將這些舊數據封存到別的地方，也就沒法通過前面的冷熱分離方案來解決。
最終我們採用了查詢分離的解決方案，才得以將這個問題順利解決：將更新的數據放在一個資料庫里，而查詢的數據放在另外一個系統里。因為數據的更新都是單表更新，不需要關聯也沒有外鍵，所以更新速度立馬得到提升，每次客戶查詢數據時，500ms 內就可得到返回結果。
什麼時候觸發查詢分離。
簡單的來說就是什麼時候應該保存一份數據到查詢資料庫中，其實也就是數據異構的過程，詳細文章可以看我前面一篇文章：數據異構就該這樣做，yyds~。
這裡介紹三種方式，如下：
同步建立異步建立binlog方式1、 同步建立。
修改業務代碼：在寫入常規數據後，同步建立查詢數據。
該種方案優缺點也非常明顯：
優點：查詢數據的一致性和實時性得到了保證。
缺點：業務代碼侵入比較強；減緩寫操作的效率。
2、 異步建立。
修改業務代碼：寫入數據後，異步建立查詢數據。
該種方案的優缺點如下：
優點：不影響主流程。
缺點：數據一致性存在問題。
3、 binlog的方式。
該種方案也是業界常用的一種方案，對於代碼是無侵入的，通過監聽資料庫日誌的方式建立查詢數據，如下：
該種方案的優缺點如下：
優點：不影響主流程；代碼侵入為0。
缺點：數據一致性存在問題；架構相對複雜。
如何實現查詢分離。
對於上述三種方案都算是比較常見的方案，對於第一種同步的方式比較簡單，這裡不再介紹；對於第三種binlog的方式在數據異構的文章中介紹過，詳情見：數據異構就該這樣做，yyds~。
這篇文章來介紹一下異步的方式，異步的方式有很多，可以放在內存中進行操作，但是這有些弊端：
數據過多，內存有限服務重啟，內存數據將會丟失。
因此最終我們可以選擇mq的方式，那麼此時就涉及到了mq的技術選型，這裡給兩個建議：
如果你的公司已經用了mq，那麼直接接著用即可如果公司目前未引入mq，則需要架構組考量選型了，對於mq的選型可以看我之前文章：聊聊 mq 技術選型。
當然一旦引入了mq還需要考慮的問題很多，如下：
1、 mq突然宕機了怎麼辦。
mq宕機意味著查詢數據不能繼續建立了，我們可以在寫入數據的同時給該條數據加一個標誌欄位（已搬運、未搬運），當mq啟動後，查詢所有未搬運的數據，繼續建立查詢數據。
「。
這裡的方案很多，按照業務實際情況考量。
」2、消息的冪等消費。
消息的冪等消費一定要保證，避免數據重複建立，比如：主數據的訂單 a 更新後，我們在查詢數據中插入了 a，可是此時系統出問題了，系統誤以為查詢數據沒更新，又把訂單 a 插入更新了一次。
3、消息的時序性問題。
比如某個訂單 a 更新了 1 次數據變成 a1，線程甲將 a1 的數據搬到查詢數據中。不一會兒，後台訂單 a 又更新了 1 次數據變成 a2，線程乙也啟動工作，將 a2 的數據搬到查詢數據中。
所謂的時序性就是如果線程甲啟動比乙早，但搬運數據動作比線程乙還晚完成，就有可能出現查詢數據最終變成過期的 a1。
查詢數據的存儲系統選型。
既然為了解決表數據量大查詢緩慢的問題，肯定是不能選用關係型資料庫了，那麼還有其他選擇嗎？
內存資料庫雖然性能非常高，比如redis，但是不適合海量數據，太費錢了。
那麼這裡比較適用的有如下三種：
mongodbhbaseelasticsearch、這裡選型還是要根據自己公司業務選擇，如果已經有在用的，則直接用即可；另外就是選擇自己熟悉的，比如當初我們設計架構方案時，為什麼選擇用 elasticsearch，除 es 對查詢的擴展性支持外，最關鍵的一點是我們團隊對 elasticsearch 很熟悉。
查詢數據如何使用。
查詢數據很簡單，每個資料庫都有對應的api，直接調用查詢。
但是，這裡有一個問題：數據查詢更新完前，查詢數據不一致怎麼辦？，給出兩種方案：
在查詢數據更新到最新前，不允許用戶查詢。（我們沒用過這種設計，但我確實見過市面上有這樣的設計。）。
給用戶提示：您目前查詢到的數據可能是 1 秒前的數據，如果發現數據不準確，可以嘗試刷新一下，這種提示用戶一般比較容易接受。