谈论消息队列和通用消息中间件

当您需要使用消息队列时，首先需要考虑它的必要性. 在许多情况下都可以使用消息队列. 最常见的是应用程序松耦合，异步处理模式，发布和订阅，最终一致性，跨峰值流量控制和日志缓冲. 相反，如果您需要强大的一致性并专注于业务逻辑的处理结果，那么RPC更合适.

非核心进程是异步的，从而减少了系统响应时间并提高了吞吐量. 例如: 短信通知消息队列中间件，终端状态推送，应用推送，用户注册等.

消息队列通常具有内置的高效通信机制，因此它们也可以用于简单的消息通信，例如实现点对点消息队列或.

网站用户注册. 成功注册后，将在一段时间后发送电子邮件确认或短信.

图片

最终一致性不是消息队列的必要功能，但是您可以真正依靠消息队列来实现最终一致性.

像Kafka这样的设计有可能在设计级别丢失消息（例如定期闪烁，如果断电，则将丢失消息）. 即使仅丢失了千分之一的消息，企业也必须使用其他手段来确保结果正确.

生产者/使用者模型只需要关心消息是否传递到队列. 对于谁想要订阅和需要消费，这是一个下游问题，无疑大大减少了开发和联合调试的工作量.

图片

当上游和下游系统之间的处理能力存在差距时，消息队列将用作电流限制控制的通用“漏斗”. 当下游具有处理能力时，请重新分配它.

一个例子: 用户成功在付款系统中结帐后，订单系统将通过短信系统向用户推送扣除通知.

由于短板效应（每秒数百个请求），SMS系统可能会卡在网关上，并且与前端的并发不是一个数量级.

结果，支付系统和SMS系统的处理能力有所不同.

但是，当用户在晚上大约一分半钟的时间内收到短信时，通常没有问题. 如果没有消息队列，那么两个系统之间的协商和滑动窗口之类的复杂方案就不是不可能的. 但是，系统复杂度的指数增长将不可避免地存储在上游或下游，并将处理一系列问题，例如时序和拥塞. 而且只要处理能力存在差距，就需要开发一套单独的逻辑来维护这套逻辑.

因此，当下游系统具有处理这些消息的能力时，使用中间系统转储两个系统的通信内容并处理这些消息是一种相对常见的方法.

将消息队列用作可靠的临时存储位置，以在一定程度上存储消息；定期执行消息传递，例如模拟用户高峰访问，并执行系统性能压力测试.

图片

在日志处理（例如Kafka应用程序）中使用消息队列来解决大量日志传输和缓冲的问题.

集中收集日志以进行PV计算，用户行为分析等.

图片

消息队列通常具有内置的高效通信机制，因此它们也可以用于简单的消息通信，例如实现点对点消息队列或.

消息生产者将消息发送到消息队列，消息队列将消息推送到消息使用者.

使用者请求消息队列接收消息，消息生产者从消息队列中提取消息.

图片

这部分主要介绍四种常用消息队列（ActiveMQ / RabbitMQ / RocketMQ / Kafka）的主要特征，优缺点.

ActiveMQ由Apache生产. ActiveMQ是一个JMS Provider实现，它完全支持JMS1.1和J2EE 1.4规范. 它非常快速，支持多种语言的客户端和协议，并且可以轻松地嵌入到企业应用程序环境中，并具有许多高级功能.

图片

符合JMS规范: JMS规范提供了良好的标准和保证，包括: 同步或异步消息分发，一次性（仅一次）消息分发，消息接收和订阅等. JMS规范是消息队列中间件，无论使用哪种JMS实现提供程序，这些基本功能都是可用的；

连接灵活性: ActiveMQ提供了广泛的连接协议. 支持的协议为: HTTP / S，IP多播，SSL，TCP，UDP等. 对许多协议的支持使ActiveMQ具有很大的灵活性；

支持多种协议: OpenWire，STOMP，REST，XMPP，AMQP；

持久性插件和安全性插件: ActiveMQ提供了各种持久性选项. 而且，ActiveMQ的安全性还可以根据用户需求定制身份验证和授权；

支持多种类型的客户端语言: 除了Java外，还有: C / C ++ 、. NET，Perl，PHP，Python，Ruby;

代理群集: 多个ActiveMQ代理可以组成一个群集以提供服务；

极其简单的管理: ActiveMQ是基于开发人员的思想而设计的. 因此，由于它提供了简单易用的管理功能，因此不需要专门的管理员. 有许多方法可以在ActiveMQ的不同级别上监视数据，包括在JConsole或ActiveMQ的Web控制台中使用JMX. 通过使用命令行脚本处理JMX警报消息，您甚至可以监视各种类型的日志.

ActiveMQ可以在Java语言支持的平台上运行. 使用ActiveMQ需要:

跨平台（JAVA编写与平台无关，ActiveMQ可以在几乎所有JVM上运行）

可以使用

JDBC: 可以将数据持久化到中. 尽管使用JDBC会降低ActiveMQ的性能，但一直是开发人员最熟悉的存储介质；

支持JMS规范: 支持JMS规范提供的统一接口；

支持自动重新连接和错误重试机制；

有一个安全机制: 支持基于shiro，jaas等的多种安全配置机制，并且可以验证和授权Queue / Topic；

完美的监视: 包括Web控制台，JMX，Shell命令行，Jolokia的RESTful API在内的完整监视；

友好的界面: 提供的Web控制台可以满足大多数情况，并且有许多第三方组件可用，例如hawtio;

社区活动不如RabbitMQ；

根据其他用户的反馈，将会发生一些莫名其妙的问题，并且消息将丢失；

目前，重点是activemq 6.0产品Apollo，该产品对5.x的维护较少；

不适用于具有数千个队列的应用场景；

RabbitMQ于2007年发布. 它是基于AMQP（高级消息队列协议）的可重用企业消息传递系统. 它是最主流的消息传递中间件之一.

图片

可靠性: 提供多种技术，可让您权衡性能和可靠性. 这些技术包括持久性机制，交付确认，发布者确认和高可用性机制；

灵活的路由: 消息在到达队列之前先通过交换机路由. RabbitMQ为典型的路由逻辑提供了多种内置开关类型. 如果您有更复杂的路由要求，则可以组合使用这些交换机. 您甚至可以实现自己的开关类型，并将其用作RabbitMQ的插件；

消息集群: 同一局域网中的多个RabbitMQ服务器可以聚合在一起并用作独立的逻辑代理；

队列高可用性: 可以在群集中的机器上镜像队列，以确保消息在硬件问题下是安全的；

支持多种协议: 支持多种消息队列协议；

支持多种语言: 用Erlang语言编写，只要您能想到就支持所有编程语言;

管理界面: RabbitMQ具有易于使用的用户界面，允许用户监视和管理Message Broker的许多方面；

跟踪机制: 如果消息异常，RabbitMQ提供了消息跟踪机制，使用户可以发现发生了什么；

插件机制: 提供了许多插件以从多个方面扩展，您也可以编写自己的插件.

RabbitMQ可以在Erlang语言支持的平台上运行，包括Solaris，BSD，Linux，MacOSX，TRU64，Windows等. 使用RabbitMQ需要:

由于Erlang语言的特性，消息队列具有更好的性能并支持高并发性；

稳健，稳定，易于使用，跨平台，支持多种语言，完整的文档；

具有消息确认机制和持久性机制，可靠性高；

高度可定制的路由；

管理界面丰富，互联网公司中也有大型应用程序，社区活跃度很高.

尽管它结合了Erlang语言本身的优点和更好的性能，但不利于二次开发和维护；

实现了代理体系结构，这意味着可以在将消息发送到客户端之前在中央节点上对其进行排队. 此功能使RabbitMQ易于使用和部署，但使其运行速度较慢，因为中央节点增加了延迟，并且封装后消息更大；

需要学习更复杂的接口和协议，并且学习和维护的成本更高.

RocketMQ来自阿里巴巴的开源产品，并以Java语言实现. 在设计过程中引用了Kafka并进行了一些改进. 消息的可靠性优于Kafka. RocketMQ被广泛用于阿里巴巴的订单，交易，充值，流计算，消息推送，日志流处理，binglog分发等场景.

图片

基于队列模型: 具有高性能，高可靠性，实时性强，分布式的特点.

生产者，消费者和队列所有支持均已分发；

生产者依次将消息发送到某些队列，队列的集合称为主题. 如果消费者使用广播，则一个消费者实例将使用与该主题相对应的所有队列；如果使用群集，则多个Consumer实例将平均使用与此主题对应的队列集；

可以保证严格的消息顺序；

提供丰富的消息提取模式；

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-176178-1.html