这个系统最有效的架构是什么？ （推或拉）

Question

所有s / w都是基于Windows的，用Delphi编码。

有些人提交了一些数据，我通过TCP发送到运行MySql的数据库服务器。

其他一些人为他们的数据添加通过/失败并更新数据库。

第三组正在查看报告。

现在，第一组可以看到他们提交的内容的历史记录。当第二组添加通过/失败时，我想更新其历史记录。我的选择似乎是

1. 定期刷新历史记录（在Delphi中，我在数据库网格上显示，然后关闭然后打开查询），但这似乎效率低下。
2. 定期向数据库服务器询问最近X分钟内是否有任何变化。
3. 从不轮询数据库服务器，而是让它在发生变化时通知用户的应用程序。

1似乎效率低下。 2似乎更好。 3减少了TCP流量，但这并不多。无论如何，每个只有几个字节。但是，它的缺点是双方现在都是TCP客户端和服务器。

同样，如果第三组的成员正在查看报告并且前两个组中的任何一个的成员更新数据，我希望在报告中反映这一点。这是最好的方法吗？

我想有两件事需要考虑。最重要的是，减少网络流量，不那么重要，使我的代码更简单。

我确信这是一种非常常见的模式，但我对这种事情不熟悉，所以欢迎提出建议。提前谢谢。

---

[更新]关闭选民，我用google搜索＆amp;无法找到答案。我希望得到你的经验。你能帮我改一下这是可以接受的吗？或者给一个能帮助我的UTL？感谢

Answer 1

简答：使用通知（选项3）。

长答案：这是一个使用面向消息的中间件传播更改的中间层的用例。这将消息传递逻辑与数据库元数据（触发器/存储过程）分离，可以使用对等和发布/订阅通信模式等。

我在

上写了两篇关于此事的文章

• Firebird Database Events and Message-oriented Middleware (part 1)
• Firebird Database Events and Message-oriented Middleware (part 2)

这篇文章是关于Firebird的，但建议的解决方案可以应用于任何应用程序/数据库。

在您的方案中，即使数据库或Delphi部分已关闭，客户端也可以使用中间件消息代理向系统发送消息。消息将在代理中排队，直到系统的其他部分重新联机。如果有许多客户端并且需要更新安装或维护窗口，这是一个优势。

  

同样，如果第三组的成员正在查看报告并且a   我希望前两组中任何一组的成员更新数据   在报告中反映了这一点。这是最好的方法吗？

如果这是一个真正的要求（报告通常是数据的不可变“快照”，但也许你的意思是需要在观看时更新的视图，类似于股票报价）但是它很容易实现 - 客户只需要“订阅”一个宣布相关数据变化的信息渠道。使用现有的消息代理功能（如消息选择器和目标通配符）可以非常灵活地节省资源并节省资源。 （请注意，我是开源消息代理的一些Delphi和Free Pascal客户端库的作者。）

---

相关问题：

• Client-Server database application: how to notify clients that data was changed?
• How to communicate within this system?

Answer 2

在某些情况下，您提出的每个解决方案都是可行的。

我已经写了很长时间的软件，下面的评论与个人经历有关，可以追溯到1981年。我毫不怀疑其他人会有其他意见，也会回答你的问题。

请允许我证明每种方法的正面和负面以及每条评论的参数。

  

“定期盲目刷新历史记录（在Delphi中，我在数据库网格上显示，然后关闭然后打开查询），但这似乎效率低下。”

• 是的，效率低下
• 通常是最快捷，最简单的事情。
• 似乎是最好的短期临时解决方案，它为最小的努力提供了最大的价值。
  • 有助于“探索性编码”，有助于获得更好的软件设计。
  • 应该是改进/探索替代方案的良好基础。
  • 程序员努力记录和/或与团队成员分享，这些团队成员在签入技术债务导致修复时可能会受到您的团队变更的影响。
  • 如果不打算作为生产质量代码，这是可以接受的。
  • 如果可用性差，请考虑更有效的解决方案，如下所述。

  

“如果在最后X分钟内发生任何变化，请定期询问数据库服务器。”

• 您正在谈论的是“拉动”或“轮询”模式。请考虑此模型的以下API选项：
  • 自从我上次打电话给你以来发生了什么变化？ （客户提供时间以避免服务必须存储和检索视觉状态）
  • 如果没有任何更改，服务器可以提供客户端应再次轮询的时间。然后，处于过载状态的系统能够回退客户端，即如果服务器应用程序已经意识到这种情况，那么通过指示它们等待更长的时间段，它能够更好地控制合规客户端的轮询速率。在重试之前。
  • 在考虑之后，问“API是否尽可能简单？”

  

“从不轮询数据库服务器，而是让它在发生变化时通知用户的应用程序。”

• 这是您正在谈论的“推送”模式 - 发布变更，为订阅者做好准备。
  • 考虑一下这对等待推送的客户端有什么影响 - 超时场景，客户端数量等，系统资源消耗等。
  • 考虑到“推动者”必须了解所有消费应用程序。如果使用行业标准的消息传递排队系统（RabbitMQ，MS MQ，MQ系列等，所有这些都自然地支持发布/订阅JMS主题或等价物，那么这个问题就会被抽象掉，但也会给你的应用程序增加一些复杂性）。
  • 考虑客户突然变得不可用的情况，假设故障模式并测试系统的稳健性，这样您就可以确信它能够从故障中正确恢复并始终保持稳定。

那么，您认为现在正确的做法是什么？