先送大家一份福利：

《美團技術(shù)年貨.pdf》（2019-2021）

在2022年春節(jié)到來之際，美團技術(shù)團隊精選過去3年公眾號50多篇技術(shù)文章以及 20多篇國際頂會論文，整理制作成一本厚達1200多頁的電子書，作為新年禮物贈送給大家。 

這本電子書內(nèi)容覆蓋算法、前端、后端、數(shù)據(jù)、安全、測試等多個領(lǐng)域。

希望能對同學們的工作和學習有所幫助。

Code A Better Life

（長按掃碼識別）

無論多么復雜的業(yè)務場景，一條數(shù)據(jù)的一生都體現(xiàn)在CRUD操作上，正是創(chuàng)建、查詢、修改、刪除。正如人的生死輪回，數(shù)據(jù)亦是如此，一條數(shù)據(jù)隨著時間的流逝，其價值也是在逐漸變小。

數(shù)據(jù)存在的價值則是在于它被使用的程度，在不同的系統(tǒng)中，人們對于不同時期的數(shù)據(jù)有著不同的需求。

比如12306、攜程上的火車、機票訂單，人們往往只關(guān)注30天之內(nèi)的訂單，而攜程正是默認只保留30天的訂單信息，超過30天的訂單需要通過手機號查找。

攜程為什么要這么做？

其實仔細想想不難明白，作為全國購票平臺，每年數(shù)以億計的訂單，如果全部能夠開放操作（CRUD），那么系統(tǒng)將會瞬間崩潰。

一個訂單走到終態(tài)的標志則是這筆訂單的完成，也就意味著這筆訂單除了查詢的需求，不再任由用戶修改、刪除。

其實攜程所用的架構(gòu)方法正是：冷熱分離。

什么是冷熱分離？

冷熱分離則是在處理數(shù)據(jù)時將數(shù)據(jù)庫分為熱庫和冷庫兩個庫。冷庫存放的是走到終態(tài)的數(shù)據(jù)，熱庫存放的是還需要修改的數(shù)據(jù)。

比如30天之內(nèi)的機票、火車票訂單，用戶可能需要對這期間的訂單做出退票、開發(fā)票的操作，但是30天之前訂單卻只有查詢的需求，因此可以將30天之內(nèi)的訂單放到熱庫中，之前的訂單存放到冷庫中。

那么這里又引出了兩個概念，分別是：

• 熱數(shù)據(jù)：被頻繁更新；響應時間有要求

• 冷數(shù)據(jù)：不允許更新（具體業(yè)務系統(tǒng)具體分析），偶爾被查詢；響應時間無要求。

什么情況下需要使用冷熱分離？

在大型的互聯(lián)網(wǎng)系統(tǒng)中，如果出現(xiàn)了以下場景則應該考慮冷熱分離：

1. 主業(yè)務響應延遲太大，比如12306下訂單太慢了。
2. 數(shù)據(jù)走到終態(tài)后，沒有更新需求，只有讀的需求，比如訂單的完成狀態(tài)。
3. 用戶能夠接受新舊數(shù)據(jù)分開查詢，比如攜程的訂單查詢30天之前的需要用手機號查詢。

“

補充：當然現(xiàn)在有些系統(tǒng)不像攜程那樣將往期訂單分開查詢，但是其實內(nèi)部也是做了冷熱分離，只不過是在你無感知的情況下完成的。

”

如何判斷一個數(shù)據(jù)是冷數(shù)據(jù)還是熱數(shù)據(jù)？

這個就要根據(jù)自己業(yè)務系統(tǒng)來區(qū)分了，一般而言是根據(jù)主表中的一個或者多個字段進行標識區(qū)分，比如訂單的時間，這個是時間維度，可以將3個月之前的數(shù)據(jù)定義為冷數(shù)據(jù)，最近3個月的數(shù)據(jù)定義為熱數(shù)據(jù)。

當然也可以是狀態(tài)維度，比如訂單的狀態(tài)，已完結(jié)的訂單定義為冷數(shù)據(jù)，未完結(jié)的訂單定義為熱數(shù)據(jù)。

同樣的也可以將時間維度和狀態(tài)維度組合起來，比如下單時間大于3個月且訂單狀態(tài)為已完結(jié)的定義為冷數(shù)據(jù)，反則為熱數(shù)據(jù)。

“

總之：根據(jù)自己業(yè)務需求，具體問題具體分析。

”

但是需要注意以下兩點：

1. 如果一個數(shù)據(jù)被標識為冷數(shù)據(jù)，業(yè)務代碼不會再對它進行寫操作
2. 不會同時存在讀冷/熱數(shù)據(jù)的需求。

如何實現(xiàn)冷熱數(shù)據(jù)分離？

一切的理論知識都要經(jīng)過實戰(zhàn)的檢驗，基礎(chǔ)知識了解了，那么如何實現(xiàn)冷熱數(shù)據(jù)的分離呢？下面介紹三種常見的方法。

1、業(yè)務代碼修改

這種方案是直接修改業(yè)務代碼，對代碼的侵入性比較高，無法按照時間進行區(qū)分，在數(shù)據(jù)修改時觸發(fā)冷熱分離。

該種方案需要在業(yè)務代碼層面判斷是否需要冷熱分離，比如訂單的狀態(tài)修改，一旦狀態(tài)為終態(tài)則將這條數(shù)據(jù)標記為冷數(shù)據(jù)，然后觸發(fā)冷熱處理，將其寫入冷庫，同時刪除熱庫中的這筆數(shù)據(jù)。

2、監(jiān)聽數(shù)據(jù)庫日志

該種方案需要監(jiān)聽binlog日志的方式進行觸發(fā)，比如訂單狀態(tài)修改了，則觸發(fā)冷熱分離。

同樣的這里無法按照時間區(qū)分，但是對代碼無侵入。

監(jiān)聽binlog日志的工具有很多，前面介紹過，比如阿里的canal，還有其他的開源中間件可供選擇，如下：

對于MySQL數(shù)據(jù)庫建議選擇canal，使用方式看：實戰(zhàn)！Spring Boot 整合 阿里開源中間件 Canal 實現(xiàn)數(shù)據(jù)增量同步！

整個流程如下圖：

3、定時任務掃描

該種方案可以按照時間區(qū)分，與業(yè)務代碼解耦，是個不錯的選擇。

流程如下：

總結(jié)

解決讀寫緩慢的問題冷熱分離是個不錯的選擇，上述介紹了三種方案實現(xiàn)冷熱分離，雖說都能實現(xiàn)，但是仍然要考慮諸多問題，最棘手的問題就是數(shù)據(jù)一致性的問題。

在冷熱分離的處理邏輯中一定要保證熱庫、冷庫中的數(shù)據(jù)一致性問題，手段很多，這里就不再過多介紹了。

1. 如果這篇文章對你有所幫助，或者有所啟發(fā)的話，幫忙點贊、在看、轉(zhuǎn)發(fā)、收藏，你的支持就是我堅持下去的最大動力！