使用复制缓存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）将成为未来之路。