azure - 使用哪个专用缓存配置？

Question

一个大型电子商务网站正在寻求将其会话缓存从共享缓存切换到专用缓存。

它通常运行在中型服务器（5-6 台）上……在繁忙时间，它运行在 20 台中型服务器上。在非常繁忙的时期，每秒向站点发送 2000 多个请求并非不合理

同位缓存在这里是否足够好，还是必须缓存在专用工作角色中？

此外，是否必须为会话数据启用高可用性？该站点依靠会话数据来提供良好的用户体验。但是缓存被持久化到 Azure blob 存储，所以我不确定我是否完全获得了高可用性选项

Answer 1

专用角色的使用取决于您要运行的角色数量，以及您的 Web 角色的内存使用量是否决定它们是否可扩展。例如，如果您的 Web 角色总是在推动内存使用，并且触发横向扩展的是内存而不是 CPU - 那么请考虑使用缓存的专用角色，因为您的 Web 角色可以处理更长时间的负载。如果您的 Web 角色是 CPU 密集型的，则可能首选将每个角色的内存专用于缓存。您还需要考虑，如果以专用角色运行，则需要多个角色来处理负载和可用性，因此即使在非繁忙时间，您也将至少有 3 个角色运行缓存（但可能更少的 Web 角色） .

同位角色缓存的一个考虑因素是，如果您有粘性会话，则延迟会更低，因为该项目位于同一台机器上。不幸的是，Azure 负载均衡器是循环的，根本没有粘性，所以会话回到同一台机器的机会很低（5 个角色的时间的 1/5）。这意味着大部分时间缓存项将从集群中的另一个角色获取，因此失去了协同定位的延迟优势。

缓存是分布式的并且在内存中 - 没有我知道的 blob 存储（“集群的运行时状态”除外 - 不管是什么。加载到缓存中的项目可从集群上的其他机器使用它存储（在内存中）（从机器 B 到机器 A 的读取不会将其存储在机器 A 上 - 请参见下面的注释）。缓存项始终仅在内存中，并且缓存大小受可用内存的限制。

高可用性选项将项目复制到单独的机器（而不是存储），因此如果一台机器发生故障，则在某处仍有副本。高可用性还将使用更多内存，因为一个项目在两个不同的地方使用内存。对于您的电子商务应用程序而言，失败的可能性可能足够低 - 如果一个项目没有被缓存（通过失败或过期），它可能会从持久数据中重建。例如，如果您将篮子保存在缓存中而不是持久化到存储中，那么您不希望在角色回收时丢失它 - 在这种情况下，高可用性可能是最佳选择。

Answer 2

很好的答案@SimonMunro 但是根据我的经验，Azure Co-located Cache 不适合生产。我们的负载测试表明，当服务器被回收时，缓存需要非常长的时间才能恢复。我们已经通过从我们的数据库中获取数据来对此进行编码，但是由于数据库的压力，我们的网站停止了。这不仅发生在节点被回收时；而且如果你向上和向下扩展你的云服务；甚至当您执行 VIP 交换时。

我们使用 Azure 专用缓存执行了相同的测试，发现它可以处理缓存辅助角色回收的情况，对站点性能几乎没有影响。 如果您希望您的站点执行，我的建议是在所有情况下都使用 Azure 专用缓存。