[数据库]-----mysql数据的冷热分离 第二版
1.前提
這次數(shù)據(jù)庫(kù)的冷熱分離算是第二次做了
其實(shí)之前已經(jīng)做過(guò)一次冷熱分離了,涉及到數(shù)據(jù)庫(kù)復(fù)制時(shí),當(dāng)時(shí)是趨近于業(yè)務(wù)的(后面會(huì)詳細(xì)講),整體來(lái)講不是很好用,這次算是重構(gòu)了吧
做的最終結(jié)果還是和前一次一樣:
數(shù)據(jù)庫(kù)中的訂單數(shù)據(jù),是每時(shí)每刻都在增加
我們認(rèn)為3個(gè)月以內(nèi)的數(shù)據(jù),用戶會(huì)頻繁的操作,稱為熱數(shù)據(jù)
3個(gè)月以前的數(shù)據(jù),基本上不會(huì)有修改的地方了,查詢也是很少量的,我們稱為冷數(shù)據(jù)
所以將現(xiàn)有數(shù)據(jù)庫(kù)稱之為生產(chǎn)庫(kù),
然后再增加一個(gè)獨(dú)立的庫(kù),我們稱之為歷史庫(kù),
我們要做的就是生產(chǎn)庫(kù)中只放3個(gè)月內(nèi)的數(shù)據(jù),
歷史庫(kù)放所有的數(shù)據(jù),
查詢的時(shí)候,主查生產(chǎn)庫(kù),生產(chǎn)庫(kù)沒(méi)有,再考慮查詢歷史庫(kù),
生產(chǎn)庫(kù)提供所有的業(yè)務(wù)操作,
歷史庫(kù)只提供查詢功能,不提供其他業(yè)務(wù)功能,
2.前一次冷熱分離的思路
因?yàn)轫?xiàng)目在數(shù)據(jù)入庫(kù)的時(shí)候,業(yè)務(wù)需求,會(huì)發(fā)一個(gè)mq消息給其他下游,前一次的思路就是復(fù)用這個(gè)消息
讓我們的項(xiàng)目反過(guò)來(lái)再消費(fèi)這個(gè)消息,就可以異步獲得數(shù)據(jù)的變化情況,再將數(shù)據(jù)同步到歷史庫(kù)中
前一次冷熱分離的細(xì)節(jié),在這個(gè)文章里
正所謂 : 成也復(fù)用,敗也復(fù)用
上次做完后,當(dāng)時(shí)的效果也很好,確實(shí)冷熱分離了,生產(chǎn)庫(kù)的壓力也確實(shí)小了很多
但是復(fù)用帶來(lái)問(wèn)題馬上就暴露出來(lái)了:
項(xiàng)目設(shè)計(jì)到需求的變化,需要增加字段,并且原邏輯也有變化
這樣帶來(lái)的問(wèn)題是,做需求的時(shí)候,需要格外注意數(shù)據(jù)的同步,
尤其是一些狀態(tài)的變化,很容易造成生產(chǎn)庫(kù)改了,沒(méi)有同步到歷史庫(kù)中
久而久之,加上沒(méi)人專門維護(hù)這個(gè)歷史庫(kù),歷史庫(kù)的數(shù)據(jù)已經(jīng)亂的不成樣子
3.這一次冷熱分離的思路
有了上次的經(jīng)驗(yàn)教訓(xùn),這次就老實(shí)多了,直接使用binlog日志,
數(shù)據(jù)庫(kù)的每一次增加和修改操作,mysql開(kāi)啟binlog后,都能在binlog日志中記錄,
采用這一特性,通過(guò)數(shù)據(jù)庫(kù)級(jí)別的監(jiān)控,就不需要擔(dān)心業(yè)務(wù)上的變化帶來(lái)的不一致了,
只要生產(chǎn)庫(kù)的數(shù)據(jù)有變化,我們就可以根據(jù)binlog日志,直接將數(shù)據(jù)同步到歷史庫(kù)中
這一次冷熱分離的細(xì)節(jié),在這個(gè)文章里
總結(jié)
以上是生活随笔為你收集整理的[数据库]-----mysql数据的冷热分离 第二版的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: postman raw带文件_postm
- 下一篇: mysql多数据源_egg-mysql配