之乎者也·的博客

从messageQueue 拉取消息，进行消费。Rocketmq 源码内部，拉模式消费使用的是DefaultMQPullConsumer/DefaultLitePullConsumerImpl，核心逻辑是先拿到需要获取消息的Topic对应的队列，然后依次从队列中拉取可用的消息。注意，拉取的消息，放在另一个队列 messageQueue 缓存，拉取之前，会进行流控检查，如果这个队列满了（>1000个消息或者 >100M内存） 则延迟50ms再拉取， 当然，下一次执行拉取之前，同样也会进行流控检查。

一条订单产生的三条消息：订单创建、订单付款、订单完成。上面三消息是有序的，消费时要按照这个顺序依次消费才有意义，但是不同的订单之间这些消息是可以并行消费的。什么是顺序消息？顺序消息是指对于一个指定的 Topic ，消息严格按照先进先出（FIFO）的原则进行消息发布和消费，即先发布的消息先消费，后发布的消息后消费。顺序消息分为两种：分区有序消息全局有序消息我们做一个关于顺序消费的总结：通过4把锁的机制，消息队列 messageQueue 的数据都会被消费者实例单线程的执行消费；

而对于局部有序的要求，只需要将有序的一组消息都存入同一个MessageQueue里，这样MessageQueue的FIFO设计天生就可以保证这一组消息的有序。而MessageQueue是RocketMQ存储消息的最小单元，他们之间的消息都是互相隔离的，在这种情况下，是无法保证消息全局有序的。而这时候，对消息的顺序就有一定的要求了。然后把所有消费者节点的目标Topic转向新的Topic，并紧急上线一组新的消费者，只负责转储，就是消费老Topic中的积压消息，并转储到新的Topic中，这个速度是可以很快的。

默认情况下，消息只要到了 Broker 端，将会优先保存到内存中，然后立刻返回确认响应给生产者。这种方式减少 I/O 次数，可以取得更好的性能，但是如果发生机器掉电，异常宕机等情况，消息还未及时刷入磁盘，就会出现丢失消息的情况。以上任一阶段都可能会丢失消息，我们只要找到这三个阶段丢失消息原因，采用合理的办法避免丢失，就可以彻底解决消息丢失的问题。若想保证 Broker 端不丢消息，保证消息的可靠性，我们需要将消息保存机制修改为同步刷盘方式，即消息。为了进一步提高消息的可靠性，我们可以采用同步的复制方式，

消费者中我们注册了一个监听器回调函数，当Consumer获取消息后，就会交给我们的回调函数来进行处理。如果处理完了，就返回一个ConsumeConcurrentlyStatus.CONSUME_SUCCESS，提交这批消息的offset到broker去，然后继续从broker获取下一批消息来进行处理。如果上面代码回调函数中，对一批消息处理的时候，数据库宕机了就不能再能返回CONSUME_SUCCESS，如果你返回的话，下一次就会处理下一批消息，但是这批消息其实没处理成功，此时必然导致这批消息就丢失了；

基本概念：延迟消息是指生产者发送消息发送消息后，不能立刻被消费者消费，需要等待指定的时间后才可以被消费。场景案例：用户下了一个订单之后，需要在指定时间内(例如30分钟)进行支付，在到期之前可以发送一个消息提醒用户进行支付。

一般最好把去重操作直接放在了消费端，消费端处理消息的业务逻辑保持幂等性。消费者收到消息后，从消息中获取消息标识写入到Redis（分布式锁）或数据库（标识作为表唯一索引插入一条记录），当再次收到该消息时就不作处理。在broker端对Queue加锁（synchronized），Consumer监听的Queue存在已投递但未收到ack且未超时的消息，不允许获取锁，直到该Queue投递的消息全部ack或者消费超时，才允许新的Consumer获取锁，拉取消息。

在2主2从同步复制场景下，当生产者向broker集群中的某个broker的master节点的队列中写入消息之后，只有当消息被同步到该broker的slave节点之后，broker集群才会给生产者发送ack消息。同一个消费者分组对于不同主题的订阅也相互独立如下图所示，消费者分组Group A订阅了两个主题Topic A和Topic B，对于Group A中的消费者来说，订阅的Topic A为一个订阅关系，订阅的Topic B为另外一个订阅关系，且这两个订阅关系互相独立，可以各自定义，不受影响。

在MySpringcloudRocketmqProducerApplication 添加 @EnableBinding(Source.class) 注解。然后创建生产者。@Component@Resource// 封装消息头// 创建消息对象// 发送消息在MySpringcloudRocketmqConsumerApplication 类上添加 @EnableBinding(Sink.class)注解。@Component。

上一篇文章我们介绍了RocketMQ集群的搭建，这篇文章将主要使用RocketMQ测试下简单消息。本文详细介绍了简单消息里的同步消息，异步消息和单向消息。他们的区别主要是生产者发布消息时的区别。另外，简单消息的消费是没有顺序的。顺序消息指的是消费者在消费消息时，按照生产者发送消息的顺序进行消费。即先发送的先消费【FIFO】。顺序消息分为 全局顺序消息和局部顺序消息。全局顺序消息就是全局使用一个queue。局部顺序消息就是 有顺序依赖的消息放在同一个queue中，多个queue并行消费。

RocketMQ是阿里巴巴开源的一款消息队列，它具有低延迟，高吞吐量，高可靠性等特点。目前，RocketMQ在阿里巴巴内部有着广泛的应用，经历多次双十一的洗礼，RocketMQ的可靠性非常高。前文对RocketMQ的基本概念做了一些介绍，本文将小试牛刀一下。本文主要讲述如何通过docker来部署单机版的RocketMQ。部署RocketMQ的最核心是部署nameserver以及部署broker。然后，我们还需要安装可视化界面，在RocketMQ的官网上提供的是基础的安装方式。