使用複製緩存vs LB粘性會話

Question

我需要將一些數據保存在服務器的緩存中。服務器處於羣集狀態，呼叫可以轉到其中的任何一個。在這種情況下，最好使用像EhCache這樣的複製/分佈式緩存或使用LB的會話粘性。

如果數據大小（在高速緩存中）很大，是不是會對所有服務器的序列化和反序列化產生性能影響？

此外，在分佈式緩存的情況下，這樣的緩存有效的最佳服務器數量是什麼。由於數據被複制到所有節點，並且節點數量是20，所以它的主節點可以在所有節點之間進行復制。我的意思是，每個節點都會收到其他19的通知，並將更新修改到其他19。

Answer 1

一如往常，在分佈式系統中，答案depands上不同的東西：

1. 與粘性會話負載均衡器可以肯定的是對於開發商的更簡單的方法，因爲它沒有，如果有什麼區別應用程序在1,2或100臺服務器上運行。如果這是你關心的一切，堅持下去，你就可以在這裏停止閱讀。

2. 我不確定會話感知負載平衡器是如何實現的，以及它們在每秒請求方面的一般限制是什麼，但它們與分佈式緩存至少有一個很大的缺點。 - 如果處理會話的機器停機，該怎麼辦？ - 如果您分配了緩存，則任何計算機都可以處理該請求，並且它們中的一個失敗並不重要。序列化/反序列化部分不是一個大問題，相反，如果您不在至少1 Gbit網絡環境中運行它，網絡可能會成爲瓶頸，但它應該沒問題。

   • 對於分佈式緩存，您可以使用Hazelcast，Infinispan或類似的解決方案，這將簡化您自己的應用程序的訪問。 （更新：這些實現使用DHT分發緩存）
   • 完全複製的緩存可以使用EhCached，您提到的或Infinispan。在這裏，分佈式緩存的優勢在於訪問速度快得多，因爲您可以在每臺機器上覆制所有數據，只需要在本地訪問它。缺點是寫入速度較慢（而非常頻繁地使用它，很少寫入情況），而且緩存受限於一臺機器能夠存儲的數量。如果您正在使用64GB內存的服務器上運行應用程序，則可以。如果你想分發它們在小型亞馬遜實例上，這可能是一個壞主意。我認爲在更新太多節點之前你會遇到任何問題，你會用完內存，而且這個問題至少很容易計算：AVG_CACHE_NEEDED_PER_CLIENT * NUMBER_OF_CLIENTS < MEMORY_FOR_CACHE_AVAILABLE (on one server)。如果您的EhCached羣集中的任何節點上都需要更多的緩存，則完全複製將不再可能。
   • 或者您可以使用Redis集羣或類似的獨立於您的應用程序和您的應用程序運行的服務器。這將允許您以不同於應用程序其餘部分的速度來調整緩存的大小，但是訪問數據不會那麼簡單。

當然實際的決定取決於你的非常具體的用例和你把你的應用需求。

就我個人而言，當我今天發現Azure WebPages有一個支持粘性會話的負載平衡器時，我非常高興，而且我不需要重新配置我的應用程序以使用Redis作爲會話對象存儲，並且可以保存所有內容就這樣。

但是，對於數百臺服務器的巨大工作負載，一個簡單的負載均衡器可能會相當不堪重負，而分佈式緩存或集中式複製緩存（Redis）將成爲未來之路。