中间件技术标准体系(主流的中间件有哪些)

一个是什么是消息中间件？为什么要使用消息中间件或消息中间件的使用场景？ 1.1消息中间件消息中间件是指能够：介于两个系统之间，用于存储、交换、路由消息的平台或系统。

1.2为什么使用消息中间件1.2.1异步处理

程序运行时，主线程或启动器线程需要做一些事情，但不需要同步等待此结果。可以创建异步线程并执行它，也可以通过消息中间件来实现。将此事件或消息发送到消息中间件，程序向下运行，消息中间件的消费者可以消耗消息并通过实现具体的业务逻辑来获得异步处理的效果。例如，用户注册时，需要以邮件或邮件的形式向用户发送注册成功的消息；或者向新注册的用户赠送优惠券。这种异步比同步更节约时间

1.2.2去耦的应用

如果一个系统需要消耗需要生成的核心消息，则原始方法可以直接调用其他系统的服务接口。例如，商品系统的更新数据需要对购物车中的商品数据和现金数据进行索引和更新。此外，向ElasticSearch写入日志也满足这种情况。如图所示：

更新商品数据需要重新编制索引，需要更新购物车系统中的商品数据。如果商品系统自行调用搜索系统索引服务和购物车系统数据更新服务，当搜索系统不可用或购物车系统不可用时该怎么办？图标：

此时，是否要将数据回滚到商品系统中？还是让购物车系统丢失此更新？商品系统不可能一直再试吧。所以，不是可靠的方案。如果您存储此数据，并使用它直到购物车系统可用，则它不是实时的，但不会丢失任何数据，从而实现了最终的完整性。那么，如何保存这条信息？消息中间件可以这样做。商品系统向消息中间件发送数据，而搜索系统和购物车系统作为消费者从消息中间件中消耗数据。如果购物车系统不可用，则在恢复时数据位于消息中间件中，可以继续使用。这将断开商品系统与搜索系统和购物车系统的连接，如图所示。

1.2.3流量消峰

有时在高峰时段流量很大，例如我们的程序运行时，晚上7点到9点，或者在一些网站上活动时。此时，正常配置可能无法处理这么多流量。这个时候，你可能会考虑增加机器来解决。那也不错，但在这样的高峰期只有1-2个小时。剩下的时候没那么多流量，机器会浪费的。所以我们这个时候也可以利用消息中间件来承受高并发性，后面的系统从中间件上慢慢消耗，这样不需要增加机器，也不用担心系统崩溃。但是，这样的场景是有限的，必须是用户要求被放弃的场景。否则，消息中间件就会满。我该怎么办？例如，这种东西可以用于抢购和秒杀，但促销场景流量变多是不合适的。促销需要保证用户的要求，所以不能直接丢弃。

双消息中间件需要解决的问题是什么？ 2.1发布订阅

订阅是消息中间件的基础功能。所以RabbitMQ、RocketMQ、Kafka都支持。

2.2为了防止信息持久化信息的丢失，必须保证信息能够持久化。这也是消息中间件所需的基础功能。所以RabbitMQ、RocketMQ、Kafka都支持。

2.3也是消息堆栈消息中间件的基本功能。如果消费者数量不足或遇到某个时间段的洪水，消耗速率低于生产速率，则如果服务器上大量存储消息并且不支持消息堆栈，该数据可能会丢失。所以RabbitMQ、RocketMQ、Kafka都支持。

2.4消息确认消息确认也是消息中间件的基本功能。

ActiveMQ、RabbitMQ、RocketMQ、Kafka都支持消息确认。其中RabbitMQ的消息确认分为发送方确认机制和接收方确认机制，当接收方autoAck设置为false,需要消费者显示确认。Kafka确认机制主要分为3个级别，ack=0: 只要发送出去了就确认了；ack=1：只要Leader副本收到就确认，ack=-1: 必须Leader副本和所有Follower副本接收到才确认。

2.5 消息重试

当消费者消费消息，没有返回响应的时候，服务器端不知道消费者到底是否消费成功，所以超时没有响应则重新将消息发送给消费者。目前ActiveMQ、RabbitMQ和RocketMQ支持消息重试，Kafka不支持。

2.6 死信队列

当消息被消费者拒绝、消息超时未被消费或者消息队列满了，这个消息可能会变成死信，可能会放到死信队列。如果直接丢弃肯定是不好的方案，最好的方案是保存一个特殊的队列里，后面还可以继续消费。那么这个队列就是死信队列(Dead-Letter Queue)，死信队列的消息就是死信消息(Dead-Letter Message)。当然也只有ActiveMQ、RabbitMQ、RocketMQ支持死信队列，Kafka不支持。

2.7 定时(延时)消息

有时候，生产者将消息发送到Broker, 但是不希望消息立刻被消费，而是希望在指定的时间或者过一段时间再被消费。ActiveMQ、RabbitMQ、RocketMQ支持延时消息，Kafka不支持延时消息。

2.8 消息回溯

指的是消息中间件具备重复消费的能力，ActiveMQ和RabbitMQ不支持消息回溯功能，Kafka支持基于指定分区的消费offset位置回溯，RocketMQ支持定点时间回溯。

2.9 顺序消息

有时候需要保证消息按照生产者发送的顺序，在broker顺序存储和消费者顺序消费，比如使用canal进行mysql binlog增量同步，如果先增加，后修改然后删除，但是消费则消费的顺序是先删除、在修改肯定就有问题了。目前ActiveMQ、RocketMQ和Kafka支持局部有序，RocketMQ只保证同一个主题的相同队列的消息是有序的，Kafka也只是能保证同一个分区下的消息是有序的，除非RocketMQ只有一个队列，Kafka只有一个分区才是全局有序。

2.11 消息优先级

有时候需要支持消息优先级，即优先级高的消息先被消费。ActiveMQ和RabbitMQ支持消息优先级，但是RocketMQ和Kafka不支持优先级，只能通过其他变通的方式实现。

RabbitMQ实现了消息优先级：

#1 设置队列的x-max-priority=n参数：表示该队列有n个优先级，从高到低是n,n-1......0

#2 设置消息的Priority参数: 设置具体的优先级

2.12 消息过滤

消息过滤有两种，一种是服务器端过滤，一种是客户端过滤。严格的讲，每一个消息中间件在客户端都可以按照业务需求自行过滤，但是服务器端过滤只有RocketMQ实现了，RocketMQ可以通过TAG实现消息过滤。RabbitMQ、Kafka服务器端没有实现消息过滤的功能，只能在客户端实现。

2.13 事务

消息有时候需要事务功能。RabbitMQ实现了生产者发送时候的事务功能；RocketMQ支持分布式事务的功能；Kafka在0.11版本也实现了事务的功能。RocketMQ和Kafka分布式事务都属于2阶段提交。

RocketMQ:

第一阶段：提交半消息，只是在Broker中CommitLog中存在，不会被消费

第二阶段：根据提交半消息的状态，执行本地事务，根据本地事务结果

2.14 幂等性

当生产者发送消息的时候，我们需要考虑幂等性。比如生产者发送消息到Broker，Broker写入磁盘，然后向生产者确认。如果写入成功，按时确认的时候因为网络或者Broker挂了，那么此时生产者接收不到确认，可能会发起重试，则又发送一次，如果没有幂等机制，那势必日志中又要多添加一条数据，这样就会被重复消费。

RabbitMQ、RocketMQ都是无法保证幂等性，只能在消费端去重。Kafka0.11版本之前也是无法保证幂等的，但是0.11版本通过ProducerId和Sequence Number可以实现幂等性。

ProducerId: 在每个新的Producer初始化时，会被分配一个唯一的ProducerID，这个ProducerID对客户端使用者是不可见的。

SequenceNumber：生产者每次发送的RecordBatch都有一个单调递增的sequence number,Broker上每个分区也会维护<pid,seq>的映射，并且每次提交都会更新lastSeq(上一次最后的序列号)。当RecordBatch到来的时候，broker会先检查seq是不是大于lastSeq，如果大于则保存数据；否则说明已经保存了，无需再次保存。