rocketmq

一、Broker 介绍 Broker 是 RocketMQ 的核心,大部分 "重量级" 工作都是由 Broker 完成的，如： * 接收 Producer 发送的消息 * 处理 Consumer的消费消息请求 * 消息的持久化存储 * 消息的 HA 机制 * 服务器过滤功能 ...... 二、消息的存储结构 RocketMQ 的消息存储由 ConsumeQueue 和 CommitLog 配合完成。 2.1 ConsumeQueue * ConsumeQueue 是消息的逻辑队列，类似数据库的索引文件，存储着指向物理存储的地址。每个 Topic 下的每个 MessageQueue 都有一个对应的 ConsumeQueue 文件。 * 文件所在路径： ${$storeRoot}\consumequeue\${topicName}\${queueId}\${fileName}。 2.2 CommitLog * CommitLog 是物理存储文件,每个 Broker 上的 CommitLog 被本机器所有的　ConsumeQueue 共享。 * 文件所在路径：${user.homt}\store\${commitlog}\${fileName}。 2.3 存储顺序 RocketMQ 通过一些机制来保证，尽量向 CommitLog 中顺序写入，但是可以随机读取。 三、高可用机制

一、NameSever介绍 1.1 NameSever是什么 NameServer 的主要功能是为整个 MQ 集群提供服务协调与治理，具体就是记录维护 Topic 、 Broker 的信息，及监控 Broker 的运行状态，为 client 提供路由能力。 NameServer 之间没有信息同步操作，主要通过 Broker 轮询修改信息。 * Name Server 是一个无状态节点，可集群部署，节点之间无任何信息同步; * Broker 分为 Master 与 Slave，它们是一对多的关系，一个 Master 可以对应多个 Slave。 每个 Broker 与 Name Server 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 Name Server; * Producer与 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Broker Master 建立长连接，且定时向 Master Broker 发送心跳。Producer 完全无状态，可集群部署; * Consumer 与 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Master

现公司选择RocketMQ作为消息队列服务器，用于异步处理，应用解耦，流量削锋和消息通讯四个场景。RocketMQ特性参见： Rocketmq整体分析 。 PS: http://blog.csdn.net/konglongaa/article/details/52208273 http://www.coin163.com/good/blog/mq.html 来源： https://www.cnblogs.com/phpdragon/p/6741526.html

3 月，跳不动了？>>> 目录 1、RocketMQ DLedger 多副本日志复制流程图 1.1 RocketMQ DLedger 日志转发(append) 请求流程图 1.2 RocketMQ DLedger 日志仲裁流程图 1.3 RocketMQ DLedger 从节点日志复制流程图 2、RocketMQ DLedger 多副本日志复制实现要点 2.1 日志编号 2.2 追加与提交机制 2.3 日志一致性如何保证 上一篇 源码分析 RocketMQ DLedger(多副本) 之日志复制(传播) ，可能有不少读者朋友们觉得源码阅读较为枯燥，看的有点云里雾里，本篇将首先梳理一下 RocketMQ DLedger 多副本关于日志复制的三个核心流程图，然后再思考一下在异常情况下如何保证数据一致性。 @(本节目录) 1、RocketMQ DLedger 多副本日志复制流程图 搜小说 https://shupu.org/ 1.1 RocketMQ DLedger 日志转发(append) 请求流程图 1.2 RocketMQ DLedger 日志仲裁流程图 1.3 RocketMQ DLedger 从节点日志复制流程图 2、RocketMQ DLedger 多副本日志复制实现要点 上图是一个简易的日志复制的模型：图中客户端向 DLedger 集群发起一个写请求，集群中的 Leader

最近看了 @JavaGuide 发布的一篇 『面试官问我如何保证Kafka不丢失消息?我哭了！』 ，这篇文章承接这个主题，来聊聊如何保证 RocketMQ 不丢失消息。 0x00. 消息的发送流程 一条消息从生产到被消费，将会经历三个阶段： 生产阶段，Producer 新建消息，然后通过网络将消息投递给 MQ Broker 存储阶段，消息将会存储在 Broker 端磁盘中 消息阶段， Consumer 将会从 Broker 拉取消息 以上任一阶段都可能会丢失消息，我们只要找到这三个阶段丢失消息原因，采用合理的办法避免丢失，就可以彻底解决消息丢失的问题。 0x01. 生产阶段 生产者（Producer） 通过网络发送消息给 Broker，当 Broker 收到之后，将会返回确认响应信息给 Producer。所以生产者只要接收到返回的确认响应，就代表消息在生产阶段未丢失。 RocketMQ 发送消息示例代码如下： DefaultMQProducer mqProducer=new DefaultMQProducer("test"); // 设置 nameSpace 地址 mqProducer.setNamesrvAddr("namesrvAddr"); mqProducer.start(); Message msg = new Message("test_topic" /* Topic

Astrotrain概述 Astrotrain是基于阿里巴巴开源项目RocketMQ进行封装的分布式消息中间件系统，提供集群环境下的消息生产和消费功能。 RocketMQ介绍 RocketMQ的物理部署结构 Name Server 是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。所有的主题和broker节点信息都由Name Server进行维护。 Broker 是主要的功能单元，处理主题的存储和消费逻辑，Broker会定时同步所有信息至Name Server。 一类Producer的集合名称，这类Producer通常发送一类消息，且发送逻辑一致。 一类Consumer的集合名称，这类Consumer通常消费一类消息，且消费逻辑一致。Consumer群组内多应用之间消息消费是竞争关系，Consumer群组之间是共享消费，这点非常重要。 RocketMQ存储特点 Broker上绑定具体的Topic。 Topic下有多个物理存储队列(Queue)，所有存储队列都会存储消息，一个消息只会存储一份。Topic可以分布在不同Broker上。 存储队列的选择决定了消费的特性，如果只读写一个队列，那么消费就是顺序的了，否则会是无序的。 消费者Push和Pull的区别 Push模式下的消息是由事件触发，有消息到达时监听器会被调用(MessageListener)。

1. 什么是RocketMQ？ 　　 　　 　　是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点。 　　Producer、Consumer、队列都可以分布式。 　　 Producer 吐一些队列轮流収送消息，队列集合称为Topic，Consumer 如果做广播消费，则一个consumer 　　实例消费返个Topic 对应的所有队列，如果做集群消费，则多个Consumer 实例平均消费返个topic 对应的 　　队列集合。 　　能够保证严格的消息顺序 　　提供丰富的消息拉叏模式 　　高效的订阅者水平扩展能力 　　实时的消息订阅机制 　　亿级消息堆积能力 　　较少的依赖 　　RocketMQ作为阿里巴巴的两大分布式技术之一，是一款纯java、分布式、队列模型的开源消息中间件，他参考了Java的JMS规范，但是它并没有遵循JMS的规范，经历了淘宝双十一的洗礼，在功能和性能上据说是远超ActiveMQ。 2. RocketMQ发展史 　　1. Metaq(Metamorphsis) 1.x 　　　由开源社区killme2008维护，开源社区非常活跃。 　　　github地址：https://github.com/killme2008/Metamorphosis 　　2. Metaq 2.x 　　　于2012年10月份上线，在淘宝内部被广泛使用。 　　3.

1. 事务消息原理图 　RocketMQ除了支持普通消息，顺序消息之外，还支持了事务消息。 1. 什么是分布式事务？ 　　分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2. RocketMQ中分布式事务的使用 　　在RocketMQ中分布式事务执行过程分为三个阶段，RocketMQ第一阶段发送 Prepared消息 时，会拿到消息的地址，第二阶段执行本地事物，第三阶段通过第一阶段拿到的地址去访问消息，并修改消息的状态。当RocketMQ确认消息发送失败时，RocketMQ会定期扫描消息集群中的事物消息，如果发现了 Prepared消息 ，它会向消息发送端(生产者)确认，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。 　　实现方式： 　　Producer实现： package com.wangx.rocketmq.transaction; import org.apache.rocketmq.client

简介： RocketMQ（Metaq3.0版本改名）是一款分布式队列模型的消息中间件 特点如下： 1.保证消息顺序 2.支持消息拉取模式 3.高效的订阅者水平和扩展能力 4.实时的消息订阅机制 5.亿级的消息堆积能力 RocketMQ低延迟、高可靠、可伸缩、易于使用的消息中间件。具有以下特性： 1.强调集群无单点，可扩展，任意一点高可用，水平可扩展。 2.海量消息堆积能力，且堆积后写入低延迟。 3.支持上万个队列。（api丰富） 4.消息失败重试机制。 5.消息可查询。 6.开源社区活跃，成熟度高（双十一访问压力）。-- oceanbase 7.支持发布/订阅（Pub/Sub）和点对点（P2P）消息模型 8.在一个队列中可靠的先进先出（FIFO）和严格的顺序传递 9.支持拉（pull）和推（push）两种消息模式 10.单一队列百万消息的堆积能力 11.支持多种消息协议，如 JMS、MQTT 等 12.分布式高可用的部署架构,满足至少一次消息传递语义 13.提供 docker 镜像用于隔离测试和云集群部署 14.提供配置、指标和监控等功能丰富的 Dashboard 专业术语 Producer 消息生产者，生产者的作用就是将消息发送到 MQ，生产者本身既可以产生消息，如读取文本信息等。也可以对外提供接口，由外部应用来调用接口，再由生产者将收到的消息发送到 MQ。 Producer

1. Exactly Only Once 　　(1). 发送消息阶段，不允许发送重复的消息 　　(2). 消费消息阶段，不允许消费重复的消息。 　　只有以上两个条件都满足情况下，才能认为消息是“Exactly Only Once”，而要实现以上两点，在分布式系统环 　　境下，不可避免要产生巨大的开销。所以RocketMQ 为了追求高性能，并不保证此特性，要求在业务上进行去重，也就是说消费消息要做到幂等性。RocketMQ 虽然不能严格保证不重复，但是正常情况下很少会出现重复发送、消 费情况，只有网络异常，Consumer 启停等异常情况下会出现消息重复。 　　此问题的本质原因是网络调用存在不确定性，即既不成功也不失败的第三种状态，所以才产生了消息重复性问 题。 2. 重复消费的原因 　　在于回馈机制。正常情况下，消费者在消费消息时候，消费完毕后，会发送一个ACK确认信息给消息队列(broker)，消息队列(broker)就知道该消息被消费了，就会将该消息从消息队列中删除。 不同的消息队列发送的确认信息形式不同,例如RabbitMQ是发送一个ACK确认消息，RocketMQ是返回一个CONSUME_SUCCESS成功标志，kafka实际上有个offset的概念。 　　造成重复消费的原因?，就是因为网络原因闪断，ACK返回失败等等故障，确认信息没有传送到消息队列