1.前提

這次數據庫的冷熱分離算是第二次做了
其實之前已經做過一次冷熱分離了,涉及到數據庫復制時,當時是趨近于業務的(后面會詳細講),整體來講不是很好用,這次算是重構了吧
做的最終結果還是和前一次一樣:
數據庫中的訂單數據,是每時每刻都在增加
我們認為3個月以內的數據,用戶會頻繁的操作,稱為熱數據
3個月以前的數據,基本上不會有修改的地方了,查詢也是很少量的,我們稱為冷數據
所以將現有數據庫稱之為生產庫,
然后再增加一個獨立的庫,我們稱之為歷史庫,
我們要做的就是生產庫中只放3個月內的數據,
歷史庫放所有的數據,
查詢的時候,主查生產庫,生產庫沒有,再考慮查詢歷史庫,
生產庫提供所有的業務操作,
歷史庫只提供查詢功能,不提供其他業務功能,

2.前一次冷熱分離的思路

因為項目在數據入庫的時候,業務需求,會發一個mq消息給其他下游,前一次的思路就是復用這個消息
讓我們的項目反過來再消費這個消息,就可以異步獲得數據的變化情況,再將數據同步到歷史庫中
前一次冷熱分離的細節,在這個文章里

正所謂 : 成也復用,敗也復用

上次做完后,當時的效果也很好,確實冷熱分離了,生產庫的壓力也確實小了很多

但是復用帶來問題馬上就暴露出來了:

項目設計到需求的變化,需要增加字段,并且原邏輯也有變化
這樣帶來的問題是,做需求的時候,需要格外注意數據的同步,
尤其是一些狀態的變化,很容易造成生產庫改了,沒有同步到歷史庫中
久而久之,加上沒人專門維護這個歷史庫,歷史庫的數據已經亂的不成樣子

3.這一次冷熱分離的思路

有了上次的經驗教訓,這次就老實多了,直接使用binlog日志,
數據庫的每一次增加和修改操作,mysql開啟binlog后,都能在binlog日志中記錄,
采用這一特性,通過數據庫級別的監控,就不需要擔心業務上的變化帶來的不一致了,
只要生產庫的數據有變化,我們就可以根據binlog日志,直接將數據同步到歷史庫中
這一次冷熱分離的細節,在這個文章里

總結

以上是生活随笔為你收集整理的[数据库]-----mysql数据的冷热分离 第二版的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。