阿里終面:業務主表讀寫緩慢如何最佳化?

ITPUB社群發表於2022-11-30

無論多麼複雜的業務場景,一條資料的一生都體現在CRUD操作上,正是建立查詢修改刪除。正如人的生死輪迴,資料亦是如此,一條資料隨著時間的流逝,其價值也是在逐漸變小。

資料存在的價值則是在於它被使用的程度,在不同的系統中,人們對於不同時期的資料有著不同的需求。

比如12306攜程上的火車、機票訂單,人們往往只關注30天之內的訂單,而攜程正是預設只保留30天的訂單資訊,超過30天的訂單需要透過手機號查詢。

阿里終面:業務主表讀寫緩慢如何最佳化?

攜程為什麼要這麼做?

其實仔細想想不難明白,作為全國購票平臺,每年數以億計的訂單,如果全部能夠開放操作(CRUD),那麼系統將會瞬間崩潰

一個訂單走到終態的標誌則是這筆訂單的完成,也就意味著這筆訂單除了查詢的需求,不再任由使用者修改、刪除。

其實攜程所用的架構方法正是:冷熱分離

什麼是冷熱分離?

冷熱分離則是在處理資料時將資料庫分為熱庫冷庫兩個庫。冷庫存放的是走到終態的資料,熱庫存放的是還需要修改的資料。

比如30天之內的機票、火車票訂單,使用者可能需要對這期間的訂單做出退票開發票的操作,但是30天之前訂單卻只有查詢的需求,因此可以將30天之內的訂單放到熱庫中,之前的訂單存放到冷庫中。

那麼這裡又引出了兩個概念,分別是:

  • 熱資料:被頻繁更新;響應時間有要求

  • 冷資料:不允許更新(具體業務系統具體分析),偶爾被查詢;響應時間無要求。

什麼情況下需要使用冷熱分離?

在大型的網際網路系統中,如果出現了以下場景則應該考慮冷熱分離:

  1. 主業務響應延遲太大,比如12306下訂單太慢了。
  2. 資料走到終態後,沒有更新需求,只有讀的需求,比如訂單的完成狀態。
  3. 使用者能夠接受新舊資料分開查詢,比如攜程的訂單查詢30天之前的需要用手機號查詢。

補充:當然現在有些系統不像攜程那樣將往期訂單分開查詢,但是其實內部也是做了冷熱分離,只不過是在你無感知的情況下完成的。

如何判斷一個資料是冷資料還是熱資料?

這個就要根據自己業務系統來區分了,一般而言是根據主表中的一個或者多個欄位進行標識區分,比如訂單的時間,這個是時間維度,可以將3個月之前的資料定義為冷資料,最近3個月的資料定義為熱資料。

當然也可以是狀態維度,比如訂單的狀態,已完結的訂單定義為冷資料,未完結的訂單定義為熱資料。

同樣的也可以將時間維度和狀態維度組合起來,比如下單時間大於3個月且訂單狀態為已完結的定義為冷資料,反則為熱資料。

總之:根據自己業務需求,具體問題具體分析。

但是需要注意以下兩點:

  1. 如果一個資料被標識為冷資料,業務程式碼不會再對它進行寫操作
  2. 不會同時存在讀冷/熱資料的需求。

如何實現冷熱資料分離?

一切的理論知識都要經過實戰的檢驗,基礎知識瞭解了,那麼如何實現冷熱資料的分離呢?下面介紹三種常見的方法。

1、業務程式碼修改

這種方案是直接修改業務程式碼,對程式碼的侵入性比較高,無法按照時間進行區分,在資料修改時觸發冷熱分離。

阿里終面:業務主表讀寫緩慢如何最佳化?

該種方案需要在業務程式碼層面判斷是否需要冷熱分離,比如訂單的狀態修改,一旦狀態為終態則將這條資料標記為冷資料,然後觸發冷熱處理,將其寫入冷庫,同時刪除熱庫中的這筆資料。

2、監聽資料庫日誌

該種方案需要監聽binlog日誌的方式進行觸發,比如訂單狀態修改了,則觸發冷熱分離。

同樣的這裡無法按照時間區分但是對程式碼無侵入

監聽binlog日誌的工具有很多,前面介紹過,比如阿里的canal,還有其他的開源中介軟體可供選擇,如下:

阿里終面:業務主表讀寫緩慢如何最佳化?

對於MySQL資料庫建議選擇canal,使用方式看:實戰!Spring Boot 整合 阿里開源中介軟體 Canal 實現資料增量同步!

整個流程如下圖:

阿里終面:業務主表讀寫緩慢如何最佳化?

3、定時任務掃描

該種方案可以按照時間區分,與業務程式碼解耦,是個不錯的選擇。

流程如下:

阿里終面:業務主表讀寫緩慢如何最佳化?

總結

解決讀寫緩慢的問題冷熱分離是個不錯的選擇,上述介紹了三種方案實現冷熱分離,雖說都能實現,但是仍然要考慮諸多問題,最棘手的問題就是資料一致性的問題。

在冷熱分離的處理邏輯中一定要保證熱庫、冷庫中的資料一致性問題,手段很多,這裡就不再過多介紹了。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024420/viewspace-2925898/,如需轉載,請註明出處,否則將追究法律責任。

相關文章