角色 broker：节点，就是你看到的机器，也就是一个kafka服务 provider：生产者，发消息的 consumer：消费者，读消息的 zookeeper：信息/注册中心，记录kafka的各种信息的地方 controller：其中的

1. 应用场景1.1 kafka场景Kafka最初是由LinkedIn公司采用Scala语言开发，基于ZooKeeper，现在已经捐献给了Apache基金会。目前Kafka已经定位为一个分布式流式处理平台，它以 高吞吐、可持久化、可

业务实现消费回调的时候，当且仅当此回调函数返回ConsumeConcurrentlyStatus.CONSUME_SUCCESS ，RocketMQ才会认为这批消息（默认是1条）是消费完成的 如果这时候消息消费失败，例如数据库异常，余额不足

1. 为什么从业务上保证1.1 消息丢失问题RocketMQ虽然号称消息不会丢失，但是还是有几率存在MQ宕机以及rocketMQ使用上的问题可能存在消息丢失等，对于类似于支付确认的消息一般来说是一条都不允许丢失的 1.2 消息幂等性在网络环

文件刷盘机制RocketMQ 的消息是存储在磁盘上的，这样做有两个优点： 保证断电后恢复 让存储的消息量超出内存的限制 RocketMQ 存储与读写是基于 JDK NIO 的内存映射机制，具体使用 MappedByteBuffer（基于

目前的MQ中间件从存储模型来，分为需要持久化和不需要持久化的两种模型，现在大多数的是支持持久化存储的，比如ActiveMQ、RabbitMQ、Kafka、RocketMQ。ZeroMQ却不需要支持持久化存储而业务系统也大多需要MQ有持久存储

RocketMQ的死信队列介绍就没有RabbitMQ那么复杂。在这篇文章会简单的介绍一下RocketMQ死信队列的特点。 死信消息特性 不会再被消费者正常消费 有效期与正常消息相同，均为 3 天，3 天后会被自动删除。故死信消息应在产生的

1. 生产端保障生产端保障需要从以下几个方面来保障 使用可靠的消息发送方式 注意生产端重试 生产禁止自动创建topic 1.1 ⚠消息发送保障1.1.1同步发送发送者向MQ执行发送消息API时，同步等待，直到消息服务器返回发送结果，会在

​ RocketMQ的消息投递分分为两种：一种是生产者往MQ Broker中投递；另外一种则是MQ broker 往消费者 投递(这种投递的说法是从消息传递的角度阐述的，实际上底层是消费者从MQ broker 中Pull拉取的)。 Rock

顺序类型无序消息无序消息也指普通的消息，Producer 只管发送消息，Consumer 只管接收消息，至于消息和消息之间的顺序并没有保证。 Producer 依次发送 orderId 为 1、2、3 的消息 Consumer 接到的消