使用复制缓存与LB粘性会话

Question

我需要在服务器上的缓存中保留一些数据。服务器在群集中，呼叫可以转到其中任何一个。在这种情况下，最好使用像EhCache Or这样的复制/分布式缓存来使用LB的会话粘性。

如果数据大小（缓存中）很大，那么它是否会对所有服务器的序列化和反序列化产生性能影响？

同样在分布式缓存的情况下，最高数量的服务器是什么，这样的缓存才有效。由于数据被复制到所有节点，并且节点数量为20，因此它类似于主节点以跨所有节点进行复制。我的意思是，每个节点都会收到来自其他节点的通知，并会更新其他19.这种类型的操作系统设置规模吗？

Answer 1

与分布式系统一样，答案不同：

1. 具有粘性会话的负载均衡器对于开发人员来说肯定是更简单的方式，因为如果应用程序在1,2或100台服务器上运行它没有任何区别。如果这就是你所关心的，坚持下去就可以在这里停止阅读。

2. 我不确定如何实现会话感知负载均衡器以及它们在每秒请求数方面的一般限制，但它们至少比分布式缓存有一个很大的缺点。 - 如果处理会话的机器出现故障怎么办？ - 如果您分发了缓存，任何计算机都可以为请求提供服务，如果其中一个失败则无关紧要。序列化/反序列化部分不是一个大问题，如果您不在至少1 Gbit网络环境中运行它，网络可能成为瓶颈，但它应该没问题。

   • 对于分布式缓存，您可以使用Hazelcast，Infinispan或类似的解决方案，这将简化您自己的应用程序的访问。 （更新：这些实现使用DHT来分发缓存）
   • 完全复制的缓存，您可以使用您提到的EhCached或Infinispan。在这里，分布式缓存的优势是访问速度更快，因为您可以在每台计算机上复制所有数据，并且只需要在本地访问它。缺点是写入速度较慢（因此非常经常使用它进行读取，编写非常少的情况）以及缓存受一台机器能够存储的数量限制的事实。如果您在具有64GB RAM的服务器上运行应用程序，这是可以的。如果你想在小亚马逊实例上分发它们，这可能是一个坏主意。我认为在您更新太多节点之前遇到任何问题之前，您将耗尽内存，并且至少非常容易计算：AVG_CACHE_NEEDED_PER_CLIENT * NUMBER_OF_CLIENTS < MEMORY_FOR_CACHE_AVAILABLE (on one server)。如果您需要的缓存超过EhCached群集中任何节点上的缓存，则无法再进行完全复制。
   • 或者您可以使用Redis群集或类似的独立于您的应用程序和运行您的应用程序的服务器。这将允许您以与应用程序其余部分不同的速度扩展缓存，但是访问数据并不是那么简单。

当然，实际的决定取决于您的具体用例以及您对应用程序的要求。

我个人非常高兴今天发现Azure WebPages有一个带有粘性会话支持的负载均衡器，而且我不需要重新配置我的应用程序以将Redis用作会话对象存储，并且可以将所有内容保留为它是。

但是对于拥有数百台服务器的巨大工作负载而言，简单的负载均衡器可能会相当不堪重负，分布式缓存或集中式复制缓存（Redis）将是最佳选择。