數據傳輸提供的數據訂閱功能，可以在不影響業務的情況下，實現簡單、可靠的緩存失效邏輯。這種緩存失效機制為阿裡巴巴多年架構優化沉澱下來的經驗，下面我們一起來看數據訂閱究竟怎麼實現這種機制。
傳統緩存失效策略
為了提高業務訪問速度，提升業務讀並發，很多用戶都會在業務架構中引入緩存層。業務所有讀請求全部路由到緩存層，通過緩存的內存讀取機制大大提升業務讀取性能。緩存中的數據不能持久化 ，一旦緩存異常退出，那麼內存中的數據就會丟失，所以為了保證數據完整，業務的更新數據會落地到持久化存儲中，例如DB。目前雲用戶的業務架構一般如下圖：
在上圖中，大家可以看到，用戶的更新數據直接持久化到DB, 業務讀請求直接請求緩存數據，所以業務需要解決緩存失效問題，即解決因為數據變更導致緩存中的數據失效的問題。 目前業務解決緩存失效問題的解決方法一般是業務實現DB、緩存雙寫。通過業務雙寫解決緩存失效，存在如下的問題：
代碼侵入性比較強，需要雙寫兩份存儲，任何對DB的數據變更，都需要同時更新緩存，代碼層面後期可維護程度不高
用戶請求線程裡同步調用緩存，對緩存存在強以來，遇到緩存超時等異常時，沒有辦法做到有效的重試，遇到異常給用戶返回系統錯誤、操作失敗等信息，嚴重影響用戶體驗
用戶請求線程裡同步完成DB、緩存雙寫，變更請求鏈路長，訪問延遲大，影響用戶體驗
RDS數據訂閱消費，輕松解決緩存失效
在阿裡巴巴內部同樣也遇到了緩存失效的問題，隨著業務架構得不斷調整優化，我們已經沉澱出一套高可靠、極優雅得緩存失效架構。即通過數據傳輸提供的數據訂閱功能，異步獲取DB（例如公共雲上的RDS）的增量數據，根據增量數據進行緩存失效。具體的架構類似下圖：
在這個架構裡面，緩存更新流程如下：
業務完成DB更新後即返回請求
數據訂閱通過日志解析方式實時解析並訂閱DB的增量更新數據，當發現DB有數據更新時，將增量數據推送給下游消費者
下游消費業務一旦接收到增量更新數據，即調用消費線程進行緩存更新
至此完成整個緩存更新過程。
從上面的緩存失效流程，可以看出這種緩存失效機制：
更新路徑短，延遲低： 緩存失效為異步流程，業務更新DB完成後直接返回，不需要關心緩存失效流程，整個更新路徑短，更新延遲低
應用簡單可靠：應用無需實現復雜雙寫邏輯，只需啟動異步線程監聽增量數據，更新緩存數據即可
應用更新無性能消耗：因為數據訂閱是通過解析DB的增量日志來獲取增量數據，獲取數據的過程對業務、DB性能無損
小結
數據訂閱功能為阿裡雲數據傳輸提供的一種數據分發方式。通過數據訂閱實現的緩存失效策略，讓業務更新更快捷，讓業務邏輯更簡單、更可靠。
數據訂閱只是數據傳輸提供的一種傳輸方式，除數據訂閱之外，數據傳輸還提供了數據實時同步，不停服遷移等多種傳輸能力，如需了解數據傳輸更多詳情，請猛擊數據傳輸。
