Apache RocketMQ

回复“ 1024 ”获取 2000+ 道互联网大厂面试题 如何把开源项目用好，很大程度上是由学习路径决定的： a. fork下来，起一个demo，上一个测试环境，遇到问题再去社区提问或找些实践文章； b. 把官方文档通读一遍，理解下产品、特点和应用场景； c. 先看一遍源代码，理解清楚其中的代码逻辑； d. 看源代码太费劲，找本社区推荐的书系统的梳理下； 本文来自 Apache RocketMQ 的资深用户丁威，他和 MyCat 的核心开发者周继锋合著了《RocketMQ技术内幕：架构设计与实现原理》一书， 目的是希望用图解的方式梳理 RocketMQ的核心原理 ，包括 RocketMQ Topic 的路由注册与剔除机制、消息发送高可用设计、消息存储文件设计、并发消息拉取与消息消费流程、主从同步(HA)、事务消息基本实现原理等，帮助开发者在使用 RocketMQ 的同时，还能对其核心原理了然于心 。 Topic 的路由机制 介绍路由注册机制之前，先简单看下 RocketMQ 的整体架构： Producer： 消息生产者，用于向消息服务器发送消息； NameServer： 路由注册中心； Broker： 消息存储服务器； Consumer： 消息消费者，该流程图中未涉及； 联通性： A. NameServer 之间互不通信，无法感知对方的存在。 B. Producer 生产者与

延迟消息是实际开发中一个非常有用的功能，本文第一部分从整体上介绍秒级精度延迟消息的实现思路，在第二部分结合RocketMQ的延迟消息实现，进行细致的讲解，点出关键部分的源码。第三步介绍延迟消息与消息重试的关系。 1 延迟消息介绍 基本概念：延迟消息是指生产者发送消息发送消息后，不能立刻被消费者消费，需要等待指定的时间后才可以被消费。 场景案例：用户下了一个订单之后，需要在指定时间内(例如30分钟)进行支付，在到期之前可以发送一个消息提醒用户进行支付。 一些消息中间件的Broker端内置了延迟消息支持的能力，如： NSQ： 这是一个go语言的消息中间件，其通过内存中的优先级队列来保存延迟消息，支持秒级精度，最多2个小时延迟。Java中也有对应的实现，如ScheduledThreadPoolExecutor内部实际上也是使用了优先级队列。 QMQ： 采用双重时间轮实现。 https://www.toutiao.com/i6851807550690722312/ RabbitMQ： 需要安装一个rabbitmq_delayed_message_exchange插件。 RocketMQ： RocketMQ 开源版本延迟消息临时存储在一个内部主题SCHEDULE_TOPIC_XXXX中， 不支持任意时间精度，支持特定的 level，例如定时 5s，10s，1m 等。

序 本文主要研究一下rocketmq-client-go的PullConsumer PullConsumer rocketmq-client-go-v2.0.0/consumer/pull_consumer.go type PullConsumer interface { // Start Start() // Shutdown refuse all new pull operation, finish all submitted. Shutdown() // Pull pull message of topic, selector indicate which queue to pull. Pull(ctx context.Context, topic string, selector MessageSelector, numbers int) (*primitive.PullResult, error) // PullFrom pull messages of queue from the offset to offset + numbers PullFrom(ctx context.Context, queue *primitive.MessageQueue, offset int64, numbers int) (*primitive.PullResult, error)

rocketmq 的注册中心是基于 NameService 的，而 kafka 的注册中心是基于 zk 的 NameService 没有 zk 的功能丰富，从组件上来说它更轻量级 NameService 没有监听机制，它通过心跳来维护自己与 broker 之间的联系 Zk 的实现是通过一个持久节点 locker 节点来创建临时节点 znode ，并且 zk 的特性是是强一致性的，生成的 znode 是有序自增的 Zk 通过创建监听比自己小的节点，和惊群效应实现 NameService 存储的是 topic 和 broker 的映射关系，数据存储不复杂 Kafka 在数据可靠性上不如 rocketmq Kafka 支持异步刷盘和异步复制， rocketmq 支持同步异步刷盘、同步异步复制 数据传输量上 kafka 优于 rocketmq Kafka 的数据传输是百万级别的，单点的 rocketmq 的传输速率是 7 万左右的水平 Kafka 数据传输效率高的一个特点是基于磁盘顺序写 第二个特点 kafka 在发送消息到 broker 时，是基于一个批量发送的理念（巧妙的利用了磁盘 I/O 的原理，减少磁盘 IO 次数，提高效率）。这样的好处是一次发送的量大 坏处是增大了消息丢失的风险，并且在发送前会堆积大量的缓存，容易对 gc 造成压力 Kafka 和 rocketmq

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 简述 消息中间件作为分布式系统的重要成员，各大公司及开源均有许多解决方案。目前主流的开源解决方案包括RabbitMQ、RocketMQ、Kafka、ActiveMQ等。消息这个东西说简单也简单，说难也难。简单之处在于好用方便，接入简单使用简单，异步操作能够解耦系统间的依赖，同时失败后也能够追溯重试。难的地方在于，设计一套可以支撑业务的消息机制，并提供高可用架构，解决消息存储、消息重试、消息队列的负载均衡等一系列问题。然而难也不代表没有方法或者“套路”，熟悉一下原理与实现，多看几个框架的源码后多总结势必能找出一些共性。 消息框架大同小异，熟练掌握其原理、工作机制是必要的。就拿用的比较多的RocketMQ为引，来说说消息引擎的设计与实现。阿里的消息引擎经过了从Notify到Napoli、再到MetaQ三代的发展，现在已经非常成熟，在不同部门的代码中现在没准都还可以从代码里看到这一系列演进过程。当前的Apache RocketMQ 就是阿里将MetaQ项目捐赠给了Apache基金会，而内部还是沿用MetaQ的名称。 首先诠释几个消息相关的基本概念 每个消息队列都必须建立一个Topic。 消息可以分组，每个消息队列都至少需要一个生产者Producer和一个消费者Consumer

1. RocketMQ 角色介绍 四个角色 Producer：消息生产者 Consumer：消费者 Broker：MQ 服务，负责接收、分发消息 NameServer：负责 MQ 服务之间的协调 2. RocketMQ 架构方案 NameServer Cluster NameServer 提供轻量级服务发现和路由。 每个名称服务器记录完整的路由信息，提供相应的读写服务，并支持快速存储扩展。 3. RocketMQ 集群部署配置 Broker 配置文件说明 # 所属集群名字 brokerClusterName=DefaultCluster # broker 名字，注意此处不同的配置文件填写的不一样 brokerName=broker-a|broker-b # 0 表示 Master，>0 表示 Slave brokerId=0 # nameServer 地址，分号分割 namesrvAddr=10.10.1.31:9876;10.10.1.32:9876 # 在发送消息时，自动创建服务器不存在的 topic，默认创建的队列数 defaultTopicQueueNums=4 # 是否允许 Broker 自动创建 Topic，建议线下开启，线上关闭 autoCreateTopicEnable=true # 是否允许 Broker 自动创建订阅组，建议线下开启，线上关闭

跟大家分享几个好消息： 在今天“2020 可信云线上峰会”上，中国信通院公布了多项可信云认证的评估结果。 阿里云原生在容器平台安全能力、函数及服务、分布式消息队列服务、可信云服务最佳实践（服务云）、可信云技术最佳实践（容器及管理）等评选中获得可信云认证！ 多年来，阿里巴巴作为云原生领域的先行者、实践者，基于自身累积多年的最佳实践，对社区赋能，为企业提供普惠的云原生产品服务。在这次可信云评选中，阿里云原生更是拿到5项大奖，从技术到实践，以最全面的技术影响力推动云原生进入新的阶段！ 下面我们来一一揭开这些奖项！ NO.1：阿里云 49 个满分，获得可信云容器安全能力先进级认证 今天，信通院发布了国内云厂商的容器安全评估结果： 阿里云容器服务 ACK 和容器镜像服务 ACR 荣获最高级别先进级可信云安全能力认证，特别是在最小化***面，二进制镜像验签名，密文的 BYOK 加密等能力上国内领先，达到国际先进水平。 早在 2018 年，阿里云容器服务团队率先提出了“端到端的企业级安全能力”概念，并推出立体式的端到端云原生安全架构，从三个层面来解决安全问题： 最底层依托于阿里云平台已有的安全能力，包括物理安全，硬件安全，虚拟化安全和云产品安全能力; 中间是容器基础设施安全层，基于最小化***面原则，提供了包括访问控制，权限收敛，配置加固和身份管理等重要的底座安全能力；同时针对凭证下发，证书

前言 市面上消息队列中间件管理有蛮多的，如：ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ，但我最先接触的可能就是 Kafka 了，不过那时候为了用，只知道部分实用性的东西，这两天稍稍花了点时间看了看。 消息队列 在我看来，消息队列的出现更多的是 解耦合 ，我们不需关心数据的来处和出处，生产者和消费者可能都不知道对方是一种什么样的存在方式，而且解决了突发的 数据剧增现象 . 我在例子中曾这样实验过 线程跑一会睡眠 20ms 线程一直在跑 实验 1 的处理速度可以跟的上生产速度，offset 一直指向 end，但实验 2 生产速度大幅上升，处理速度明显跟不上，我停止生产后，几毫秒再去看，offset 才指向 end。 例子 通过例子了解的可能会更加的快，这里我使用 docker-compose 搭建的 kafka 集群 SpringBoot 和 kafka 生产者 https://github.com/tokeneros/kafka_produce... SpringBoot 和 kafka 消费者 https://github.com/tokeneros/kafka_consumt... 最后注意 ：光理论是不够的。在此顺便送大家十套2020最新JAVA架构项目实战教程及大厂面试题库，进我扣裙 ：七吧伞吧零而衣零伞 （数字的谐音

1 面试题 分布式事务了解吗？你们如何解决分布式事务问题的？ 2 考点分析 只要聊到做了分布式系统，必问分布式事务，若你对分布式事务一无所知的话，确实很坑，起码得知道有哪些方案，一般怎么来做，每个方案的优缺点是什么。 现在面试，分布式系统成了标配，而分布式系统带来的分布式事务也成了标配. 你做系统肯定要用事务，那你用事务的话，分布式系统之后肯定要用分布式事务. 先不说你搞过没有，起码你得明白有哪几种方案，每种方案可能有啥坑？ 比如TCC方案的网络问题、XA方案的一致性问题. 单块系统里的事务 分布式系统里的事务 3 XA方案也叫做两阶段提交事务方案. 举个例子，比如公司经常团建，然后一般会有个主席（就是负责组织团建的那个人）。 tb，team building，团建 第一个阶段，一般tb主席会提前问团队里的每个人，说，大家伙，下周六我们去滑雪+烧烤，去吗？ 这个时候tb主席开始等待每个人的回答，如果所有人都说ok，那么就可以决定一起去这次tb 如果这个阶段里，任何一个人回答说，我有事不去了，那么tb主席就会取消这次活动 第二个阶段，那下周六大家就一起去滑雪+烧烤了 这就是所谓的XA事务，两阶段提交. 有一个事务管理器，负责协调多个数据库（资源管理器）的事务，事务管理器先问各个数据库你准备好了吗？ 如果每个数据库都回复ok，那么就正式提交事务，在各个数据库上执行操作

记录下搭建rocketmq过程中遇到的坑：（集群机子代号这里列为：mq-a，mq-b，mq-a-s, mq-b-s） rocketmq搭建的是 双主双从 模式。三台机器，机器 a 、b 分别安装 双主 ，机器c 安装 双从 。 启动三个 nameserver，双主broker-master，双从broker-slave 服务器 rocketmq 是4.7.0版本 1. 第一个坑 - 项目rokcetmq 版本和服务器rocketmq版本没对上 ：rocketmq 双主双从 搭建完，从 github 上下载的 rocketmq管理后台，本地跑起来，能成功连上rocketmq。然后自己写了的一个demo，发下报错，报错信息如下： 后来发现是 demo项目于中 pom的 rocketmq 依赖是 4.3.0， 和服务器4.7.0 对不上，然后我项目改成了 4.7.0的版本依赖。然后就ok了 附上 provider生产者的 demo代码 和 consumer消费者 的 demo 代码： ========>>>> provider 生产者代码： public class TestProvider { public static void main(String[] args) { try { //Instantiate with a producer group name.