消息队列基础知识

MQ 选型考量维度

可靠性、性能、功能、可运维性，可扩展性、是否开源及社区活跃

 

主题和队列

队列 和 发布-订阅模型

 

 

每个主题包含多个消息队列，通过多个消息队列实现并行生产和消费，

例如 RocketMQ 只在队列上保证消息的有序性，主题层面无法保证消息的严格顺序

队列 与主题 并没有本质的区别，他们最大的区别就是，一份消息能不能被多次消费。

 

如何利用事务性消息实现分布式事务

消息队列中的`事务`，主要解决的就是消息生产者和消息消费者的数据一致性问题。

例： RocketMQ 事务消息功能实现分布式事务流程如下

 

RocketMQ 中有事务反查机制，这种机制通过定时反查事务状态来补偿提交事务消息可能出现的失败。而在kafka中并没有这种反查机制（处理方式 直接抛异常），需要用户去自己解决这种问题

RocketMQ 的事务并没有完整实现事务的ACID （原子性、一致性、隔离性、持久性）四个特性

• A(原子性) ： 本地事务的操作1 与往消息队列中生产消息的操作 2，是两个分离的操作不符合对原子性的定义

• C(一致性) ： 由于消息队列是异步操作，在数据一致性上只能保证数据的最终一致性。 若多实时性要求较高的业务的话，事务消息是不一致的。但对实时性不高的系统可以酌情处理

如何确保消息不会丢失

目前消息队列都提供了非常完善的消息可靠性保护机制，完全可以做到在消息传递过长中，及时发生网络中端或者硬件故障，也能保证消息的可靠性传递，不丢消息

检测消息丢失的方法

• 利用消息队列的有序性来验证消息是否丢失。

在消息生产者端，给每个消息附加一个连续递增的序号，然后在消息消费端检查（一般都有拦截器机制，不会侵入代码）这个序号的连续性。若检测到不连续的消息，则可通过缺失的序号判断丢了哪个消息。注意Kafka 和RocketMQ并不能保证 topic 上的严格顺序，so要指定分区（队列）

• 确保消息的可靠投递

  • 生产阶段：在这个阶段，从消息在Producer 创建出来，经过网络传输发送到Broker端

    • 正确处理返回值 与 异常

  • 存储阶段：在这个阶段，消息在Broker端存储，如果是集群，消息会在这个阶段被复制到其他的副本上

    • 信息持久化到磁盘

    • 如果是集群部署的话，消息要达到多数节点（多副本机制）

  • 消费阶段：在这个阶段，Consumer从Broker 上拉取消息，经过网络传输发送到Cunsumer上

    • 消费端的逻辑处理完后及时响应ACK。不要在收到消息后就立即发送ACK

 

如何处理消费过程中的重复消息

消息重复的情况是必然的。在MQTT协议中，给处理三种传递消息的服务质量标准。从低到高依次是:

1. At most once :至多一次，在消息传递过程中，对多会被送达一次。也就是说，没什么消息可靠性保证，允许丢消息。使用场景如对可靠性不高的监控，允许少量数据丢失

2. At least once :至少一次，在消息传递时，至少会被送达一次，也就是说，不允许丢消息，但是允许有少量的重复消息出现 （大多数都是实现了它）

3. Exactly once：恰好一次，消息传递时，只会被送达一次，不允许也丢失不允许重复，这个是***的。

用幂等性解决重复消息问题

1. 利用数据库唯一约束实现幂等

2. 利用状态机、version 来实现幂等

3. 记录并检查操作（适用范围广） ： 如何check ？ 可能会引入更多的问题。。。

 

消息积压了该如何处理

一般来说 是 ： 要么生产变快了，要么消费变慢了

• 优化性能避免消息积压

  • 发送端性能优化（实际上与消息积压关系不大）。 准备数据、序列化消息、构造请求、网络耗时、Broker处理消息延迟

  • 消费端性能优化。（一般消费端的消费能力要大于生产端的） 批量处理。。。

    • 增加消费消费端实例。（同样的扩充相应的队列（分区），确保队列与消费者的实例数是相等的 ）

    • 检查是不是消费失败从而导致一条消息反复消费

    • 检查是不是消费者触发了死锁或者卡死在某些资源

消费端是否可以通过批量消费的方式来提升消费性能？

1. 要求消费端能够处理或者开启多线程进行单条处理

2.批量消费一单某条数据消费失败会导致整批数据重复消费

3.对实时性要求不高，批量消费需要Broker积累到一定数据才会发送到Consumer，会使单次消费消息的耗时变长