無論多麼複雜的業務場景，一條資料的一生都體現在crud操作上，正是建立、查詢、修改、刪除。正如人的生死輪迴，資料亦是如此，一條資料隨著時間的流逝，其價值也是在逐漸變小。
資料存在的價值則是在於它被使用的程度，在不同的系統中，人們對於不同時期的資料有著不同的需求。
比如12306、攜程上的火車、機票訂單，人們往往只關注30天之內的訂單，而攜程正是預設只保留30天的訂單資訊，超過30天的訂單需要通過手機號查詢。
攜程訂單
攜程為什麼要這麼做？
其實仔細想想不難明白，作為全國購票平台，每年數以億計的訂單，如果全部能夠開放操作（crud），那麼系統將會瞬間崩潰。
乙個訂單走到終態的標誌則是這筆訂單的完成，也就意味著這筆訂單除了查詢的需求，不再任由使用者修改、刪除。
其實攜程所用的架構方法正是：冷熱分離。
冷熱分離則是在處理資料時將資料庫分為熱庫和冷庫兩個庫。冷庫存放的是走到終態的資料，熱庫存放的是還需要修改的資料。
比如30天之內的機票、火車票訂單，使用者可能需要對這期間的訂單做出退票、開發票的操作，但是30天之前訂單卻只有查詢的需求，因此可以將30天之內的訂單放到熱庫中，之前的訂單存放到冷庫中。
那麼這裡又引出了兩個概念，分別是：
在大型的網際網路系統中，如果出現了以下場景則應該考慮冷熱分離：
主業務響應延遲太大，比如12306下訂單太慢了。
資料走到終態後，沒有更新需求，只有讀的需求，比如訂單的完成狀態。
使用者能夠接受新舊資料分開查詢，比如攜程的訂單查詢30天之前的需要用手機號查詢。
補充：當然現在有些系統不像攜程那樣將往期訂單分開查詢，但是其實內部也是做了冷熱分離，只不過是在你無感知的情況下完成的。這個就要根據自己業務系統來區分了，一般而言是根據主表中的乙個或者多個字段進行標識區分，比如訂單的時間，這個是時間維度，可以將3個月之前的資料定義為冷資料，最近3個月的資料定義為熱資料。
當然也可以是狀態維度，比如訂單的狀態，已完結的訂單定義為冷資料，未完結的訂單定義為熱資料。
同樣的也可以將時間維度和狀態維度組合起來，比如下單時間大於3個月且訂單狀態為已完結的定義為冷資料，反則為熱資料。
總之但是需要注意以下兩點：：根據自己業務需求，具體問題具體分析。
如果乙個資料被標識為冷資料，業務**不會再對它進行寫操作
不會同時存在讀冷/熱資料的需求。
一切的理論知識都要經過實戰的檢驗，基礎知識了解了，那麼如何實現冷熱資料的分離呢？下面介紹三種常見的方法。
這種方案是直接修改業務**，對**的侵入性比較高，無法按照時間進行區分，在資料修改時觸發冷熱分離。
該種方案需要在業務**層面判斷是否需要冷熱分離，比如訂單的狀態修改，一旦狀態為終態則將這條資料標記為冷資料，然後觸發冷熱處理，將其寫入冷庫，同時刪除熱庫中的這筆資料。
該種方案需要監聽binlog日誌的方式進行觸發，比如訂單狀態修改了，則觸發冷熱分離。
同樣的這裡無法按照時間區分，但是對**無侵入。
監聽binlog日誌的工具有很多，前面介紹過，比如阿里的canal，還有其他的開源中介軟體可供選擇，如下：
對於mysql資料庫建議選擇canal，使用方式看：實戰！spring boot 整合 阿里開源中介軟體 canal 實現資料增量同步！
整個流程如下圖：
該種方案可以按照時間區分，與業務**解耦，是個不錯的選擇。
流程如下：
解決讀寫緩慢的問題冷熱分離是個不錯的選擇，上述介紹了三種方案實現冷熱分離，雖說都能實現，但是仍然要考慮諸多問題，最棘手的問題就是資料一致性的問題。
在冷熱分離的處理邏輯中一定要保證熱庫、冷庫中的資料一致性問題，手段很多，這裡就不再過多介紹了。
如何準備阿里技術面試？終面官現身說法！
春暖花開的季節，阿里巴巴的春招面試正如火如荼地進行著。相信同學們也在面試這塊做了許多準備，那麼，參加阿里的面試需要注意些什麼？今天，我們特別邀請到資深終面官永叔給同學們送上最實用的面試秘籍。a 面試的基本要點很多，很多同學容易犯的一些小問題，我總結幾個點分享給大家 一定不要遲到，這是起碼的尊重。對面...
如何準備阿里技術面試？終面官現身說法！
春暖花開的季節，阿里巴巴的春招面試正如火如荼地進行著。相信同學們也在面試這塊做了許多準備，那麼，參加阿里的面試需要注意些什麼？今天，我們特別邀請到資深終面官永叔給同學們送上最實用的面試秘籍。q 面試官看簡歷，最關注哪些部分？q 面試過這麼多同學，您對同學們有什麼面試忠告？a 面試的基本要點很多，很多...
阿里一面 電話面
前端小白記錄一下面試經歷 首先面試官特別和藹可親，聲音很溫柔。開始就是做了下自我介紹，blablabla.接下來就專案談了一下做了哪些專案，用過哪些技術，遇到過哪些難題之類的。下面就是技術問題了 記住，搞懂原理很重要 1.闡述一下ajax原理 2.解釋一下vuex原理 3.vue雙向繫結原理 4.解...