突然覺得緩存如果單獨(dú)搞一套服務(wù)出來，那不是每次寫代碼都要業(yè)務(wù)的寫一遍，緩存的也寫一遍??？

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

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

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

這個(gè)過程是不可行的，會(huì)導(dǎo)致大量的溝通成本，而且在大團(tuán)隊(duì)協(xié)作里會(huì)導(dǎo)致經(jīng)常容易出問題

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

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

要不是打造這樣的服務(wù)閉環(huán)，會(huì)導(dǎo)致你做商品詳情頁(yè)的復(fù)雜緩存架構(gòu)，幾乎沒法做，每次有一點(diǎn)變動(dòng)就要找：商品服務(wù)、價(jià)格服務(wù)、庫(kù)存服務(wù)、推薦服務(wù)、評(píng)論服務(wù)、會(huì)員服務(wù)、促銷服務(wù)，等等各個(gè)方向的人開會(huì)，幾乎會(huì)把自己搞死