asp.net-mvc - ASP.NET MVC session 状态使用状态分区、MongoDB 或 Memcached 或...？

Question

我的团队目前正在为我们公司构建新的 SaaS 应用程序 ( Amilia.com )。我们处于“alpha”版本，该应用程序是为了部署在网络场上而构建的。

对于我们的 session 提供程序，我们使用 Sql Server 模式(在开发和测试中)，它似乎不可“扩展”，因此我们正在寻找在 ASP.NET 中处理 session 的最佳解决方案(在我们的例子中为 mvc3) )。我们目前正在使用 Sql Server，但由于许可证成本问题，我们想切换到其他系统。

我们的目标是 20000 个[已编辑，之前是 10 万]并发用户。在 session 中，我们存储一个 GUID、一个字符串和一个 Cart 对象(我们尽量保持尽可能少的数量，该对象允许我们在每个请求时保存 3 个查询)。

以下是我找到的不同解决方案:

ASP.NET 内置解决方案:

无 session :在我们的情况下不可能(已消除)

进程内模式:不能在网络场中使用。 (已淘汰)

StateServer 模式:可以在网络场中使用，但如果服务器出现故障，我会丢失所有 session 。 (已淘汰)

带有使用多个服务器的 PartitionResolver 的 StateServer 模式 ( http://msdn.microsoft.com/en-ca/magazine/cc163730.aspx#S8 ) 如果我理解得很好，如果其中一台服务器出现故障，只有一部分用户会丢失 session 。

SqlServer 模式:可以在网络场中使用，如果服务器出现故障，我可以恢复 session ，但过程非常慢。此外，在负载较重的情况下，该数据库会成为瓶颈。

使用多个服务器的带有 PartitionResolver 的 SqlServer 模式 ( http://www.bulletproofideas.net/2011/01/true-scale-out-model-for-aspnet-session.html ):如果其中一台服务器出现故障，只有一部分用户会丢失 session 。如果用户在停机期间没有执行任何操作，他将恢复之前的 session ，否则他将被重定向到登录屏幕。

定制解决方案:

使用 MongoDB 作为 session 存储( http://www.adathedev.co.uk/2011/05/mongodb-aspnet-session-state-store.html )这似乎是一个很好的权衡，但我对 nosql 的了解非常初级，所以我看不到缺点。

使用 Memcached :问题与 StateServer 模式相同，如果 memcached 服务器出现故障，我的所有 session 都会丢失。此外，我认为 Memcached 不是专门用来存储 session 状态的？

使用像 ScaleOut ( http://highscalability.com/product-scaleout-stateserver-memcached-steroids ) 这样的分布式 memcached:似乎是最好的解决方案，但它需要花钱。

使用repcached和memcached(http://repcached.lab.klab.org/)，我从未见过该解决方案的实现。

我们可以轻松地访问 Ms Azure 并使用它提供的工具，但我们只有一个应用程序，因此如果微软将价格提高一倍，我们的基础设施成本会立即增加一倍(但这是另一个主题)。

那么，最好的方法是什么，或者至少您对此有何看法？

Answer 1

SQL Server session 非常好。由于您已经有一个 SQL Server 数据库来存储主要数据，因此您只需创建另一个数据库并在其中存储 ASP.NET session 即可。

关于可扩展性，我想说，如果您有 100,000 个并发用户，那么您的用户群必须超​​过 1000 万或更多。您应该做一些实际的估计，看看真正需要多长时间才能达到这样的并发用户负载。在我之前的创业公司中，我们在世界各地拥有数百万用户，每天 24 小时，但我们几乎没有达到 10K 并发用户，即使人们每天连续使用我们的网站几个小时。

如果您确实有 100,000 个并发用户，那么许可证成本将是您最不用担心的。如果采用正确的业务模式，拥有 10 万并发用户意味着您每年至少拥有 1000 万美元的收入。

我已经构建了 myoffice.bt.com，它在单个 SQL Server 实例上使用 SQL Server session 和所有主要数据，但在两个数据库中。上午 8 点到 10 点之间，数百万用户访问了我们的网站。我们几乎没有任何性能问题。借助双核服务器、8 GB RAM，只要编码正确，您就可以愉快地运行 SQL Server 实例并支持这样的负载。这完全取决于您的编码方式。如果您遵循性能最佳实践，则可以在单个数据库服务器上轻松扩展到数百万用户。

看看我的性能建议: http://omaralzabir.com/tag/performance/

我仅使用 memcached 集群来缓存常用数据。出于充分的原因，从未用于 session 。有好几次必须重新启动 memcached 服务器的情况。如果我们使用 memcached 进行 session ，我们将丢失该实例中存储的所有 session 。因此，我不建议将 session 存储在 memcached 中。但话又说回来，对于您的应用程序来说，维护 session 中的数据有多重要？如果您有一个购物车，那么当用户在购物车上添加产品时，它必须保留在数据库中，而不是 session 中。 session 通常用于短期存储。对于任何事务性数据，您都不应该将其保留在 session 中，而应直接将其存储在关系表中。

我始终支持不使用 Session。开发人员一直在滥用 session 。每当他们想要将数据从一个页面传递到另一页面时，他们只需将其放在 session 中即可。这会导致糟糕的设计。如果您确实想要扩展到 10 万并发用户群，请将您的应用程序设计为根本不使用 session 。任何交易数据都必须存储在数据库中。 Cart 是一个事务性对象，因此不适合在 Session 上保存。在某些时候，您需要知道有多少购物车已启动但从未被放置。因此，您需要将它们永久存储在数据库中。

请记住，基于数据库的 session 只不过是基于数据库的序列化。仔细考虑要序列化到数据库中的内容。您还必须清理它，因为 Session_End 不会触发基于数据库的 session ，或者实际上大多数进程外 session 。因此，本质上，您使开发人员能够将数据序列化到数据库中并绕过关系模型。它总是会导致糟糕的编码。

借助永久关系存储，以 memcached 等高性能缓存为前端，您可以拥有更好的设计来支持庞大的用户群。

希望这能帮助您解决问题。