1

以下场景：我们有一个数据库表，其中存储了用户的新邮件消息。当用户运行我们的客户端应用程序时，当该用户的条目插入到数据库表中时，应用程序需要显示一个新邮件已到达的图标。

大约 100 个用户将同时登录。

据我所知，有两种解决方案：

  1. 在中央服务器上实现服务。该服务器定期轮询数据库。此外，客户端在启动时需要向服务器注册，以便在收到用户的新消息时回调它们。好：更少的数据库轮询。不好：中心元素的编码更多。
  2. 每个客户端都自己轮询数据库。轮询需要大约每分钟发生一次，所以我有 100 个客户端每分钟轮询数据库。馊主意？还是还可以？

那么，你会选择哪个选项？

我们的客户端使用 .NET 4.0，数据库使用 MS SQL Server 2008。

此外，如果您投票支持解决方案 1：WCF 服务会是一个好主意吗？围绕我的场景的任何链接或想法将不胜感激。

谢谢大家！

4

3 回答 3

2

现在跳出框框思考一下，您可能想要探索的另一个选项（特别是如果您已经有一个向应用程序公开内容的网络服务器）是使用一个将为您提供长轮询支持的库。例如，SignalR。这样您就可以避免来自客户端的轮询，而只需担心接收通知。

这是有关如何从控制台应用程序以及标准 web/js 实现中使用 SignalR 的教程。

现在，您遇到的另一个问题是不断轮询数据库以进行更改。您也可以通过使用SqlDependencyADO.net 和 SQL Server 中的功能（服务代理和通知）来避免这种情况。

这是一个使用这种实时通知方法的示例聊天应用程序。

根据并发客户端的实际数量，您甚至可以直接从客户端建立依赖关系（但不建议这样做）。

所以现在，结合这两者，您可以让您的服务器知道所有连接的客户端，并且您可以使用SqlDependency它仅在Messages表中的数据真正发生变化时触发更新。在这种情况下，您可能必须使用 ConnectionManager 获取 Hub，如SignalR 的 wiki 底部所示，标题为“Broadcasting over a Hub from outside of a Hub”。

我相信这种替代方案将比快速轮询方法更好地扩展，并将大大减少客户端和服务器之间以及服务器和数据库之间的整体流量。

但是，请注意，如果您在网络农场中进行部署，您可能需要对 SignalR 当前对它的支持进行更多研究。

于 2012-11-28T05:36:46.637 回答
1

选择选项 1。更多的代码，但更多的可扩展性。

于 2015-10-01T08:18:45.157 回答
0

我倾向于选择选项 1。更少的客户端与数据库交谈是一件好事，如果您稍后需要更改数据库或在其中添加一些其他逻辑，它会更容易。WCF 服务可能适用于此。

于 2012-11-27T20:44:25.910 回答