Windows Server AppFabric ASP.Net SessionState体系结构 [英] Windows Server AppFabric ASP.Net SessionState Architecture

问题描述

我们正在使用Windows Server AppFabric缓存设计解决方案，并希望将其用于在多服务器配置中缓存ASP.Net会话状态。

We are desiging a solution using Windows Server AppFabric Caching and would like to use it for caching ASP.Net Session state in a multi-server configuration.

我们有查看了MSDN及其他地方的所有文档，但我们无法找到以下某些架构问题的明确答案。如果我在这里错过了一些内容，请道歉。  

We have looked at all of the documentation on MSDN and elsewhere but we can't find explicit answers to some of the following architecture questions. Apologies if I have missed something here.  

1. 我们是否正确思考如果在非高可用性配置中，如果ASP.Net会话状态逻辑缓存和 ""条纹"  根据其他缓存类型在AppFabric群集中的多个缓存服务器内部，还是绑定到
   单个服务器？我们在MSDN中只看到了完整的工作示例，其中一个缓存主机服务器用于ASP.Net会话状态。对于这个内存缓存分布，ASP.Net会话状态是否存在于Appfabric集群中的预定模式
   （同样适用于所有服务器或首先是一台服务器）？这如何影响响​​应的延迟？
   
2. 如果ASP.Net会话状态缓存是"条带化"，会话状态完整性会发生什么？跨缓存主机和一个缓存服务器丢失并且未启用高可用性？ ASP.Net会话状态是否为所有服务器完全重建，或者为
   重新生成每个受损的会话/缓存主机？这是手动重建吗？
   
3. 我们希望使ASP.Net会话状态缓存既可扩展又具有弹性。对于给定的缓存配置，当有高可用性和辅助功能被启用时，是否有人尝试过ASP.Net会话状态Appfabric缓存？ 
   
4. 高可用性缓存复制的性能/处理效果以及主要和辅助缓存之间的确认顺序是否具有强一致性需求 使其不适合会话状态中的动态值
   低延迟访问需求 （其中会话不断创建，值更新并且每个用户会话都被销毁，因此缓存总是在更新？）
   
5. 这是正确的吗？在高可用性配置中，主副本始终接收读取，辅助副本仅用于恢复，或者是负载平衡的辅助部分并且可用于读取？
   
6. 在将辅助副本提升为主要副本之前，主要副本有多少短期单点故障？如何在此切换期间处理对会话状态的写入 - 它们是在某处缓冲还是丢失？
   

非常感谢任何帮助！

 

推荐答案

嗨罗杰，

我会按照上面的要求尝试回答你的问题：

I will try to give answer of your question as asked above:

 

1。 AppFabric缓存将数据存储在键值对中。整个"价值"给定密钥的部分数据驻留在一个服务器中，而不是条带化的。在ASP.Net会话状态的情况下，您的sesion id生成密钥，因此任何与一个会话ID关联的数据将在非HA方案中进入一个缓存服务器
。如果有HA，数据将被复制到辅助数据库。

1. AppFabric cache store data in a Key-value pair. The whole "Value" part of the data for a give key resides in one server and it is not striped. In case of ASP.Net session state, your sesion id makes the key so any data associated with one session id will go into one cache server in a Non HA scenario. If there is HA, the data will be copied to secondary aswell.

2。 N / A，因为它没有条纹

2. N/A as it is not striped

3。 HA是会话状态的支持和测试场景

3. HA is supported and tested scenario for Session state

4。 HA在写入期间有开销。一旦主要和次要写入，put / add调用将返回给用户。

4. HA has overhead of during write. The put/add call will return to user once both primary and secondary have bee written.

5。主要启动时，辅助数据无法读取。当相应的主节点突然下降时，从辅助节点读取，并且缓存服务器将现有的辅助节点推送到主节点（并且还创建另一个辅助节点）

5. Secondary data is not available for read when primary is up. The read from secondary happens, when corresponding primary node has down abruptly, and cache server promto the existing secondary to primary (and also create another secondary)

6。当主服务器发生故障（或任何节点发生故障）时，缓存服务器会尝试以1分钟的间隔对故障节点进行3次ping /检测。此设置目前不可配置。因此，在主要故障发生时将辅助级别升级为
主要课程大约需要3分钟

6. When primary goes down (or any node goes down) cache server tries to ping/detect the failed node 3 times in an interval of 1 minute. This setting currently non-configurable. As a result, it will take around 3 minutes before a secondary is promoted to primary when a primary failure happens

如果您有其他问题，请告诉我。

Let me know if you have further question.

谢谢，

Koushik

 

这篇关于Windows Server AppFabric ASP.Net SessionState体系结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！