ActiveMQ-为什么需要消息中间件？

Posted 2020-10-19 皮特王同学

消息中间件的优势

UNIX的进程间通信就开始运用消息队列技术，一个进程将数据写入某个特定的队列中，其它进程可以读取队列中的数据，从而实现异步通信。对于如今的分布式系统，消息队列已经演变为独立的消息中间件产品，相比于RPC同步通信的方式来说有几个明显的优势：

• 低耦合，不管是程序还是模块之间，使用消息中间件进行间接通信。
• 消息的顺序性，消息队列可以保证消息的先进先出。
• 消息可靠传输，持久化的存储使得消息只有在被消费之后才会删除。
• 异步通信能力，相对于RPC来说，异步通信使得生产者和消费者得以充分执行自己的逻辑而无需等待。
• 缓冲能力，消息中间件像是一个巨大的蓄水池，将高峰期大量的请求存储下来慢慢交给后台进行处理，对于秒杀业务来说尤为重要。

但是异步通信也存在程序设计和编程方面的复杂，同时对于实时性要求较高的业务也不能采用异步通信，所以要根据业务具体分析。

J2EE和JEE是什么?

J2EE全称是Java to Enterprise Edition，是一套企业级技术规范，包含：JMS Servlet JSP EJB JPA 等。J2EE发展到1.5版本改名为JEE5，所以JEE是J2EE规范的延续。 

消息中间件的发展历程

• J2EE时代，消息中间件强调企业级特性，比如消息持久化和事务性要求，全部遵循JMS规范。典型的ActiveMQ、HornetQ，后者现在已经发展成ActiveMQ Artemis子项目，这表明在Java/JEE领域ActiveMQ会继续发挥不可替代的作用。           
• 后Java时代，随着消息中间件协议AMQP（Advanced Message Queuing Protocol）的诞生，最知名的AMQP消息中间件产品RabbitMQ也随之诞生，RabbitMQ基于Erlang开发，2007年诞生至今已经称为最流行的开源消息中间件产品，ActiveMQ于2013年也开始支持AMQP协议，后来Apache还推出了ActiveMQ Apollo的新项目，也实现了包括AMQP在内的多种协议。
• 互联网时代，设计思路上采用分布式系统设计理念，以LinkedIn开源的Kafka为代表，Kafka使用Scala编写，由于良好的水平扩展能力和高性能被广泛采用，同时诞生了一些高仿的类似产品如搜狐的Jafka，阿里的RocketMQ等。              

 JMS是什么？

JMS Java Message Service Java消息服务是J2EE架构中针对消息中间件的一组规范。JMS规范定义了Java中访问消息中间件的接口，但没有给予实现，具体实现交给消息中间件，称为JMS Provider，如ActiveMQ就是一个JMS Provider。简单说，没有实现这些接口的消息中间件就不能纳入J2EE（JEE）架构，Java程序也无法与其进行交互。

JMS的两种消息传送模型

JMS支持两种消息传送模型：点对点消息通信模型和发布订阅模型。

• 点对点（PTP）消息通信模型也可称之为队列模式，特定的一条消息只能被一个消费者消费。生产者将消息发送到指定的Queue当中，Broker（中间件）针对消息是否需要持久化进行持久化存储后通知消费者进行处理，消费者处理完毕后发送一个回执（Acknowledge）给Broker，Broker认为该消息已被正常消费，于是从持久化存储中删除该条消息。回执的发送逻辑内嵌在MQ的API中，无需主动调用。消费者通常可以通过两种方式获取新消息：PUSH和PULL。PUSH方式，由MQ收到消息后主动调用消费者的新消息通知接口，需要消耗MQ宝贵的线程资源，同时消费者只能被动等待消息通知；PULL方式，由消费者轮询调用MQ API去获取新消息，对应于ActiveMQ中的方法为consumer.receive()，不消耗MQ线程，消费者更加主动，虽然消费者的处理逻辑变得稍稍复杂。两种方式的根本区别在于线程消耗问题，由于MQ的线程资源相对客户端更加宝贵，PUSH方式会占用MQ过多的线程从而难以适应高并发的消息场景。同时当某一消费者离线一段时间再次上线后，大量积压消息处理会消耗大量MQ线程从而拖累其它消费者的消息处理，所以PULL方式相对来说更好。Kafka已经抛弃了PUSH模式，全面拥抱PULL模式。

• 发布/订阅模式（Pub/Sub）也可称之为主题模式，特定的一条消息可以被多个消费者所接收，只要消费者订阅了某个主题。消息生产者（发布者）将消息发送到某个称为主题（Topic）的虚拟通道中，Topic可以被多个消费者订阅，因此该模式类似于广播的方式。发布/订阅模式采用PUSH的方式传送消息，Subscriber只需保持在线即可。Subscriber分为临时性的和持久性的，当Sub离线时，MQ会为持久性的Sub持久化消息，当Sub恢复时会重新收到消息。但是既然采用Pub/Sub模式就表明允许部分消费者接收不到消息，所以通常会采用临时性的Subscriber而不是持久性的。