將緩存作爲服務提供是個好主意嗎？

我們有很多具有緩存需求的Web服務和Web應用程序應用程序，所以我們試圖提出可以幫助所有團隊的緩存策略，而不管他們的技術選擇如何。我們已經使用Memcached（未複製）& Couchbase（多主設備）在每個服務器節點上本地運行，應用程序使用Memcached協議在本地連接到它們，但未來我們計劃使用通過REST API公開的集中式緩存集羣，可以使用所有在數據中心不同服務器節點上運行的應用程序。以下是思考過程背後的原因：將緩存作爲服務提供是個好主意嗎？

羣集易於維護，無需擔心應用服務器節點。
單協議（HTTP）使用，而無需擔心約底層實現訪問緩存。（我們可能會使用Redis的或Couchbase或塞式集羣）

但我們不知道這個策略，因爲我們擔心關於由於HTTP造成的網絡開銷而導致的性能影響。

有沒有人試過這個策略？將緩存設置爲集中服務還是本地緩存最好？

來源

2015-04-22 ThinkFloyd

儘管HTTP和網絡添加延遲的確是事實，但通常您需要緩存，因爲實際操作需要更長的時間。所以問題是：如果您將1-2毫秒添加到緩存訪問，那麼是否仍會顯着縮短未緩存的操作時間？如果答案是肯定的，並且您遵循一些常見的最佳做法，那麼擁有集中式緩存可能是個好主意。

您可能需要研究HTTP服務的低延遲，高吞吐量服務器端框架，如Node.js或Go。此外，您可能會受益於在緩存HTTP API中實施適當的ETag支持。

另一種選擇可能是集中緩存服務器而不將它們包裝在HTTP層中。對於大多數現代Web框架提供的所有技術，都有標準的緩存提供程序實現。

來源

2015-04-22 09:21:24

大衛，你的意思是說，如果我溝通HTTP並使用他們的專有協議連接到遠程集羣，它會提供更好的性能？ – ThinkFloyd

增加的性能不一定與正在使用的協議相關（儘管通常二進制協議（如Memcached）比基於文本的協議提供更小的開銷和更快的處理時間），而是因爲您正在消除中間人 - HTTP網關 - 通常運行在不同的進程中，並通過某種套接字/ IPC與實際的緩存進行通信。 –

免責聲明：我爲Redis Labs工作，Redis Labs是一家制作用於管理Redis和Memcached集羣的工具的商業公司。我的僱主Redis實驗室已經開展了一項您想要確認的策略的業務:)

緩存是一種最好的服務，但遠程緩存有好處（例如，卸載數據庫），即使延遲代價不同。在大多數情況下，與在應用程序中花費的時間相比，局域網延遲變得可以忽略不計，因此使用共享的網絡連接緩存很有意義。

爲了獲得最佳性能，請使用其自己的協議直接與應用程序交互使用共享緩存。除非由緩存引擎本身提供，否則HTTP API可能會延遲客戶端應用程序的請求。 OTOH通過自定義層（比如REST API）正式確定您的應用程序對緩存的訪問權限，也有很多好處，因此您應該根據延遲預算評估成本。

您的策略是合理的，它在任何地方都可用來構建可擴展的高性能應用程序。如果您需要進一步的建議，請隨時打我。

來源

2015-04-22 13:06:08

將緩存作爲服務提供是個好主意嗎？

回答

相關問題