消息投递分为两个部分一是生產者对Broker的消息投递，二是Broker对消费者的消息投递 生产者需要保证消息正确的投递到了Broker, Broker保证每个消息至少消费一次。

1.事务(同步性能差)

2.confirm 确认機制，包含三种模式

3.消费的消息确认包括三种模式

      (5)如果已投递未确认的消息在指定时间内未收到消息确认重新投递到消息队列中。

    (1)发送half消息消息状态为half状态，消费者看不见（确认MQ还活着,且将消息发送的半消息队列）

2.事务补偿流程对一直没有进行commit/rollback的消息，回调你的系统接口

   (3)如果16次都无法处理完成，这时候就需要一个队列叫做 死信队列

   (4)我们可以单独对死信队列的消息进行单独处理，比如单独开一个后囼线程进行订阅处理。

      确保一个事务中发送的多条消息要么都成功，要么都失败没有反查机制。Kafka的这种事务机制单独来使用的场景不多，更多的情况下是被用来配合Kafka幂等进制来实现Kafka的 Exactly Once

      通常理解消费队列的Exactly Once，是指消息从生产者发送到Broker然后消费者从Broker拉取消息，进行消费这个过程确保每个消息恰好传输一次，不重不丢

      Kafka解决的是在流计算中，用Kafka作为数据源并且将计算结果保存到Kafa这种场景下，数据從Kafka的某个主题中消费在计算集群中计算，在把计算结果保存在Kafka的其他主题中这样的过程中，保证每条消息恰好计算一次确保计算结果正确。

1.RabbitMQ提供事务及confirm机制实现生产者的投递保证并通过消费确认机制实现消费者至少消费一次。

2.RocketMQ通过half消息即事务补偿流程实现生产者投遞的保证消费确认ACK并不会删除消息，只是提交消费进度NACK时，消息会进入重试队列

3.Kafka通过事务机制实现生产者的投递保证，消费者在确認消费时提交消费位移

2.《深入理解Kafka：核心设计与实践原理》