常用消息队列中间件MQ对比分析_排队系统用什么中间件比较好

1、什么是MQ？MQ又有哪些场景使用？

消息队列

消息队列是一种异步的通信方式，用于在分布式系统中管理消息传递。消息队列采用了生产者-消费者模型，生产者将消息发送到队列中，而消费者则从队列中接收消息。

使用消息队列的好处是什么？

解耦

A系统发送个数据到BCD三个系统，接口调用发送，那如果E系统也要这个数据或者如果C系统现在不需要了、现在A系统又要发送第二种数据了呢？而且A系统要时时刻刻考虑BCDE四个系统如果挂了要不要重发、要不要把消息存起来

我们需要去考虑一下咋们的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用MQ给他异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个MQ去进行系统的解耦。

异步

A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要20ms，BCD三个系统分别写库要100ms、500ms、300ms。最终请求总延时是20 + 100 + 500 + 300 =920ms，接近1s。

BCD三个系统改成消息队列异步通讯，写库时间就不用考虑了，大大提升响应速度和性能。

削峰

每天0点到14点，你的系统风平浪静，每秒并发请求数量就几百个个。但每到14点~23点，每秒并发请求数量突然会暴增到几万条。但是此时系统最大的处理能力就只能是每秒钟处理10000个请求，那此时就需要进行流量的削峰，让系统可以平缓的处理好突增的请求。

2、RabbitMQ的AMQP协议

AMQP协议

是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。目标是实现一种在全行业广泛使用的标准消息中间件技术，以便降低企业和系统集成的开销，并且向大众提供工业级的集成服务。主要实现有 RabbitMQ。

客户端与RabbitMQ的通讯

连接

首先作为客户端（无论是生产者还是消费者），你如果要与RabbitMQ通讯的话，你们之间必须创建一条TCP连接，当然同时建立连接后，客户端还必须发送一条“问候语”让彼此知道我们都是符合AMQP的语言的，比如你跟别人打招呼一般会说“你好！”，你跟国外的美女一般会说“hello!”一样。你们确认好“语言”之后，就相当于客户端和RabbitMQ通过“认证”了。你们之间可以创建一条AMQP的信道。

信道

概念：信道是生产者/消费者与RabbitMQ通信的渠道。信道是建立在TCP连接上的虚拟连接，什么意思呢？就是说rabbitmq在一条TCP上建立成百上千个信道来达到多个线程处理，这个TCP被多个线程共享，每个线程对应一个信道，信道在RabbitMQ都有唯一的ID ,保证了信道私有性，对应上唯一的线程使用。

疑问：为什么不建立多个TCP连接呢？原因是rabbit保证性能，系统为每个线程开辟一个TCP是非常消耗性能，每秒成百上千的建立销毁TCP会严重消耗系统。所以rabbitmq选择建立多个信道（建立在tcp的虚拟连接）连接到rabbit上。

从技术上讲，这被称之为“多路复用”，对于执行多个任务的多线程或者异步应用程序来说，它非常有用。

虚拟主机

虚拟消息服务器，vhost，本质上就是一个mini版的mq服务器，有自己的队列、交换器和绑定，最重要的，自己的权限机制。Vhost提供了逻辑上的分离，可以将众多客户端进行区分，又可以避免队列和交换器的命名冲突。Vhost必须在连接时指定，rabbitmq包含缺省vhost：“/”，通过缺省用户和口令guest进行访问。

rabbitmq里创建用户，必须要被指派给至少一个vhost，并且只能访问被指派内的队列、交换器和绑定。Vhost必须通过rabbitmq的管理控制工具创建。

交换器类型

共有四种direct,fanout,topic,headers，其种headers(几乎和direct一样)不实用，可以忽略。

Direct

路由键完全匹配，消息被投递到对应的队列， direct交换器是默认交换器。声明一个队列时，会自动绑定到默认交换器，并且以队列名称作为路由键：channel->basic_public($msg,’’,’queue-name’)

Fanout

消息广播到绑定的队列，不管队列绑定了什么路由键，消息经过交换器，每个队列都有一份。

Topic

通过使用“”和“#”通配符进行处理，使来自不同源头的消息到达同一个队列，”.”将路由键分为了几个标识符，“”匹配1个，“#”匹配一个或多个。

3、RabbitMQ是怎样保证消息不丢失的？

持久化

在发送消息时，可以设置消息属性 delivery_mode 为 2，表示该消息需要被持久化，即将消息保存到磁盘中，即使 RabbitMQ 服务器宕机也能够保证消息不会丢失。可以在创建队列时将 durable 属性设置为 True，表示该队列也需要被持久化，以便在 RabbitMQ 服务器宕机后能够重新创建队列和绑定。

确认机制

在 RabbitMQ 中，消费者通过 basic.ack 命令向 RabbitMQ 服务器确认已经消费了某条消息。如果消费者在处理消息时发生错误或宕机，RabbitMQ 服务器会重新将消息发送给其他消费者。在确认消息之前，RabbitMQ 会将消息保存在内存中，只有在收到消费者的确认消息后才会删除消息。

发布者确认

RabbitMQ 支持发布者确认（Publisher Confirm）机制，即发布者在将消息发送到队列后，等待 RabbitMQ 服务器的确认消息。如果 RabbitMQ 成功将消息保存到队列中，会返回一个确认消息给发布者。如果 RabbitMQ 服务器无法将消息保存到队列中，会返回一个 Nack（Negative Acknowledgement）消息给发布者。通过发布者确认机制，可以确保消息被成功发送到 RabbitMQ 服务器。

备份队列

RabbitMQ 支持备份队列（Alternate Exchange）机制，即在消息发送到队列之前，先将消息发送到备份队列中。如果主队列无法接收消息，RabbitMQ 会将消息发送到备份队列中。备份队列通常是一个交换机，可以在创建队列时通过 x-dead-letter-exchange 属性来指定备份队列。

4、Kafka如何做到消息不丢失？

Kafka 通过ISR（In-Sync Replicas）机制、ACK 机制、副本机制多种机制来确保消息不丢失

ISR 机制

在 Kafka 中，副本分为 Leader 副本和 Follower 副本。Leader 副本负责处理消息，Follower 副本只是简单地复制 Leader 副本的数据。当 Follower 副本落后于 Leader 副本时，Kafka 会将 Follower 副本从 ISR 中移除。只有当 Follower 副本与 Leader 副本的差距不大时，才会将 Follower 副本重新加入 ISR，确保消息不会丢失。

ACK 机制

在 Kafka 中，生产者发送消息时可以指定 acks 参数，表示生产者等待的确认数。acks 参数有三个取值：

• acks=0 表示生产者不等待确认消息，直接将消息发送到 Kafka 集群。这种方式可能会导致消息丢失，不建议使用。

• acks=1 表示生产者在 Leader 副本收到消息后，就将消息视为发送成功。如果 Leader 副本在发送消息后立即宕机，消息可能会丢失。如果 Follower 副本成功复制了消息，但 Leader 副本在宕机前没有来得及将消息写入磁盘，则这条消息将会丢失。

• acks=all 表示生产者在所有 ISR 副本都确认接收到消息后，才将消息视为发送成功。这种方式可以最大程度地确保消息不会丢失，但是会降低消息发送的性能。

副本机制

Kafka 通过副本机制来确保消息不会丢失。在 Kafka 中，每个分区都可以配置多个副本，每个副本保存分区的完整副本，当一个副本宕机时，Kafka 会自动将副本切换到其他可用的副本上。因此，即使其中一个副本宕机，也能够保证消息不会丢失。

以上方式可以最大程度地确保 Kafka 中的消息不会丢失，不过实际应用中，还需要根据实际场景选择合适的参数配置来平衡消息发送的性能和可靠性。

5、RocketMQ如何做到消息不丢失？

RocketMQ 通过多种机制来确保消息不丢失，包括刷盘机制、消息拉取机制、ACK 机制等。

刷盘机制

RocketMQ 中的消息分为内存消息和磁盘消息，内存消息在 Broker 内存中进行读写，磁盘消息则保存在磁盘上。RocketMQ 支持同步刷盘和异步刷盘两种方式，通过刷盘机制可以确保消息在 Broker 宕机时不会丢失。在同步刷盘模式下，消息写入磁盘时，会等待磁盘的写入完成才返回写入成功的响应。在异步刷盘模式下，消息写入磁盘后立即返回写入成功的响应，但是不等待磁盘写入完成

ACK 机制

在 RocketMQ 中，Producer 发送消息后，Broker 会返回 ACK 确认信号，表示消息已经成功发送。如果 Broker 没有收到 ACK 确认信号，就会尝试重新发送该消息，直到消息被确认为止。

RocketMQ 采用主从复制机制，每个消息队列都有一个主节点和多个从节点，主节点负责消息的写入和读取，从节点负责备份数据。当主节点宕机时，从节点会自动接管主节点的工作，确保消息不会丢失

消息存储机制

RocketMQ 默认使用双写模式来存储消息，即将消息同时写入内存和磁盘中，然后再将内存中的消息异步刷盘到磁盘中。这种方式可以保证消息的可靠性，即使系统宕机，也能够尽可能地保证消息不会丢失。

除此之外，RocketMQ 还提供了多种机制来保证消息不丢失，例如事务消息、延迟消息、顺序消息等，这些机制可以根据业务需求进行选择和使用。

不过，为了确保消息的可靠性，RocketMQ 的发送消息的速度可能会受到一定的限制，需要在消息可靠性和性能之间进行权衡。

6、重复消费：幂等性处理

幂等性解释

对于消息接收端的情况,幂等的含义是采用同样的输入多次调用处理函数,得到同样的结果。例如，一个SQL操作

update order_table set count= 100 where id =1000

这个操作多次执行,id等于1000的记录中的 count字段的值都为100,这个操作就是幂等的,我们不用担心这个操作被重复。

再来看另外一个SQL操作

update order_table set count= count +100  where id= 1000;

这样的SQL操作就不是幂等的,一旦重复,结果就会产生变化。

确保幂等的一些场景办法

1. MVCC：

多版本并发控制，乐观锁的一种实现，在生产者发送消息时进行数据更新时需要带上数据的版本号，消费者去更新时需要去比较持有数据的版本号，版本号不一致的操作无法成功。例如朋友圈点赞次数自动+1的接口：

public boolean addAct(Long id, Long version);

update xxxTable set count= count+1,version=version+1 where id=9999 and version=321

每一个version只有一次执行成功的机会，一旦失败了生产者必须重新获取数据的最新版本号再次发起更新。

2. 去重表：

利用数据库表单的特性来实现幂等，常用的一个思路是在表上构建唯一性索引，保证某一类数据一旦执行完毕，后续同样的请求不再重复处理了，

就是加上一张日志表来记录已经处理成功的消息的ID，如果新到的消息ID已经在日志表中，那么就不再处理这条消息

以某个互联网电商平台为例子，平台上的订单号就是最适合的Token

每当用户下单时，会经历生成订单，减库存，减优惠券等环节。每一个环节执行时都先检测一下该订单是否已经执行过这一步骤，对未执行的请求，执行操作并缓存结果，而对已经执行过的订单，则直接返回之前的执行结果，不做任何处理，这样可以最大程度避免操作重复问题，其实缓存起来的执行结果也能用于事务控制