@平常 我看有的架構是直接通過canel訂閱binlog，消費 如果訂閱的商品數(shù)據(jù)有變動直接可以消費到，在寫入緩存中去

@平常 說得太好了，一看老師就是做過大系統(tǒng)的人

同學，你可能沒理解這個業(yè)務的背景。如果只是面向c端的最普通的那種緩存架構，確實就是你說的那種，每個服務自己寫緩存。但是如果是電商的商品詳情頁的系統(tǒng)架構，是要緩存一整個商品詳情頁的，涉及可能幾十個服務的數(shù)據(jù)，如果每個服務都自己胡亂寫緩存，那么緩存的控制權就放在幾十個服務的負責人那里。那么負責商品詳情頁系統(tǒng)的同學，就要一個一個溝通緩存格式、后續(xù)的變動、新加一個緩存數(shù)據(jù)、等等吧，然后商品詳情頁系統(tǒng)從redis里獲取幾十個服務零散寫入的數(shù)據(jù)，整合起來，給商品詳情頁提供出去。

這個過程是不可行的，會導致大量的溝通成本，而且在大團隊協(xié)作里會導致經(jīng)常容易出問題

你依賴的某個服務，可能來個新同學，自己沒事兒把某個寫緩存的代碼給刪了，你都不知道

所以才要打造所謂的服務閉環(huán)，就是說，幾十個服務，自己不寫緩存，有數(shù)據(jù)變動，發(fā)個消息到MQ，自己就不管了。然后你開發(fā)一個商品詳情頁系統(tǒng)，監(jiān)聽MQ，從各個服務拉取他們變動的數(shù)據(jù)，如何存緩存？什么格式？要怎么存？用什么架構？多級緩存怎么玩兒？怎么做緩存降級？全都在你一個人的掌控之中，打造了一個閉環(huán)。就是說商品詳情頁涉及到的各種數(shù)據(jù)的緩存，你完全可控。

要不是打造這樣的服務閉環(huán)，會導致你做商品詳情頁的復雜緩存架構，幾乎沒法做，每次有一點變動就要找：商品服務、價格服務、庫存服務、推薦服務、評論服務、會員服務、促銷服務，等等各個方向的人開會，幾乎會把自己搞死