2

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

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

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

第三组只是在看报告。

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

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

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

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

我想有两点需要考虑。最重要的是，减少网络流量，更重要的是，让我的代码更简单。

我确信这是一个非常常见的模式，但我对这种事情很陌生，所以欢迎提出建议。提前致谢。

[更新] 关闭选民，我用谷歌搜索并找不到答案。我希望对您的经验有所帮助。你能帮我改写这个可以接受吗？或者也许给一个对我有帮助的UTL？谢谢

4

2 回答 2

4

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

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

我在博客上写了一篇关于这个的两部分文章

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

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

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

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

相关问题：

于 2013-04-06T08:16:15.890 回答
1

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

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

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

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

  • 是的，这是低效的
  • 通常是最快和最简单的事情。
  • 似乎是最好的短期临时解决方案，以最小的努力获得最大的价值。
    • 适合“探索性编码”，有助于获得更好的软件设计。
    • 应该是完善/探索替代方案的良好基础。
    • 对于程序员来说，在签入导致技术债务的修复程序后，努力记录和/或与可能受到您的更改影响的团队成员共享非常重要。
    • 如果不打算作为生产质量代码，这是可以接受的。
    • 如果可用性很差，请考虑更有效的解决方案，就像您在下面描述的那样。

“定期询问数据库服务器在过去 X 分钟内是否有任何变化。”

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

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

  • 这就是您所说的“推送”模型——发布更改，准备好让订阅者采取行动。
    • 考虑这对等待推送的客户端有什么影响 - 超时场景、客户端数量等、系统资源消耗等。
    • 考虑到“推动者”必须意识到所有正在使用的应用程序。如果使用行业标准的消息队列系统（RabbitMQ、MS MQ、MQ Series 等，所有自然支持发布/订阅 JMS 主题或等效主题，那么这个问题就被抽象出来了，但也给您的应用程序增加了一些复杂性）
    • 考虑客户端突然变得不可用的场景，假设故障模式并测试系统的稳健性，以便您确信它能够从故障中正确恢复并始终保持稳定。

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

于 2013-09-01T03:01:24.150 回答