ASP.NET MVC 会话状态使用状态分区、MongoDB 或 Memcached 或...？
我的团队目前正在为我们公司 (Amilia.com) 构建新的 SaaS 应用程序。我们处于“alpha”版本，该应用程序是为了部署在网络场上而构建的。
对于我们的会话提供程序，我们使用 Sql Server 模式（在开发和测试中），它似乎不可“扩展”，因此我们正在寻找在 ASP.NET 中处理会话的最佳解决方案（在我们的例子中为 mvc3）。我们目前正在使用 Sql Server，但由于许可证成本问题，我们想切换到其他系统。
我们的目标是 20 000 个[已编辑，之前是 10 万]并发用户。在会话中，我们存储一个 GUID、一个字符串和一个 Cart 对象（我们尽量保持尽可能少的数量，该对象允许我们在每个请求时保存 3 个查询）。
以下是我发现的不同解决方案：
ASP.NET 内置解决方案：
无会话：在我们的情况下不可能（已消除）
进程内模式：不能在网络场中使用。 （已淘汰）
StateServer 模式：可以在网络场中使用，但如果服务器出现故障，我会丢失所有会话。 （消除）
使用多个服务器的带有 PartitionResolver 的 StateServer 模式 (http://msdn.microsoft.com/ en-ca/magazine/cc163730.aspx#S8）如果我理解得很好，如果其中一台服务器出现故障，只有一部分用户会失去会话。
SqlServer模式：可以在网络场中使用，如果服务器出现故障，我可以恢复我的会话，但过程非常慢。此外，在负载较重的情况下，该数据库会成为瓶颈。
使用多个服务器的带有 PartitionResolver 的 SqlServer 模式 (http://www .bulletproofideas.net/2011/01/true-scale-out-model-for-aspnet-session.html)：如果其中一台服务器出现故障，只有一部分用户会丢失会话。如果用户在停机期间没有执行任何操作，他将恢复之前的会话，否则他将被重定向到登录屏幕。
自定义解决方案：
使用 MongoDB 作为会话存储 (http://www.adathedev .co.uk/2011/05/mongodb-aspnet-session-state-store.html）这似乎是一个很好的权衡，但我对 nosql 的了解相当初级，所以我看不到缺点。
使用 Memcached ：问题与 StateServer 模式相同，如果 memcached 服务器出现故障，我的所有会话都会丢失。此外，我认为Memcached不是专门用来存储会话状态的？
使用分布式 Memcached，例如 ScaleOut (http://highscalability.com/product-scaleout-stateserver-memcached-steroids) ：似乎是最好的解决方案，但需要花钱。
使用repcached和memcached（http://repcached.lab.klab.org/），我从未见过实现那个解决方案。
我们可以轻松地使用 Azure 并使用它提供的工具，但我们只有一个应用程序，因此如果微软将价格提高一倍，我们的基础设施成本立即就会增加一倍（但这是另一个主题）。
那么，最好的方法是什么，或者至少您对此有何看法？
My team is currently building a new SaaS application for our company (Amilia.com). We are in "alpha" release and the application was built to be deployed on a web farm.
For our session provider, we are using Sql Server mode (in DEV and TEST) and it seems to be not "scalable", hence we are looking for the best solution for handling sessions in asp.net (mvc3 in our case). We are currently using Sql Server but we would like to switch to an other system due to license cost.
We target 20 000 [EDITED, was 100k before] concurrent users. In session, we store a GUID, a string and a Cart object (we try to keep it as little as possible, this object allows us to save 3 queries at each request).
Here are the different solutions I've found :
ASP.NET built-in solutions:
No session : impossible in our case (eliminated)
In-Proc Mode : can't be used in a webfarm. (eliminated)
StateServer Mode : can be used in a webfarm but if the server goes down, I lose all my sessions. (eliminated)
StateServer Mode with a PartitionResolver using multiple servers (http://msdn.microsoft.com/en-ca/magazine/cc163730.aspx#S8) If I undestand well, if one of these servers goes down, only a part of my users will lose their session.
SqlServer Mode : can be used in a webfarm, if the server goes down, I can recover my sessions but the process is quite slow. Moreover, that database becomes a bottleneck in case of heavy load.
SqlServer Mode with a PartitionResolver using multiple servers (http://www.bulletproofideas.net/2011/01/true-scale-out-model-for-aspnet-session.html) : If one of these servers goes down, only a part of my users will lose their session. If the user was doing nothing between the downtime, he will recover his previous session otherwise he will be redirected to the signin screen.
Custom solutions :
Use MongoDB as Session storage (http://www.adathedev.co.uk/2011/05/mongodb-aspnet-session-state-store.html) It seems to be a good tradeoff but my knowledge in nosql is quite rudimentary so I cannot see the cons.
Use Memcached : the problem will be the same as StateServer mode and if the memcached server goes down, all my sessions are lost. Furthermore, I think Memcached is not dedicated to store session state ?
Use distributed memcached like ScaleOut (http://highscalability.com/product-scaleout-stateserver-memcached-steroids) : seems to be the best solution but it costs money.
Use repcached and memcached (http://repcached.lab.klab.org/), I've never seen an implementation of that solution.
We could easily go to Ms Azure and use tools provided by it but we have only one application, so if Microsoft doubles the price, we immediately double our infrastructure cost (but that's another subject).
So, what's the best way or at least what's your opinion about this ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
SQL Server 会话非常好。由于您已经有一个 SQL Server 数据库来存储主要数据，因此您可以创建另一个数据库并在其中存储 ASP.NET 会话。
关于可扩展性，我想说，如果您有 100,000 个并发用户，那么您的用户群必须超过 1000 万或更多。您应该做一些实际的估计，看看真正需要多长时间才能达到这样的并发用户负载。在我之前的创业公司中，我们在世界各地拥有数百万用户，每天 24 小时，但我们几乎没有达到 10K 并发用户，即使人们每天连续使用我们的网站几个小时。
如果您确实有 100,000 个并发用户，那么许可证成本将是您最不用担心的。有了正确的商业模式，拥有 10 万并发用户意味着您每年至少有 1000 万美元的收入。
我构建了 myoffice.bt.com，它在单个 SQL Server 实例上使用 SQL Server 会话和所有主要数据，但在两个数据库中。上午 8 点到 10 点之间，数百万用户访问了我们的网站。我们几乎没有任何性能问题。借助双核服务器、8 GB RAM，只要编码正确，您就可以愉快地运行 SQL Server 实例并支持这样的负载。这完全取决于您的编码方式。如果您遵循性能最佳实践，则可以在单个数据库服务器上轻松扩展到数百万用户。
看看我的性能建议：
http://omaralzabir.com/tag/performance/
我仅使用 memcached 集群来缓存常用数据。出于充分的原因，从未用于会话。曾经多次需要重新启动 memcached 服务器。如果我们使用 memcached 进行会话，我们将丢失该实例中存储的所有会话。因此，我不建议将会话存储在 memcached 中。但话又说回来，对于您的应用程序而言，维护会话中的数据有多重要？如果您有一个购物车，那么当用户在购物车上添加产品时，它必须保留在数据库中，而不是会话中。会话通常用于短期存储。对于任何事务性数据，您都不应该将其保留在会话中，而是直接将其存储在关系表中。
我始终支持不使用 Session。开发人员一直在滥用会话。每当他们想要将数据从一个页面传递到另一页面时，他们只需将其放在会话中即可。这会导致糟糕的设计。如果您确实想要扩展到 10 万并发用户群，请将您的应用程序设计为根本不使用会话。任何交易数据都必须存储在数据库中。 Cart 是一个事务性对象，因此不适合在 Session 上保存。在某些时候，您需要知道有多少购物车已启动但从未被放置。因此，您需要将它们永久存储在数据库中。
请记住，基于数据库的会话只不过是基于数据库的序列化。仔细考虑要序列化到数据库中的内容。您还必须清理它，因为 Session_End 不会触发基于数据库的会话，或者实际上大多数进程外会话。因此，本质上，您使开发人员能够将数据序列化到数据库中并绕过关系模型。它总是会导致糟糕的编码。
借助永久关系存储，以 memcached 等高性能缓存为前端，您可以拥有更好的设计来支持庞大的用户群。
希望这对您的担忧有所帮助。
SQL Server session is pretty good. Since you already have a SQL Server database to store your primary data, you can just create another database and store the ASP.NET Session there.
About the scalability, I would say if you have 100,000 concurrent users, then your userbase must be more than 10 millions or more. You should do some practical estimate to see really how long it will take to reach such a concurrent user load. In my previous startup, we had millions of users all around the world, 24x7, but we hardly ever reached 10K concurrent users even though people used our site continuously for hours every day.
If you really have 100,000 concurrent users, license cost would be the least of your worry. With right business model, having 100K concurrent users means you have at least $10M revenue/year.
I have built myoffice.bt.com that uses SQL Server session and all primary data on a single SQL Server instance, but in two databases. Between 8 AM to 10 AM, millions of users hit our site. We hardly have any performance issue. With a dual Core server, 8 GB RAM, you can happily run a SQL Server instance and support such a load as long as you code it right. It all depends on how you have coded. If you have followed performance best practices, you can easily scale to millions of users on a single database server.
Take a look at my performance suggestions from:
http://omaralzabir.com/tag/performance/
I have used memcached clusters only to cache frequently used data. Never used for session for good reasons. There's been several occasions where a memcached server had to be rebooted. If we had used memcached for session, we would have lost all the sessions stored in that instance. So, I would not recommend storing sessions in memcached. But then again, how important is it for your app to maintain data in session? If you have a shopping cart, then as users add products on the cart, it must get persisted in database, not in session. Session is usually for short term storage. For any transactional data, you should never keep it on session, instead store it on relational tables directly.
I am always in support of not using Session. Developers abuse session all the time. Whenever they want to pass data from one page to another, they just put it on the Session. It results in bad design. If you truly want to scale to 100K concurrent user base, design your app to not use session at all. Any transactional data must be stored in database. Cart is a transactional object and thus it's not suitable for holding on Session. At some point you would need to know how many carts get started but never gets placed. So, you will need to store them in database permanently.
Remember, database based session is nothing but databased based serialization. Think very carefully on what you are serializing into database. You will have to clean it up as well since Session_End won't fire for database based session or in fact most of the out of proc sessions. So, essentially you are giving devs ability to just serialize data into database and bypass relational model. It always results in bad coding.
With permanent relational storage, fronted by a high performance cache like memcached, you have much better design to support large user base.
Hope this helps your concerns.