【问题标题】:Message Queue Design消息队列设计
【发布时间】:2014-01-17 11:22:00
【问题描述】:

这是场景

我有一个离线应用程序,当用户按下发布时我想要

  • 打印 2 份到打印机 A
  • 打印 1 份到打印机 B
  • 打印 3 份到打印机 C
  • 向收件人 A 发送 txt 消息
  • 向收件人 B 发送 txt 消息
  • 将数据导出到外部系统
  • 与在线网站同步数据
  • 可以将各种其他工作添加到列表中

所以我要问的是我可以使用更好的结构,我希望避免使用完整的消息队列系统,因为这是一个独立的桌面应用程序。

我开始为每个任务创建一个数据库表并将作业编号放入列表中,然后对其进行处理,并在完成后将其从列表中删除。

虽然这工作正常,但作业失败时会出现问题,我没有重试超时或任何东西,并且每次添加任务(不经常)时,我都必须添加一个新表,这不是超好的。

我遇到的其他问题是所有任务都有不同的参数,我应该只使用 json 或其他东西来存储这些参数吗?目前数据库中的每个表都有不同的参数列

【问题讨论】:

标签: message-queue


【解决方案1】:

听起来是 MQ 的理想工作。发布后,您可以使用适当的参数将作业添加到队列中。然后,您需要 10 个(或其他)读者来阅读消息并管理打印/发短信/导出等。根据您的描述,使用数据库滚动您自己的没有意义。

超时/重试是一个业务问题,您需要弄清楚如何发出警报和解决。这不是您想象的技术问题。

就我个人而言,每个目标都有一个消息类型/队列。 JSON 或其他格式将取决于您的平台。通常,您只需使用平台提供的任何机制将包含所有数据的对象序列化到队列中。最坏的情况是,您制作 XML,然后将其添加到队列中。

【讨论】:

    【解决方案2】:

    如果您的应用程序不打算跨系统扩展,我认为您不需要 MQ。消息队列最适合分布式系统。您已经提到它将成为一个桌面应用程序。

    在设计应用程序时,您必须根据给定的要求识别组件。您目前拥有的是一组要求。您需要将它们分解为可重复使用的组件。

    重试和超时是任务的参数......当您通过组件执行任务时,您可以处理它们。

    您需要一个数据库,但不需要高扩展性的数据库。您只需要一个持久性存储。

    【讨论】:

      猜你喜欢
      • 2017-02-01
      • 1970-01-01
      • 2017-08-27
      • 1970-01-01
      • 2013-05-17
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-11-27
      相关资源
      最近更新 更多