一家大型电子商务网站正在寻求将其会话缓存从共享缓存切换到专用缓存。
它通常在中型服务器（5-6 台）上运行...在繁忙时间，它在 20 台中型服务器上运行。在非常繁忙的时候，每秒有 2000 多个请求到站点并不是不合理的
在这里共存缓存是否足够好，还是必须缓存在专用工作角色中？
另外，是否必须为会话数据启用高可用性？该站点依靠会话数据来提供良好的用户体验。但是缓存被持久化到 Azure blob 存储，所以我不确定我是否完全获得了高可用性选项
【问题讨论】：
标签： azure azure-caching
专用角色的使用取决于您要运行的角色数量，以及您的 Web 角色的内存使用量是否决定了它们是否可扩展。例如，如果您的 Web 角色一直在推动内存使用，并且触发横向扩展的是内存而不是 CPU - 那么请考虑使用缓存的专用角色，因为您的 Web 角色可以处理更长时间的负载。如果您的 Web 角色是 CPU 密集型的，则可能首选将每个角色上的内存专用于缓存。您还需要考虑，如果以专用角色运行，则需要多个角色来处理负载和可用性，因此即使在非繁忙时间，您也将至少有 3 个角色运行缓存（但可能更少的 Web 角色） .如果您进行大量部署或缩小规模，您可能还希望使用专用缓存 - 其中角色被有意且频繁地关闭。
关于并置角色缓存的一个考虑因素是，如果您有粘性会话，则延迟会更低，因为该项目位于同一台机器上。不幸的是，Azure 负载均衡器是循环的，根本没有粘性，所以会话回到同一台机器的机会很低（5 个角色的时间的 1/5）。这意味着大部分时间缓存项将从集群中的另一个角色获取，因此失去了协同定位的延迟优势。
缓存是分布式的并且在内存中 - 我知道没有 blob 存储（“集群的运行时状态”除外 - 不管是什么。加载到缓存中的项目可用于集群上的其他机器它存储（在内存中）的机器（从机器 B 到机器 A 的读取不会也将其存储在机器 A 上 - 请参见下面的注释）。缓存项目始终仅在内存中，并且缓存大小受可用的限制记忆。
高可用性选项将项目复制到单独的机器（而不是存储），因此如果一台机器发生故障，在某处仍有副本。高可用性还将使用更多内存，因为一个项目在两个不同的地方使用内存。对于您的电子商务应用程序而言，失败的可能性可能足够低 - 如果一个项目没有被缓存（通过失败或过期），它可能会从持久数据中重建。例如，如果您将篮子保存在缓存中而不是持久化到存储中，那么您不希望在角色回收时丢失它 - 在这种情况下，高可用性可能是最佳选择。
【讨论】：
@SimonMunro 的答案很好，但是根据我的经验，Azure Co-located Cache 不适合生产。我们的负载测试表明，当服务器被回收时，缓存需要非常长的时间才能恢复。我们已经通过从我们的数据库中获取数据来对此进行编码，但是由于数据库的压力，我们的网站停止了。这不仅发生在节点被回收时；而且如果你向上和向下扩展你的云服务；甚至当你执行 VIP 交换时。
我们使用 Azure 专用缓存执行了相同的测试，发现它可以处理缓存辅助角色回收的情况，对站点性能几乎没有影响。 如果您希望网站正常运行，我的建议是在所有情况下都使用 Azure 专用缓存。
【讨论】：