阿里終面:業(yè)務(wù)主表讀寫(xiě)緩慢如何優(yōu)化?
大家好,我是不才陳某~
無(wú)論多么復(fù)雜的業(yè)務(wù)場(chǎng)景,一條數(shù)據(jù)的一生都體現(xiàn)在CRUD操作上,正是創(chuàng)建、查詢、修改、刪除。正如人的生死輪回,數(shù)據(jù)亦是如此,一條數(shù)據(jù)隨著時(shí)間的流逝,其價(jià)值也是在逐漸變小。
數(shù)據(jù)存在的價(jià)值則是在于它被使用的程度,在不同的系統(tǒng)中,人們對(duì)于不同時(shí)期的數(shù)據(jù)有著不同的需求。
比如12306、攜程上的火車、機(jī)票訂單,人們往往只關(guān)注30天之內(nèi)的訂單,而攜程正是默認(rèn)只保留30天的訂單信息,超過(guò)30天的訂單需要通過(guò)手機(jī)號(hào)查找。
攜程訂單
攜程為什么要這么做?
其實(shí)仔細(xì)想想不難明白,作為全國(guó)購(gòu)票平臺(tái),每年數(shù)以億計(jì)的訂單,如果全部能夠開(kāi)放操作(CRUD),那么系統(tǒng)將會(huì)瞬間崩潰。
一個(gè)訂單走到終態(tài)的標(biāo)志則是這筆訂單的完成,也就意味著這筆訂單除了查詢的需求,不再任由用戶修改、刪除。
其實(shí)攜程所用的架構(gòu)方法正是:冷熱分離。
什么是冷熱分離?
冷熱分離則是在處理數(shù)據(jù)時(shí)將數(shù)據(jù)庫(kù)分為熱庫(kù)和冷庫(kù)兩個(gè)庫(kù)。冷庫(kù)存放的是走到終態(tài)的數(shù)據(jù),熱庫(kù)存放的是還需要修改的數(shù)據(jù)。
比如30天之內(nèi)的機(jī)票、火車票訂單,用戶可能需要對(duì)這期間的訂單做出退票、開(kāi)發(fā)票的操作,但是30天之前訂單卻只有查詢的需求,因此可以將30天之內(nèi)的訂單放到熱庫(kù)中,之前的訂單存放到冷庫(kù)中。
那么這里又引出了兩個(gè)概念,分別是:
- 熱數(shù)據(jù):被頻繁更新;響應(yīng)時(shí)間有要求
- 冷數(shù)據(jù):不允許更新(具體業(yè)務(wù)系統(tǒng)具體分析),偶爾被查詢;響應(yīng)時(shí)間無(wú)要求。
什么情況下需要使用冷熱分離?
在大型的互聯(lián)網(wǎng)系統(tǒng)中,如果出現(xiàn)了以下場(chǎng)景則應(yīng)該考慮冷熱分離:
- 主業(yè)務(wù)響應(yīng)延遲太大,比如12306下訂單太慢了。
- 數(shù)據(jù)走到終態(tài)后,沒(méi)有更新需求,只有讀的需求,比如訂單的完成狀態(tài)。
- 用戶能夠接受新舊數(shù)據(jù)分開(kāi)查詢,比如攜程的訂單查詢30天之前的需要用手機(jī)號(hào)查詢。
補(bǔ)充:當(dāng)然現(xiàn)在有些系統(tǒng)不像攜程那樣將往期訂單分開(kāi)查詢,但是其實(shí)內(nèi)部也是做了冷熱分離,只不過(guò)是在你無(wú)感知的情況下完成的。
如何判斷一個(gè)數(shù)據(jù)是冷數(shù)據(jù)還是熱數(shù)據(jù)?
這個(gè)就要根據(jù)自己業(yè)務(wù)系統(tǒng)來(lái)區(qū)分了,一般而言是根據(jù)主表中的一個(gè)或者多個(gè)字段進(jìn)行標(biāo)識(shí)區(qū)分,比如訂單的時(shí)間,這個(gè)是時(shí)間維度,可以將3個(gè)月之前的數(shù)據(jù)定義為冷數(shù)據(jù),最近3個(gè)月的數(shù)據(jù)定義為熱數(shù)據(jù)。
當(dāng)然也可以是狀態(tài)維度,比如訂單的狀態(tài),已完結(jié)的訂單定義為冷數(shù)據(jù),未完結(jié)的訂單定義為熱數(shù)據(jù)。
同樣的也可以將時(shí)間維度和狀態(tài)維度組合起來(lái),比如下單時(shí)間大于3個(gè)月且訂單狀態(tài)為已完結(jié)的定義為冷數(shù)據(jù),反則為熱數(shù)據(jù)。
總之:根據(jù)自己業(yè)務(wù)需求,具體問(wèn)題具體分析。
但是需要注意以下兩點(diǎn):
- 如果一個(gè)數(shù)據(jù)被標(biāo)識(shí)為冷數(shù)據(jù),業(yè)務(wù)代碼不會(huì)再對(duì)它進(jìn)行寫(xiě)操作
- 不會(huì)同時(shí)存在讀冷/熱數(shù)據(jù)的需求。
如何實(shí)現(xiàn)冷熱數(shù)據(jù)分離?
一切的理論知識(shí)都要經(jīng)過(guò)實(shí)戰(zhàn)的檢驗(yàn),基礎(chǔ)知識(shí)了解了,那么如何實(shí)現(xiàn)冷熱數(shù)據(jù)的分離呢?下面介紹三種常見(jiàn)的方法。
1、業(yè)務(wù)代碼修改
這種方案是直接修改業(yè)務(wù)代碼,對(duì)代碼的侵入性比較高,無(wú)法按照時(shí)間進(jìn)行區(qū)分,在數(shù)據(jù)修改時(shí)觸發(fā)冷熱分離。
圖片
該種方案需要在業(yè)務(wù)代碼層面判斷是否需要冷熱分離,比如訂單的狀態(tài)修改,一旦狀態(tài)為終態(tài)則將這條數(shù)據(jù)標(biāo)記為冷數(shù)據(jù),然后觸發(fā)冷熱處理,將其寫(xiě)入冷庫(kù),同時(shí)刪除熱庫(kù)中的這筆數(shù)據(jù)。
2、監(jiān)聽(tīng)數(shù)據(jù)庫(kù)日志
該種方案需要監(jiān)聽(tīng)binlog日志的方式進(jìn)行觸發(fā),比如訂單狀態(tài)修改了,則觸發(fā)冷熱分離。
同樣的這里無(wú)法按照時(shí)間區(qū)分,但是對(duì)代碼無(wú)侵入。
監(jiān)聽(tīng)binlog日志的工具有很多,前面介紹過(guò),比如阿里的canal,還有其他的開(kāi)源中間件可供選擇,如下:
圖片
對(duì)于MySQL數(shù)據(jù)庫(kù)建議選擇canal,使用方式看:實(shí)戰(zhàn)!Spring Boot 整合 阿里開(kāi)源中間件 Canal 實(shí)現(xiàn)數(shù)據(jù)增量同步!
整個(gè)流程如下圖:
圖片
3、定時(shí)任務(wù)掃描
該種方案可以按照時(shí)間區(qū)分,與業(yè)務(wù)代碼解耦,是個(gè)不錯(cuò)的選擇。
流程如下:
圖片
總結(jié)
解決讀寫(xiě)緩慢的問(wèn)題冷熱分離是個(gè)不錯(cuò)的選擇,上述介紹了三種方案實(shí)現(xiàn)冷熱分離,雖說(shuō)都能實(shí)現(xiàn),但是仍然要考慮諸多問(wèn)題,最棘手的問(wèn)題就是數(shù)據(jù)一致性的問(wèn)題。
在冷熱分離的處理邏輯中一定要保證熱庫(kù)、冷庫(kù)中的數(shù)據(jù)一致性問(wèn)題,手段很多,這里就不再過(guò)多介紹了。