快取失效竟然可以這麼解決？

資料傳輸提供的資料訂閱功能，可以在不影響業務的情況下，實現簡單、可靠的快取失效邏輯。這種快取失效機制為阿里巴巴多年架構最佳化沉澱下來的經驗，下面我們一起來看資料訂閱究竟怎麼實現這種機制。

傳統快取失效策略

為了提高業務訪問速度，提升業務讀併發，很多使用者都會在業務架構中引入快取層。業務所有讀請求全部路由到快取層，透過快取的記憶體讀取機制大大提升業務讀取效能。快取中的資料不能持久化 ，一旦快取異常退出，那麼記憶體中的資料就會丟失，所以為了保證資料完整，業務的更新資料會落地到持久化儲存中，例如DB。目前雲使用者的業務架構一般如下圖：

在上圖中，大家可以看到，使用者的更新資料直接持久化到DB, 業務讀請求直接請求快取資料，所以業務需要解決快取失效問題，即解決因為資料變更導致快取中的資料失效的問題。 目前業務解決快取失效問題的解決方法一般是業務實現DB、快取雙寫。透過業務雙寫解決快取失效，存在如下的問題：

1. 程式碼侵入性比較強，需要雙寫兩份儲存，任何對DB的資料變更，都需要同時更新快取，程式碼層面後期可維護程度不高
2. 使用者請求執行緒裡同步呼叫快取，對快取存在強以來，遇到快取超時等異常時，沒有辦法做到有效的重試，遇到異常給使用者返回系統錯誤、操作失敗等資訊，嚴重影響使用者體驗
3. 使用者請求執行緒裡同步完成DB、快取雙寫，變更請求鏈路長，訪問延遲大，影響使用者體驗

RDS資料訂閱消費，輕鬆解決快取失效

在阿里巴巴內部同樣也遇到了快取失效的問題，隨著業務架構得不斷調整最佳化，我們已經沉澱出一套高可靠、極優雅得快取失效架構。即透過資料傳輸提供的資料訂閱功能，非同步獲取DB（例如公共雲上的RDS）的增量資料，根據增量資料進行快取失效。具體的架構類似下圖：

在這個架構裡面，快取更新流程如下：

1. 業務完成DB更新後即返回請求
2. 資料訂閱透過日誌解析方式實時解析並訂閱DB的增量更新資料，當發現DB有資料更新時，將增量資料推送給下游消費者
3. 下游消費業務一旦接收到增量更新資料，即呼叫消費執行緒進行快取更新

至此完成整個快取更新過程。

從上面的快取失效流程，可以看出這種快取失效機制：

1. 更新路徑短，延遲低： 快取失效為非同步流程，業務更新DB完成後直接返回，不需要關心快取失效流程，整個更新路徑短，更新延遲低
2. 應用簡單可靠：應用無需實現複雜雙寫邏輯，只需啟動非同步執行緒監聽增量資料，更新快取資料即可
3. 應用更新無效能消耗：因為資料訂閱是透過解析DB的增量日誌來獲取增量資料，獲取資料的過程對業務、DB效能無損

小結

資料訂閱功能為阿里雲資料傳輸提供的一種資料分發方式。透過資料訂閱實現的快取失效策略，讓業務更新更快捷，讓業務邏輯更簡單、更可靠。

資料訂閱只是資料傳輸提供的一種傳輸方式，除資料訂閱之外，資料傳輸還提供了資料實時同步，不停服遷移等多種傳輸能力，如需瞭解資料傳輸更多詳情，請猛擊資料傳輸。