記一次操蛋的方案降級（雲上冷熱分離的坎坷之路）

原創：小姐姐味道（微信公衆號ID：xjjdog），歡迎分享，轉載請保留出處。

系統的數據，就是公司的生命。哪怕是狗屎，咱們也要將它冷凍起來冰封以備後用。垃圾的產品設計就比較讓人費解，會時不時從冰櫃中將屎取出，想要品嚐其中殘留的味道。

不過這其中，仍是有些有價值的需求。這種狀況，就須要將數據進行冷熱分離，對數據進行隔離。不至於讓一顆老鼠屎，壞了一鍋粥。

xjjdog今天給你們分享的，是一個很是常見的冷熱分離的功能，方案有不少，只舉例最多見的。

最終，在rds的限制下，只能選了一個不是最美的方案。這從側面證實了老婆不是最漂亮的好，要最合適的才能幸福圓滿。

問題場景

隨着業務的發展，數據庫增加的很快。老闆不明白其中道理，但做爲數據庫的維護者，卻看的膽顫心驚。

終於，數據庫慢慢的接近數瓶頸點，管理員也愈來愈焦慮。

使用分區表吧，不行。就如上面所說，有些挖祖墳的請求，會加載一些好久以前的數據，分區表並不能解決問題。

明顯要對數據進行一下切割，進行冷熱分離了。

大致的結構如上圖。咱們有一個數據路由，負責根據時間維度區分數據，定位到相應的數據庫中進行查詢。

熱庫和冷庫，多是異構的。

解決思路

問題已經進行了轉化。咱們接下來的目標，變成了怎麼根據時間維度，構建熱數據和冷數據的分離。

目前使用最多的數據庫是mysql，咱們也從它提及。

其實，冷熱分離的兩份數據，查詢「最近時間」的數據，是沒什麼差異的。惟一不一樣的是，熱庫，會定時的刪除舊的數據。

雙寫

雙寫是最簡單，可是又最不靠譜的方案。結構以下圖。

可是注意，操做步驟一、2，涉及到分佈式事務，須要同時保證兩個庫的寫入成功。

這就讓事情變的麻煩了一些。做爲一個吃過無數次事務問題的虧的人，不會重蹈這樣的覆轍。

因此，這種方案，直接pass。

走消息

細心的同窗應該發現了上圖的優化點，經過引入一個叫作消息隊列的東西，就能夠把分佈式事務這座大山給繞過去，只保證最終一致性便可。

多麼美好的設想。理想很豐滿，現實很骨感。因爲冷熱分離涉及到很是多的數據表，須要修改不可預知的業務代碼，遭到了你們的一致反對。

此方案無疾而終。

直接看圖，變了兩根線而已。

使用binlog

有的同窗可能已經憋不住了：爲何不用binlog？接下來咱們就談下這種方案。

不能否認，這是種很是優雅的方式。數據只須要寫入熱庫就能夠了，經過數據訂閱的方式，增量的將數據寫入到冷庫。

可是等等。咱們的定時任務，刪除數據的時候，一樣也要產生binlog。如何區別數據的刪除，是定時任務產生的，仍是正常的業務產生？

還好，xjjdog知曉一個很是隱祕的方式去操做。

對對對，就是下面的過程。

set session sql_log_bin=0;
//opt
set session sql_log_bin=1;
複製代碼

binlog能夠設置session級別的，也就是在此session中操做的語句，並不會產生binlog。

這樣，咱們在定時任務執行時，先關閉binlog，而後，執行刪除語句，而後，從新恢復binlog。這些刪除的數據，就不會經過canal同步到冷庫中了。

萬萬沒想到

mmp?

爲何不支持呢？爲何呢？容我當心翼翼的猜測一下。你的rds啊，有可能在和別人在共用一個實例呢。

其實，除了rds的限制，此方案還存在一個bug。好比熱庫有冷熱分離的時候。想一想爲甚麼吧。

標記清除

得了，xjjdog只能曲線救國了。用最2的方式完成這個操蛋的功能。

標記清除。這四個醒目的大字，讓人不禁自主的想到jvm的垃圾回收算法。

原理其實也相似，步驟也是一分爲二。

第1、標記階段

給每一張數據表，都加一個叫作mark2Del字段。而後，經過定時，標記全部要過時（也就是要放入冷庫的數據）。

第2、清除階段

在下一次定時來臨時，將上次標記要刪除的數據，逐條搬遷到冷庫。搬遷完畢後，進行下一輪標記。

此方案很是簡單，但有個致命弱點。因爲全部的庫表，都是老表，都須要增長一個叫作mark2Del的字段，甚是麻煩。

然而，上面的介紹，只是解決了數據的刪除，並無解決數據的同步。

最終方案

結合以上的描述，以及環境的限制。咱們選擇了使用binlog+標記清除的方式。

標記清除負責刪除數據。

binlog負責增量同步數據。只是，在這個同步邏輯中，多了一個判斷，若是mark2Del的值被設置成了true，則忽略此binlog。

也就是說，咱們強行給每條刪除的記錄，追加了一個判斷標誌。

這樣，系統終於跑起來了。

End

上文描述的，是mysql到mysql之間的冷熱分離。

但若是，我想要作一個分層的數據倉庫。

第一層，是熱庫。

第二層，是冷庫。

第三層，是存檔庫，多是druid這種大數據存儲。

該如何設計？

本文不作過多介紹。架構的難點不在結果，而在於過程。

你看起來很挫的方案，總有它背後的故事，嘗試着去理解，大有裨益。

除非它是真的挫。不過，這不也是你的機會麼？

做者簡介：小姐姐味道 (xjjdog)，一個不容許程序員走彎路的公衆號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高併發世界，給你不同的味道。個人我的微信xjjdog0，歡迎添加好友，​進一步交流。​