LO_YUN的博客

RocketMQ要保证高可用的话，可以使用主从架构，也就是将Broker分为Master Broker和Slave Broker，下面文章中的Master和Slave分别指的是Master Broker和Slave Broker与其他传统的主从架构一样，Master负责接收数据之后，再将数据同步给Slave，Master和Slave都会向NameServer注册路由信息，同时每隔30秒发送一次心...

RocketMQ消费消息有一个消费者组的概念，一个消费者组里面包含了多个消费者。消费者组有两种消费方式，一种是集群模式，消费者组内只有一个消费者能消费到Topic下的同一条数据，其余消费者则无法消费到，而另外的消费者组也可以有一个消费者能消费到这条消息，这是默认的消费模式；还有一种是广播模式，Topic下的同一条消息将会被消费者组内的所有消费者消费一遍。消息传送也有两种模式，一种是Push模式...

消息乱序也是RocketMQ中的一个常见问题，那么到底为什么会出现消息乱序呢？首先我们知道在RocketMQ的Topic中，会有多个MessageQueue作为数据分片，每个MessageQueue都会存储部分的消息，那么在生产者产生消息发送到Topic上的时候，按道理这些消息都会均匀的分布在多个MessageQueue中，假如我现在有多个消息，它们是按照顺序排列的，现在它们分布到了不同的Mes...

一般的，我们在RocketMQ处理消息的时候，可能会在消费者中使用类似下面的代码consumer.registerMessageListener(new MessageListenerConcurrently() { @Override public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msg...

消息重复消费是各个MQ都会发生的常见问题之一，在一些比较敏感的场景下，重复消费会造成比较严重的后果，比如重复扣款等。那么在什么情况下会发生RocketMQ的消息重复消费呢？当系统的调用链路比较长的时候，比如系统A调用系统B，系统B再把消息发送到RocketMQ中，在系统A调用系统B的时候，如果系统B处理成功，但是迟迟没有将调用成功的结果返回给系统A的时候，系统A就会尝试重新发起请求给系统B，...

RocketMQ作为一款消息中间件，必然少不了数据的存储，跟Kafka一样，RocketMQ也是采取的分布式存储，这样就不至于一个Broker宕机，就会产生数据丢失的问题，那么RocketMQ是如何实现分布式存储的呢？如果大家了解Kafka的话，就知道在Kafka中存在一个数据分片partition，每一个topic可以划分为多个partition，而每一个partition都只存放一部分的数据...

既然使用在项目中使用了MQ，那么就不可避免的需要考虑消息丢失问题。在一些涉及到了金钱交易的场景下，消息丢失还是很致命的。那么在RocketMQ中存在哪几种消息丢失的场景呢？先来一张最简单的消费流程图：上图中大致包含了这么几种场景：生产者产生消息发送给RocketMQRocketMQ接收到了消息之后，必然需要存到磁盘中，否则断电或宕机之后会造成数据的丢失消费者从RocketMQ中获取消...

先来一段阿里云上的官方描述了解一下RocketMQ的部署架构和各个角色的概念图中所涉及到的概念如下所述：Name Server: 是一个几乎无状态节点，可集群部署，在消息队列 MQ 中提供命名服务，更新和发现 Broker 服务。Broker：消息中转角色，负责存储消息，转发消息。分为 Master Broker 和 Slave Broker，一个 Master Broker 可以对应多...

MQ（Message Queue）是一个常用的消息中间件，在各种场景都能见到MQ的身影，其最主要的三个场景分别是异步、解耦、削峰。异步：当一个交易的链路涉及多个系统的互相调用时，系统处理完毕，返回结果的时长会比较长，用户需要等待这一段时间才能看到结果，往往体验就比较差。这时我们就可以在系统中加入MQ，系统接受用户请求之后，直接将请求发送给MQ，然后返回结果给用户，响应很快，之后的其他的系统再从M...

分布式事务常见的方案有TCC（Try-Confirm-Cancel），XA两阶段提交方案，可靠消息最终一致性方案，最大努力通知方案等等。其中可靠消息最终一致性方案主要就可以依靠RocketMQ来做，因为RocketMQ支持消息事务。先上一张图：RocketMQ 事务消息的实现步骤如下：Producer发送half message给RocketMQRocketMQ返回half messag...