一、介绍
1. 消息中间件的定义
没有标准定义，一般认为，采用消息传送机制/消息队列 的中间件技术，进行数据交流，用在分布式系统的集成
2. 为什么要用消息中间件
解决分布式系统之间消息的传递，用户下单减库存，调用物流系统。随着业务量的增大，需要对系统进行拆分（服务化和业务拆分），拆分后的系统之间的交互一般用RPC（远程过程调用）。如果系统扩充到有几十个接口，就需要用消息中间件来解决问题
3. 消息中间件和RPC有什么区别
3.1 功能特点：
在架构上，RPC和Message的差异点：Message有一个中间结点Message Queue，可以把消息存储。
3.2 消息的特点
Message Queue把请求的压力保存一下，逐渐释放出来，让处理者按照自己的节奏来处理。
Message Queue引入一下新的结点，让系统的可靠性会受Message Queue结点的影响。
Message Queue是异步单向的消息。发送消息设计成是不需要等待消息处理的完成。
所以对于有同步返回需求，用Message Queue则变得麻烦了。
3.3 RPC的特点
同步调用，对于要等待返回结果/处理结果的场景，RPC是可以非常自然直觉的使用方式。
# RPC也可以是异步调用。
由于等待结果，Consumer（Client）会有线程消耗。
如果以异步RPC的方式使用，Consumer（Client）线程消耗可以去掉。但不能做到像消息一样暂存消息/请求，压力会直接传导到服务Provider。
3.4 适用场合说明
希望同步得到结果的场合，RPC合适。
希望使用简单，则RPC；RPC操作基于接口，使用简单，使用方式模拟本地调用。异步的方式编程比较复杂。
不希望发送端（RPC Consumer、Message Sender）受限于处理端（RPC Provider、Message Receiver）的速度时，使用Message Queue。
随着业务增长，有的处理端处理量会成为瓶颈，会进行同步调用到异步消息的改造。
这样的改造实际上有调整业务的使用方式。
比如原来一个操作页面提交后就下一个页面会看到处理结果；改造后异步消息后，下一个页面就会变成“操作已提交，完成后会得到通知”。
4. 消息中间件的使用场景
4.1 异步处理
用户注册（50ms），还需发送邮件（50ms）和短信（50ms）
串行：（150ms）用户注册—》发送邮件----》发送短信
并行（100ms）：用户注册—》发送邮件----》发送短信
消息中间件（56ms）：
用户注册（50ms）—》（6ms）消息中间件《-----发送邮件《-----发送短信
说明：
用户注册时，可能还需要同时发送邮件和短信，使用串行的方式进行处理时花费的时间比较久；这时就会考虑并行处理，即用户注册完以后，同时启动两个两个线程去发送邮件和短信，这样时间就会花费得更少。
如果引入消息中间件的话就会比并行处理更快，即用户注册时，把注册信息放到消息中间件里面，然后发送邮件和短信的程序自己去消息中间件里面那用户注册的消息来消费
4.2 应用的解耦
订单系统---》库存系统（强耦合）
消息中间件：订单系统---》消息中间件《----库存系统（解耦）
原因：下订单以后还要同步去修改库存，没有必要耦合在一起
说明：
用户下订单时，可能还需要去更新库存，这个时候下订单的后，还需要同步去更新库存，这样两个系统之间就会有很强的耦合。
所以这个时候引入消息中间件，当用户下订单后，直接把订单信息放入消息中间件里面，接着就不用管了，库存系统直接去消息中间件里面那订单信息来消费就行了，这样订单系统和库存系统之间就解耦了
4.3 流量的削峰
用户请求-----》秒杀应用
应用的前端加入消息队列
用户请求-----》消息队列《----秒杀应用
原因：用户访问太多，服务器承受不了
说明：
在做秒杀的时候会有许多访问，可能导致系统承受不住。这个时候就需要在应用的前端加入消息队列，然后秒杀系统就可以直接去消息队列里面拿消息来消费就行了，秒杀系统是可以选择性的拿消息过来消费的，如果消息太多就会选择性的丢弃一些消息
4.4 日志处理
错误日志---》消息队列《----日志处理
用户行为日志--》消息队列(kafka)《-----日志的存储或流式处理
原因：机器太多，日志查看不方便
说明：
当系统太多的时候，部署了很多机器，每台机器上面都有日志，定位问题的时候不可能去每一台机器去看日志。
这个时候就需要引入消息中间件，把所有的日志放到消息中间件里面，然后在通过一个应用去读取日志存库或者展示
4.5 纯粹的消息通信
点对点通信
5. 常见消息中间件比较
说明：
kafka和RabbitMQ的比较
1）RabbitMq比kafka成熟，在可用性上，稳定性上，可靠性上，RabbitMq超过kafka
2）Kafka设计的初衷就是处理日志的，可以看做是一个日志系统，针对性很强，所以它并没有具备一个成熟MQ应该具备的特性
3）Kafka的性能（吞吐量、tps）比RabbitMq要强
二、JMS规范
1. 什么是JMS规范
JMS（Java Messaging Service）规范，本质是API，Java平台消息中间件的规范，java应用程序之间进行消息交换。并且通过提供标准的产生、发送、接收消息的接口简化企业应用的开发。对应的实现ActiveMQ
2. JMS对象模型包含如下几个要素
1）连接工厂：创建一个JMS连接
2）JMS连接：客户端和服务器之间的一个连接。
3）JMS会话：客户端和服务器会话的状态，建立在连接之上的
4）JMS目的：消息队列
5）JMS生产者：消息的生成
6）JMS消费者：接收和消费消息
7）Broker：消息中间件的实例（ActiveMQ）
3. JMS规范中的点对点模式
队列，一个消息只有一个消费者（即使有多个接受者监听队列），消费者是要向队列应答成功
4. JMS规范中的主题模式（发布订阅）
发布到Topic的消息会被当前主题所有的订阅者消费
5. JMS规范中的消息类型
TextMessage,MapMessage,ObjectMessage,BytesMessage,StreamMessage
三、ActiveMQ、RabbitMQ、RocketMQ、Kafka之间的比较
|
特性 |
ActiveMQ |
RabbitMQ |
RocketMQ |
Kafka |
|
单机吞吐量 |
万级，吞吐量比RocketMQ和Kafka要低了一个数量级 |
万级，吞吐量比RocketMQ和Kafka要低了一个数量级 |
十万级，RocketMQ也是可以支撑高吞吐的一种MQ |
十万级别，这是kafka最大的优点，吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集 |
|
topic数量对吞吐量的影响 |
|
|
topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降 这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic |
topic从几十个到几百个的时候，吞吐量会大幅度下降 在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源 |
|
时效性 |
ms级 |
微秒级，延迟最低 |
ms级 |
延迟在ms级以内 |
|
可用性 |
高，基于主从架构实现高可用性 |
高，基于主从架构实现高可用性 |
非常高，分布式架构 |
非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
|
消息可靠性 |
有较低概率丢失数据 |
|
经过参数优化配置，可以做到0丢失 |
经过参数优化配置，可以做到0丢失 |
|
功能支持 |
MQ领域的功能极其完备 |
基于erlang开发，所以并发能力很强，性能极其好，延时很低 |
MQ功能较为完善，还是分布式的，扩展性好 |
功能较为简单，支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用 |
|
优劣势总结 |
非常成熟，功能强大，在业内大量的公司以及项目中都有应用。 缺点： 偶尔会有较低概率丢失消息，而且现在社区以及国内应用都越来越少，官方社区现在维护越来越少，几个月才发布一个版本； 主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用。
|
erlang语言开发，性能极其好，延时很低； 吞吐量到万级，MQ功能比较完备； 开源提供的管理界面非常棒，很好用； 社区相对比较活跃，几乎每个月都发布几个版本； 在国内一些互联网公司近几年用rabbitmq也比较多。 缺点： RabbitMQ吞吐量会低一些，这是因为他做的实现机制比较重。 因为是基于erlang开发，很难去看懂源码，难以定制和掌控，基本职能依赖于开源社区的快速维护和修复bug。 |
接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障； 日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便； 社区维护还可以，可靠性和可用性都不错，还可以支撑大规模的topic数量，支持复杂MQ业务场景； 而且一个很大的优势在于，阿里出品都是java系的，可以自己阅读源码，定制自己公司的MQ，易于定制和掌控。 缺点： 社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码； 因为是阿里出台的技术，得做好这个技术万一被抛弃，社区黄掉的风险。 |
kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展； 同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量； 缺点： kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略，这个特性天然适合大数据实时计算以及日志收集场景。 |