在ASP.NET网站中使用状态服务器时如何避免单点故障
在我当前的项目中，我们必须创建一个网站（ASP.NET MVC），该网站可能有足够的负载来需要服务器场。 据我所知，如果使用服务器群，会话状态必须存储在其他地方，例如 SQL Server 数据库或状态服务器。
经过一番实验，我们倾向于使用状态服务器机制，但它会出现单点故障，这让我感到紧张。 在使用状态服务器时，有什么方法可以避免“单点故障”吗？
In my current project, we have to create a website (ASP.NET MVC) which is likely to have sufficient load to demand a server farm. I understand that if server farm is used, session states must be stored on somewhere else such as SQL server database or state server.
After some experimentation, we are inclined to use the state server mechanism but the fact that it will have single point of failure, makes me nervous. Is there any method by which we can avoid "single point of failure" when using state server?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有一种叫做会话状态分区的东西您可以使用，以避免
单点故障。 如果这仍然不适合您，那么您可以考虑尝试 ASP.NET Velocity 项目，尽管仅处于 CTP 阶段，但看起来很有前途。如果您想要完全的可扩展性和冗余，那么您可能应该使用 SQL Server 集群。
There is something called session state partitioning that you could use, in order to avoid a
single point of failure. If this still doesn't suit you, then you might consider trying the ASP.NET Velocity project, which it looks promising even though it is in CTP stage only.If you want full scalability and redundancy, then you should probably use a SQL Server Cluster.
共享缓存（http://www.sharedcache.com 或 http://sharedcache.codeplex.com) 有一个会话实现，到目前为止尚未发布，但人们正在使用它。
sharedcache (http://www.sharedcache.com or http://sharedcache.codeplex.com) has an implementation for sessions, it's not released so far but people are using it.
您可以将 SQL Server 复制设置到另一台计算机或使用故障转移群集。这可能会很昂贵，但会让你的数据库组件更加健壮。
从技术上讲，你的 Web 服务器机房以及你的网络等都是单点故障。我不一定会对会话更加紧张状态比任何一个都重要。
You could set up SQL Server replication to another machine or use a failover cluster.This could potentially be expensive but would make your database component more robust.
Technically, your web server equipment room is a single point of failure, as well as your network, etc. I wouldn't necessarily be more nervous about session state than any of those.