概念

消息中间件是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。

核心角色

消息中间件的使用有几个核心角色，如下图所示：
Producer 生产者：负责生产消息，将消息发送到消息队列中。
Consumer 消费者：负责消费使用消息，从消息队列中获取消息并进行处理。
Queue 消息中间件：作为消息传递的桥梁，负责存储和管理消息。

作用&使用场景

应用解耦

消息中间件可以将几个业务关联的微服务调用修改为基于MQ的异步通知，将消息发送方和消息接收方解耦，使得他们可以独立地进行开发和部署，不需要直接依赖于对方的实现细节。

异步通信

通过消息中间件，不同的服务之间可以进行异步通信，可以提高系统的吞吐量和并发性能，避免因为同步调用而导致的阻塞和性能瓶颈。

削峰填谷

消息中间件可以为消费者屏蔽上游的流量起伏，按自身系统的性能能力平稳消费处理消息。

大数据流处理

主要是Kafka，消息中间件可作为数据同步的传输工具，用于处理用户活动记录、实时数据传输、日志异步存储等场景。

使用模型

点对点模型

生产者将消息发送到一个特定的消息队列中，消息队列只会将消息传递给一个消费者处理。

发布-订阅模型

生产者将消息发送到一个主题（topic）中，消费者通过订阅该主题获取消息。在该模式下，消息队列会将消息广播给所有订阅了这个主题的消费者，一个消息可以发给多个消费者处理。

常见消息中间件

介绍

一、kafka

kafka是一个分布式的高吞吐量的消息系统，广泛应用于多种用途，例如实时数据流处理、日志聚合、监控、指标和日志收集、消息队列等。
kafka的基本模型是生产者向主题（Topic）发布消息，消费者从主题订阅消息。
消息通过一个或多个Kafka集群的代理（Broker）进行传输和存储，如下图所示：

二、RabbitMQ

一个开源的 AMQP（高级消息队列协议）消息代理软件，支持多种消息协议和多种语言的客户端，并提供可靠性、灵活性和可扩展性等优势。
RabbitMQ是erlang语言开发，结合erlang语言本身的并发优势。RabbitMQ支持许多高级特性，例如消息确认、持久化、优先级、消息 TTL、消息复制和分片等。
每个客户端都可以向不同的交换机发送消息，不同的交换机可以通过绑定key绑定多个队列，消费端通过绑定key可以消费不同的队列来实现不同的逻辑。

三、RocketMQ

RocketMQ是一个分布式的消息队列系统，由阿里巴巴集团开发并开源。
它具有高可用性、高吞吐量、高可靠性和可扩展性等特点，并且可以通过事务消息保证生产者和消费者之间的事务一致性。

比较

特性	Kafka	RabbitMQ	RocketMQ
关键字	高性能、高吞吐、大数据	可靠、简单易接入	可靠、事务支持
消息确认	发送消息：同步确认、异步确认；消费消息：支持，但消费消息后不删除，避免文件更新，更新offset（偏移量）	支持	支持
数据存储	磁盘	内存	内存
持久化	支持，写入log文件	支持	支持
分布式事务	不支持	不支持	支持
消息 TTL	支持	支持	支持
延迟队列	不支持，可自己手动实现，创建一个单独针对延迟队列的 topic，同时创建 18 个 partition 针对不同的延迟级别，发送消息的时候根据延迟参数发送到延迟 topic 对应的 partition，对应的key为延迟时间，同时把原 topic 保存到 header 中，使用定时器去轮询延迟的TopicPartition，如果到了时间就转发到真实的topic，如果没到则继续等待。	默认不支持，可通过死信机制通过消息过期实现；增加DelayExchange插件可支持延迟队列	支持，固定时间延迟队列，默认时间间隔分为 18 个级别，1s、 5s、 10s、 30s、 1m、 2m、 3m、 4m、 5m、 6m、 7m、 8m、 9m、 10m、 20m、 30m、 1h、 2h。
顺序消费	一个topic只能有一个发送者，保证消息发送的有序性。一个topic只能有一个分区，避免分区导致消息并发消费，而不是顺序消费。如果非要有多个分区，那么需要有一个key来保证相同key的消息在同一个分区。一个分区只能有一个消费者，可以通过锁保证。	保证消息发送的有序性；保证一组有序的消息都发送到同一个队列；保证一个队列只包含一个消费者	全局有序：这种方式主要是控制在一个Topic中，只允许有一个队列，并且生产者和消费者都需要只有一个实例进行，这样可以保证所有的消息都在同一个队列中被消费，从而实现顺序消费。分区有序：这种方式适用于一些复杂的业务场景，如电商业务的订单处理流程。在这种场景下，可以将每个订单相关的消息（如创建、付款、推送、完成等）分别发送到一个单独的主题中，然后在消费端开启负载均衡模式，以确保一个消费者能拿到的是按照订单处理的消息序列
死信机制	不支持	支持	支持
吞吐量级	单机10W/s级别	单机1w/秒级别	单机10W/s级别
消费模式	push+pull	push+pull	push+pull

一、Kafka如何实现高吞吐量

顺序写磁盘：Kafka的producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。
零拷贝技术：“零拷贝技术”只用将磁盘文件的数据复制到页面缓存中一次，然后将数据从页面缓存直接发送到网络中（发送给不同的订阅者时，都可以使用同一个页面缓存），避免了重复复制操作。如果有10个消费者，传统方式下，数据复制次数为4*10=40次，而使用“零拷贝技术”只需要1+10=11次，一次为从磁盘复制到页面缓存，10次表示10个消费者各自读取一次页面缓存。Kafka是采用了Java提供NIO包中的的FileChannel的transfer方法实现了高性能的IO传输操作，FileChannel提供了transferTo和transferFrom方法，都是采用了调用底层操作系统的sendfile函数来实现的CPU零拷贝机制。
Topic分区：kafka对每个Topic进行分区提高了并发，也提高了效率。

二、RocketMQ如何实现事务消息

RocketMQ的事务消息是通过两阶段提交（Two-phase Commit）协议实现的。具体实现步骤如下：
发送半事务消息：发送方将半事务消息发送至RocketMQ服务端，由于消息为半事务消息，在未收到生产者对该消息的二次确认前，此消息被标记成“暂不能投递”状态，不会被消费。
执行本地事务：发送方开始执行本地事务逻辑。可能是一系列的数据库更新、文件写入等操作，他们要么全部成功，要么全部回滚。
二次确认：发送方根据本地事务执行结果向服务端提交二次确认（Commit 或是 Rollback），服务端收到 Commit 状态则将半事务消息标记为可投递，订阅方最终将收到该消息；服务端收到 Rollback 状态则删除半事务消息，订阅方将不会接受该消息。
丢弃消息：如果二次确认时，发送方的本地事务没有执行完成，则可以向服务端返回 Unknown 状态，服务端收到 Unknown 状态则会等一段时间后，重新向发送方发起状态确认。如果发送方多次返回 Unknown 状态，服务端则会直接丢弃这一条消息。

思考题：事务消息解决什么问题？

事务消息解决的问题是：Provider本地事务 + 消息投递 一起执行。解决应用端 和 MQ端两个独立的应用的操作，在一个事务里面完成
因为传统的模式无法保证这一点，比如MQ宕机，或者网络丢失，而事务消息有一个两阶段确认的这一操作，可以大大降低这种丢失的概率。
但是这个功能和消费者无关，并不能确保该消息能被消费者成功消费。
消费端同样也存在这个分布式的问题：成功的从MQ中取出消息到本地 + 消费端成功业务上消费这个消息

思考题：事务消息和发送同步ack有什么区别：

RocketMQ有发送同步消息的功能，只有Broker Ack Send_OK状态码时才代表消息发送成功，否则阻塞重试，重试2次还失败就报错。
既然同步消息可以保证消息成功的写入到MQ中，为什么还要有事务消息呢？因为会遇到消息投递成功而本地事务执行失败的场景。
事务消息解决的问题是：Provider本地事务 + 消息投递 一起执行。
而同步消息解决的问题是：消息一定投递成功