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

【问题标题】：Frequent Database Query for Instant Message即时消息的频繁数据库查询
【发布时间】：2015-12-02 11:24:06
【问题描述】：

我正在为我们部门创建一个即时消息应用程序。该应用程序的特点是：

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

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

谢谢

【问题讨论】：

标签： sql-server instant-messaging

【解决方案1】：

如果您知道您将始终拥有数十个客户端而不是数千个客户端，那么轮询就可以正常工作，并且您不必每 15 秒轮询一次，（它会是否则将无法使用，）您可以每 100 或 200 毫秒轮询一次，因此聊天会立即显示。

只要确保每个轮询操作尽可能简单。你可以做的最简单的操作是这样的：

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

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

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

【讨论】：

谢谢，迈克。是的，这个应用程序将仅限于我们的部门，因此护士和其他工作人员可以在不通过对讲机等宣布患者姓名的情况下进行交流。感谢您的反馈。

【解决方案2】：

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

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

我可以建议一些提高性能的选项，

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

您还可以创建本地消息缓存（客户端），这将显着提高最终用户的性能。您可以为此创建一个 SQLite（就像 Skype 一样。Win + R -> %appdata%\skype -> 文件夹 -> main.db）

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

写入 - 写入消息会很麻烦，而不是直接更新数据库，您可以使用消息队列（Azure 消息队列、Rabbit MQ.. 等）。然后你可以有另一个进程将消息写入数据库。

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

【讨论】：

谢谢，达努卡。好的建议。我特别喜欢 x 天后的存档。