我只是在阅读关于JMS和Apache ActiveMQ的abit . 并且想知道现实世界中有人使用JMS或类似的消息队列技术吗？
我们使用它来启动我们不希望中断或与现有事务冲突的异步处理 .
例如，假设你有一个昂贵且非常重要的逻辑，比如“买东西”，购买东西的一个重要部分就是“通知东西商店” . 我们使通知调用异步，以便通知调用中涉及的任何逻辑/处理都不会阻止或与使用购买业务逻辑的资源竞争 . 最终结果，购买完成，用户满意，我们得到了我们的钱，并且因为队列是有保证的交付，所以商店一打开就会得到通知，或者一旦队列中有新项目就会得到通知 .
JMS（ActiveMQ是JMS代理实现）可以用作允许异步请求处理的机制 . 您可能希望这样做，因为请求需要很长时间才能完成，或者因为多方可能对实际请求感兴趣 . 使用它的另一个原因是允许多个客户端（可能用不同语言编写）通过JMS访问信息 . ActiveMQ就是一个很好的例子，因为您可以使用STOMP协议来允许从C＃/ Java / Ruby客户端进行访问 .
一个真实世界的例子是用于为特定客户下订单的Web应用程序 . 作为下订单（并将其存储在数据库中）的一部分，您可能希望执行许多其他任务：
将订单存储在某种第三方后端系统（例如SAP）中
向客户发送电子邮件，通知他们已下订单
为此，您的应用程序代码会将消息发布到包含订单ID的JMS队列 . 监听队列的应用程序的一部分可以通过获取orderId，在数据库中查找订单然后将该订单与另一个第三方系统放在一起来响应事件 . 您的应用程序的另一部分可能负责获取orderId并向客户发送确认电子邮件 .
分布式（a）同步计算 .现实世界的示例可以是应用程序范围的通知框架，它在应用程序使用过程中的各个点向利益相关者发送邮件 . 因此，应用程序将通过创建 Message 对象充当 Producer ，将其置于特定的 Queue 上，并向前移动 .会有一组 Consumer 谁会订阅有问题的 Queue ，并会小心处理发送过的 Message . 请注意，在此事务过程中， Producer 与处理给定 Message 的逻辑分离 .消息传递框架（ActiveMQ等）通过提供 MessageBroker 来充当促进此类 Message 事务的主干 .
Message
Producer
Queue
Consumer
MessageBroker
我用它来发送不同基金管理系统之间的日内交易 . 如果您想了解更多有关精彩技术消息的信息，我可以完全推荐“Enterprise Integration Patterns”这本书 . 有一些JMS示例用于请求/回复和发布/订阅 .
消息传递是一种很好的集成工具 .
始终使用它们异步处理长时间运行的操作 . Web用户不希望等待超过5秒的时间来处理请求 . 如果你有一个运行时间超过一个的设计，一个设计是将请求提交到队列并立即发回一个URL，用户可以检查该URL以查看作业何时完成 .
发布/订阅是另一种将发送者与许多接收者分离的好方法 . 它是一种灵活的架构，因为订户可以根据需要来去 .
我用它来做我的学术项目，这是一个类似亚马逊的在线零售网站 . JMS用于处理以下功能：
当货物从一个地点移动到另一个地点时，更新客户下订单的位置 . 这是通过不断向JMS队列发送消息来完成的 .
提醒任何异常事件，如装运延迟，然后向客户发送电子邮件 .
如果交货到达目的地，则发送交货事件 .
我们有多个也实现了连接到主服务器的远程客户端 . 如果连接可用，则它们用于访问主数据库或不使用自己的数据库 . 为了处理数据一致性，我们实施了2PC机制 . 为此，我们使用JMS来交换这些系统之间的消息，即一个充当协调器的人将通过在队列上发送消息来启动该过程，而其他人将通过在队列上再次发送消息来响应 . 正如其他人已经提到的，这与pub / sub模型类似 .
我见过JMS用于不同的商业和学术项目 . JMS很容易就来了无论何时你想拥有一个完全分离的分布式系统，你的图片就可以了 . 一般来说，当您需要从一个节点发送请求时，网络中的某个人在没有/向发送者提供有关接收者的任何信息的情况下处理它 .
就我而言，我在论文中使用JMS开发了面向消息的中间件（MOM），其中特定类型的面向对象的对象作为您的请求在一侧生成，并在另一侧作为您的响应进行编译和执行 .
我们使用JMS通过不可靠的网络与大量远程站点中的系统进行通信 . 松散耦合与可靠的消息传递相结合，可以产生稳定的系统环境：每条消息都会在技术上尽快发送，网络中更大的问题不会对整个系统环境产生影响......
Apache Camel与ActiveMQ结合使用是进行企业集成模式的好方法
我对JMS有很多惊人的用途：
用于客户服务的Web聊天通信 .
后端调试日志记录 . 所有应用服务器都在各个级别广播调试消息 . 然后可以启动JMS客户端以监视调试消息 . 当然我可以使用像syslog这样的东西，但是这给了我各种方法来根据上下文信息过滤输出（例如，通过app server name，api call，log level，userid，message type等...） . 我也把输出着色了 .
调试记录到文件 . 与上面相同，只使用过滤器拉出特定部分，并记录到文件以进行常规日志记录 .
警报 . 再次，与上述日志记录类似的设置，观察特定错误，并通过各种方式警告人们（电子邮件，短信，IM，低吼弹出......）
动态配置和控制软件集群 . 每个应用服务器都会广播一个“configure me”消息，然后是一个配置守护进程，它将使用包含各种配置信息的消息进行响应 . 稍后，如果所有应用服务器都需要立即更改其配置，则可以从配置守护程序完成 .
通常 - 延迟活动的排队交易，例如结算，订单处理，配置，电子邮件生成......
在任何想要保证异步传递消息的地方都很棒 .
我们使用消息传递来生成在线报价
11 回答
我们使用它来启动我们不希望中断或与现有事务冲突的异步处理 .
例如，假设你有一个昂贵且非常重要的逻辑，比如“买东西”，购买东西的一个重要部分就是“通知东西商店” . 我们使通知调用异步，以便通知调用中涉及的任何逻辑/处理都不会阻止或与使用购买业务逻辑的资源竞争 . 最终结果，购买完成，用户满意，我们得到了我们的钱，并且因为队列是有保证的交付，所以商店一打开就会得到通知，或者一旦队列中有新项目就会得到通知 .
JMS（ActiveMQ是JMS代理实现）可以用作允许异步请求处理的机制 . 您可能希望这样做，因为请求需要很长时间才能完成，或者因为多方可能对实际请求感兴趣 . 使用它的另一个原因是允许多个客户端（可能用不同语言编写）通过JMS访问信息 . ActiveMQ就是一个很好的例子，因为您可以使用STOMP协议来允许从C＃/ Java / Ruby客户端进行访问 .
一个真实世界的例子是用于为特定客户下订单的Web应用程序 . 作为下订单（并将其存储在数据库中）的一部分，您可能希望执行许多其他任务：
将订单存储在某种第三方后端系统（例如SAP）中
向客户发送电子邮件，通知他们已下订单
为此，您的应用程序代码会将消息发布到包含订单ID的JMS队列 . 监听队列的应用程序的一部分可以通过获取orderId，在数据库中查找订单然后将该订单与另一个第三方系统放在一起来响应事件 . 您的应用程序的另一部分可能负责获取orderId并向客户发送确认电子邮件 .
分布式（a）同步计算 .
现实世界的示例可以是应用程序范围的通知框架，它在应用程序使用过程中的各个点向利益相关者发送邮件 . 因此，应用程序将通过创建
Message对象充当Producer，将其置于特定的Queue上，并向前移动 .会有一组
Consumer谁会订阅有问题的Queue，并会小心处理发送过的Message. 请注意，在此事务过程中，Producer与处理给定Message的逻辑分离 .消息传递框架（ActiveMQ等）通过提供
MessageBroker来充当促进此类Message事务的主干 .我用它来发送不同基金管理系统之间的日内交易 . 如果您想了解更多有关精彩技术消息的信息，我可以完全推荐“Enterprise Integration Patterns”这本书 . 有一些JMS示例用于请求/回复和发布/订阅 .
消息传递是一种很好的集成工具 .
始终使用它们异步处理长时间运行的操作 . Web用户不希望等待超过5秒的时间来处理请求 . 如果你有一个运行时间超过一个的设计，一个设计是将请求提交到队列并立即发回一个URL，用户可以检查该URL以查看作业何时完成 .
发布/订阅是另一种将发送者与许多接收者分离的好方法 . 它是一种灵活的架构，因为订户可以根据需要来去 .
我用它来做我的学术项目，这是一个类似亚马逊的在线零售网站 . JMS用于处理以下功能：
当货物从一个地点移动到另一个地点时，更新客户下订单的位置 . 这是通过不断向JMS队列发送消息来完成的 .
提醒任何异常事件，如装运延迟，然后向客户发送电子邮件 .
如果交货到达目的地，则发送交货事件 .
我们有多个也实现了连接到主服务器的远程客户端 . 如果连接可用，则它们用于访问主数据库或不使用自己的数据库 . 为了处理数据一致性，我们实施了2PC机制 . 为此，我们使用JMS来交换这些系统之间的消息，即一个充当协调器的人将通过在队列上发送消息来启动该过程，而其他人将通过在队列上再次发送消息来响应 . 正如其他人已经提到的，这与pub / sub模型类似 .
我见过JMS用于不同的商业和学术项目 . JMS很容易就来了无论何时你想拥有一个完全分离的分布式系统，你的图片就可以了 . 一般来说，当您需要从一个节点发送请求时，网络中的某个人在没有/向发送者提供有关接收者的任何信息的情况下处理它 .
就我而言，我在论文中使用JMS开发了面向消息的中间件（MOM），其中特定类型的面向对象的对象作为您的请求在一侧生成，并在另一侧作为您的响应进行编译和执行 .
我们使用JMS通过不可靠的网络与大量远程站点中的系统进行通信 . 松散耦合与可靠的消息传递相结合，可以产生稳定的系统环境：每条消息都会在技术上尽快发送，网络中更大的问题不会对整个系统环境产生影响......
Apache Camel与ActiveMQ结合使用是进行企业集成模式的好方法
我对JMS有很多惊人的用途：
用于客户服务的Web聊天通信 .
后端调试日志记录 . 所有应用服务器都在各个级别广播调试消息 . 然后可以启动JMS客户端以监视调试消息 . 当然我可以使用像syslog这样的东西，但是这给了我各种方法来根据上下文信息过滤输出（例如，通过app server name，api call，log level，userid，message type等...） . 我也把输出着色了 .
调试记录到文件 . 与上面相同，只使用过滤器拉出特定部分，并记录到文件以进行常规日志记录 .
警报 . 再次，与上述日志记录类似的设置，观察特定错误，并通过各种方式警告人们（电子邮件，短信，IM，低吼弹出......）
动态配置和控制软件集群 . 每个应用服务器都会广播一个“configure me”消息，然后是一个配置守护进程，它将使用包含各种配置信息的消息进行响应 . 稍后，如果所有应用服务器都需要立即更改其配置，则可以从配置守护程序完成 .
通常 - 延迟活动的排队交易，例如结算，订单处理，配置，电子邮件生成......
在任何想要保证异步传递消息的地方都很棒 .
我们使用消息传递来生成在线报价