即时消息的频繁数据库查询

Question

我正在为我们的部门创建一个Instant Messaging应用程序。该应用程序的功能是：

1. 消息将存储在数据库中
2. 可以将消息发送到一个，多个或所有用户/位置
3. 登录的用户将能够看到他们所包含的消息的历史记录。

我的问题：从每个客户端不断查询数据库是否合适 - 应该少于20个客户端运行 - 比如说每15到30秒左右？我已经看到了使用tcipclient的服务器/客户端消息传递应用程序的示例，但我不熟悉该主题。所以我认为查询数据库可能是我可以采用的方法。经常执行这些查询的后果是什么？我也在看sqldependencies ???我真的应该回去尝试学习tcip技术吗？

由于

Answer 1

如果你知道你将永远拥有数十个客户的订单而不是数千个客户的订单，那么轮询将工作得很好，你不必每15秒轮询一次（这将是如果你这样做就无法使用了，你可以每隔100或200毫秒进行一次轮询，这样就可以即时聊天。

确保每个轮询操作尽可能简单。您可以做的最简单的操作是：

SELECT * FROM chat_log WHERE chat_log.id > ?其中id是您的IDENTITY主键，而?是您的客户端到目前为止从服务器看到的最后一个ID。因此，如果没有新的聊天消息，则不会检索任何行。对于客户端检索的每一行，更新客户端到目前为止看到的最大ID，您就可以了。

我做到了，它就像一个魅力。

从技术角度来看，轮询是一种非常 ignoble 技术，但在许多情况下，它可能是一种实际的折衷方案，只需很少的开发即可产生足够好的结果。 （另一种方法是创建一个适当的聊天服务器，向客户端发送推送通知，祝你好运。）

Answer 2

如果少于20个客户端（每20秒选择20个查询+一些写入），SQL Server将无需处理这些消息。

工具和技术的选择取决于您的实际要求。 （邮件大小，允许文件传输，删除/编辑邮件......）

我可以提出一些改善绩效的方案，

• 阅读邮件 - 您可以使用缓存（例如Azure Redis缓存）查看最近的邮件（最近30天）。您可以提出后台缓存更新策略，以确保它不断更新新消息。读取消息将首先调用缓存，只有在缓存未命中时才会访问数据库。

此外，您还可以创建本地消息缓存（客户端），这将显着提高最终用户的性能。您可以为此创建一个SQLite（如Skype一样.Win + R - ＆gt;％appdata％\ skype - ＆gt;％ - ＆gt; main.db）

否则，您只需在数据库中拥有一个存档表，其中计划的（每24小时）后台进程存档超过14/30天的邮件。所以你会收到最近的消息

• 写作 - 编写消息会很繁琐，而不是直接更新数据库，您可以使用消息队列（Azure消息队列，Rabbit MQ等）。然后，您可以使用另一个进程将消息写入数据库。

每种技术选择都有自己的成本，优缺点和学习时间。因此，从简单开始，稍后留出空间。