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