上一讲【RocketMQ】消息的拉取消息消费当RocketMQ进行消息消费的时候，是通过ConsumeMessageConcurrentlyService的submitConsumeRequest方法，将消息提交到线程池中进行消费，具体的处理逻辑如下：如果本次消息的个数小于等于批量消费的大小consumeBatchSize，构建消费请求ConsumeRequest，直接提交到线程池中进行消费即可如果本次消息的个数大于批量消费的大小consumeBatchSize，说明需要分批进行提交，每次构建consumeBatchSize个消息提交到线程池中进行消费如果出现拒绝提交的异常，调用submitC
上一讲【RocketMQ】消息的拉取消息消费当RocketMQ进行消息消费的时候，是通过ConsumeMessageConcurrentlyService的submitConsumeRequest方法，将消息提交到线程池中进行消费，具体的处理逻辑如下：如果本次消息的个数小于等于批量消费的大小consumeBatchSize，构建消费请求ConsumeRequest，直接提交到线程池中进行消费即可如果本次消息的个数大于批量消费的大小consumeBatchSize，说明需要分批进行提交，每次构建consumeBatchSize个消息提交到线程池中进行消费如果出现拒绝提交的异常，调用submitC
关于producer到comsuner全流程，可以参考文章：【打怪升级】【rocketMq】如何保证消息顺序消费 在rocket4.X版本中，其实所有的生产者都是client，对应的其实就是MQProducer具体的实现，主要分为DefaultMQProducer和TransactionMQProducer。producer启动 首先我们看一下MQProducer的继承关系： 其中，MQAdmin是上层一些基础方法的抽象，例如创建topic、查询message、查询对应最大最小消费点位； ClientConfig主要是一些基本的客户端公共配置； 我们可以看到默认提供的produc
关于producer到comsuner全流程，可以参考文章：【打怪升级】【rocketMq】如何保证消息顺序消费 在rocket4.X版本中，其实所有的生产者都是client，对应的其实就是MQProducer具体的实现，主要分为DefaultMQProducer和TransactionMQProducer。producer启动 首先我们看一下MQProducer的继承关系： 其中，MQAdmin是上层一些基础方法的抽象，例如创建topic、查询message、查询对应最大最小消费点位； ClientConfig主要是一些基本的客户端公共配置； 我们可以看到默认提供的produc
大家好，我是君哥。今天来聊一聊RocketMQ5.0中的Proxy。RocketMQ5.0为了更好地拥抱云原生，引入了无状态的Proxy模块，新的架构图如下：引入Proxy模块后，Proxy承担了协议适配、权限管理、消息管理等计算功能，Broker则更加专注于存储。这样存储和计算相分离，在云原生环境下可以更好地进行资源调度。1、Proxy介绍RocketMQ5.0 把客户端的部分功能下沉到Proxy，Proxy承接了之前 客户端的计算能力，客户端变得更加轻量级。（1）NameServer从上面的架构图可以看到，Producer/Consumer不再需要注册到NameServer，这一部分功能下
大家好，我是君哥。今天来聊一聊RocketMQ5.0中的Proxy。RocketMQ5.0为了更好地拥抱云原生，引入了无状态的Proxy模块，新的架构图如下：引入Proxy模块后，Proxy承担了协议适配、权限管理、消息管理等计算功能，Broker则更加专注于存储。这样存储和计算相分离，在云原生环境下可以更好地进行资源调度。1、Proxy介绍RocketMQ5.0 把客户端的部分功能下沉到Proxy，Proxy承接了之前 客户端的计算能力，客户端变得更加轻量级。（1）NameServer从上面的架构图可以看到，Producer/Consumer不再需要注册到NameServer，这一部分功能下
全局有序在RocketMQ中，如果使消息全局有序，可以为Topic设置一个消息队列，使用一个生产者单线程发送数据，消费者端也使用单线程进行消费，从而保证消息的全局有序，但是这种方式效率低，一般不使用。局部有序假设一个Topic分配了两个消息队列，生产者在发送消息的时候，可以对消息设置一个路由ID，比如想保证一个订单的相关消息有序，那么就使用订单ID当做路由ID，在发送消息的时候，通过订单ID对消息队列的个数取余，根据取余结果选择消息队列，这样同一个订单的数据就可以保证发送到一个消息队列中，消费者端使用MessageListenerOrderly处理有序消息，这就是RocketMQ的局部有序，保
全局有序在RocketMQ中，如果使消息全局有序，可以为Topic设置一个消息队列，使用一个生产者单线程发送数据，消费者端也使用单线程进行消费，从而保证消息的全局有序，但是这种方式效率低，一般不使用。局部有序假设一个Topic分配了两个消息队列，生产者在发送消息的时候，可以对消息设置一个路由ID，比如想保证一个订单的相关消息有序，那么就使用订单ID当做路由ID，在发送消息的时候，通过订单ID对消息队列的个数取余，根据取余结果选择消息队列，这样同一个订单的数据就可以保证发送到一个消息队列中，消费者端使用MessageListenerOrderly处理有序消息，这就是RocketMQ的局部有序，保
RocketMQ优异的性能表现，必然绕不开其优秀的存储模型。这篇文章，笔者按照自己的理解,尝试分析RocketMQ的存储模型，希望对大家有所启发。1整体概览首先温习下RocketMQ架构。整体架构中包含四种角色:Producer：消息发布的角色，Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。Consumer：消息消费的角色，支持以push推，pull拉两种模式对消息进行消费。NameServer：名字服务是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper，支持Broker的动态注册与发现。Br
RocketMQ优异的性能表现，必然绕不开其优秀的存储模型。这篇文章，笔者按照自己的理解,尝试分析RocketMQ的存储模型，希望对大家有所启发。1整体概览首先温习下RocketMQ架构。整体架构中包含四种角色:Producer：消息发布的角色，Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。Consumer：消息消费的角色，支持以push推，pull拉两种模式对消息进行消费。NameServer：名字服务是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper，支持Broker的动态注册与发现。Br
