1

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

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

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

回答

0

一如往常,在分佈式系統中,答案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)將成爲未來之路。

+0

感謝Zahorak的回覆。但我的問題是圍繞複製緩存而不是分佈式緩存。我認爲與分佈式緩存相比,複製的緩存不會有太大的擴展。如你所說,更好的方法是使用LB粘性會話或分佈式緩存。 – 2014-08-30 04:54:55

+0

基本上EhCache,Hazelcast和Infinispan正在嘗試解決類似的問題,不同之處在於EhCache通過完全複製(如你所寫)來完成它,而Hazelcast有一個DHT。 Infinispan支持這兩種實現。對於完全複製緩存的限制可以很容易地通過一個對象的大小以及您在計算機上有多少可用空間來計算,因爲添加新計算機不會使緩存更快。我已經更新了我的回答。 – peter 2014-08-30 08:34:11

+0

我不認爲eh緩存必須被複制。這是一個配置。可以選擇具有相互複製冗餘的節點集合,以及具有不同配置的ID標識的不同「緩存」。所以可以保留一些被複制的信息和其他不是的信息。決定複製什麼以及不依賴於信息和業務需求的大小 – tgkprog 2014-09-08 12:12:50