服務經過緩存傳遞數據，毫不推薦

《服務經過緩存傳遞數據，是否可行》一文引起一個服務之間「經過緩存傳遞數據」設計合理性的討論。

如上圖：

• service-A將數據放入cache
• service-B從cache裏讀取數據

這種架構設計好仍是很差，網友進行了激烈的討論，感興趣的同窗能夠看下《服務經過緩存傳遞數據，是否可行》的評論，看到這麼多互聯網技術人對一個技術方案問題進行思考與探討，非常開心。這裏，分享下我的的觀點。

先說結論

樓主旗幟鮮明的反對「服務之間經過緩存傳遞數據」。

核心理由

1、數據管道場景，MQ比cache更加適合

若是隻是單純的將cache做爲兩個服務數據通信的管道，service-A生產數據，service-B（固然，可能有service-C/service-D等）訂閱數據，MQ比cache更加合適：

• MQ是互聯網常見的邏輯解耦，物理解耦組件，支持1對1，1對多各類模式，很是成熟的數據通道
  畫外音：詳見《MQ，互聯網架構解耦神器》
• 而cache反而會將service-A/B/C/D耦合在一塊兒，你們要彼此協同約定key的格式，ip地址等
• MQ可以支持push，而cache只能拉取，不實時，有時延
• MQ自然支持集羣，支持高可用，而cache未必
• MQ能支持數據落地，cache具有將數據存在內存裏，具備「易失」性，固然，有些cache支持落地，但互聯網技術選型的原則是，讓專業的軟件幹專業的事情：nginx作反向代理，db作固化，cache作緩存，mq作通道
  
  綜上，數據管道場景，MQ比cache更加適合。

2、數據共管場景，兩個(多個)service同時讀寫一個cache實例會致使耦合

若是不是數據管道，是兩個(多個)service對一個cache進行數據共管，同時讀寫，也是不推薦的，這些service會由於這個cache耦合在一塊兒：

• 你們要彼此協同約定key的格式，ip地址等，耦合
• 約定好同一個key，可能會產生數據覆蓋，致使數據不一致
• 不一樣服務業務模式，數據量，併發量不同，會由於一個cache相互影響，例如service-A數據量大，佔用了cache的絕大部份內存，會致使service-B的熱數據所有被擠出cache，致使cache失效；又例如service-A併發量高，佔用了cache的絕大部分鏈接，會致使service-B拿不到cache的鏈接，從而服務異常
  

綜上，數據共管場景，多個service耦合在一個cache實例裏，也是不推薦的，須要垂直拆分，實例解耦。

3、數據訪問場景，兩個(多個)service有讀寫一份數據的需求

根據服務化的原則，數據是私有的（本質也是解耦）：

• service層會向數據的需求方屏蔽下層存儲引擎，分庫，chace的複雜性
• 任何需求方不能繞過service讀寫其後端的數據
  

假設有其餘service要有數據獲取的需求，應該經過service提供的RPC接口來訪問，而不是直接讀寫後端的數據，不管是cache仍是db。

綜上

• 數據管道，MQ比cache更合適
• 多個服務不該該公用一個cache實例，應該垂直拆分解耦
• 服務化架構，不該該繞過service讀取其後端的cache/db，而應該經過RPC接口訪問

但願邏輯是清晰的，供大夥參考，歡迎不一樣的聲音共同探討。