為了提高業務通路速度，提升業務讀并發，很多使用者都會在業務架構中引入緩存層。業務所有讀請求全部路由到緩存層，通過緩存的記憶體讀取機制大大提升業務讀取性能。緩存中的資料不能持久化 ，一旦緩存異常退出，那麼記憶體中的資料就會丢失，是以為了保證資料完整，業務的更新資料會落地到持久化存儲中，例如db。目前雲使用者的業務架構一般如下圖：
在上圖中，大家可以看到，使用者的更新資料直接持久化到db, 業務讀請求直接請求緩存資料，是以業務需要解決緩存失效問題，即解決因為資料變更導緻緩存中的資料失效的問題。 目前業務解決緩存失效問題的解決方法一般是業務實作db、緩存雙寫。通過業務雙寫解決緩存失效，存在如下的問題：
（1）代碼侵入性比較強，需要雙寫兩份存儲，任何對db的資料變更，都需要同時更新緩存，代碼層面後期可維護程度不高
（2）使用者請求線程裡同步調用緩存，對緩存存在強依賴，遇到緩存逾時等異常時，沒有辦法做到有效的重試，遇到異常給使用者傳回系統錯誤、操作失敗等資訊，嚴重影響使用者體驗
（3）使用者請求線程裡同步完成db、緩存雙寫，變更請求鍊路長，通路延遲大，影響使用者體驗
在阿裡巴巴内部同樣也遇到了緩存失效的問題，随着業務架構得不斷調整優化，我們已經沉澱出一套高可靠、極優雅得緩存失效架構。即通過資料傳輸提供的資料訂閱功能，異步擷取db（例如公共雲上的rds）的增量資料，根據增量資料進行緩存失效。具體的架構類似下圖：
在這個架構裡面，緩存更新流程如下：
(1) 業務完成db更新後即傳回請求
(2) 資料訂閱通過日志解析方式實時解析并訂閱db的增量更新資料，當發現db有資料更新時，将增量資料推送給下遊消費者
(3) 下遊消費業務一旦接收到增量更新資料，即調用消費線程進行緩存更新
至此完成整個緩存更新過程。
從上面的緩存失效流程，可以看出這種緩存失效機制：
(1) 更新路徑短，延遲低： 緩存失效為異步流程，業務更新db完成後直接傳回，不需要關心緩存失效流程，整個更新路徑短，更新延遲低
(2) 應用簡單可靠：應用無需實作複雜雙寫邏輯，隻需啟動異步線程監聽增量資料，更新緩存資料即可
(3) 應用更新無性能消耗：因為資料訂閱是通過解析db的增量日志來擷取增量資料，擷取資料的過程對業務、db性能無損
資料訂閱功能為阿裡雲資料傳輸提供的一種資料分發方式。通過資料訂閱實作的緩存失效政策，讓業務更新更快捷，讓業務邏輯更簡單、更可靠。