rocketmq

一、最近公司在做队列的技术选型，经过调研，决定使用rocketmq作为整个架构的队列层，我们之前的公司是用RabbitMQ，集群部署参考我之前的文章： RabbitMQ集群部署 ；rocketmq集群由NameServer和Broker两种角色组成，NameServer是无状态的可以横向部署多台达到消除单点的目的；Broker分多master、多master多slave同步、多master多slave异步这三种部署方案，一般生产环境都使用的是多master多slave异步这种方案，关于这三种方案的优缺点对比如下： 多Master模式（2m-noslave） ： 一个集群无Slave，全是Master，例如2个Master或者3个Master 优点：配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢）。性能最高。 缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到受到影响。 多Master多Slave模式，异步复制（2m-2s-async） ： 每个Master配置一个Slave，有多对Master-Slave，HA采用异步复制方式，主备有短暂消息延迟，毫秒级。 优点：即使磁盘损坏，消息丢失的非常少

产生的原因：网络不可达问题。 网络超时之后我们可以做的只有两件事，1 停止（回滚，但对于系统来说影响特别大） 2 继续（另发送到别的服务消费端） 一般我们采用第二种处理方式，但是要经过网络，必然会出现消息重复问题。 最好的解决方法是： 恰好不需要——幂等操作 S * S = S (某个操作不管重复多少次，结果都一样)。 幂等消息去重： 保证有个唯一ID标记每一条消息 保证消息处理成功与去重表日志同事出现 代价：去重代价是去重日志的写入，数据校验，多台机器对去重表的维护。 ONS消息与事物转账设计难点： 如何保证消息发送与Bob账户减钱同时成功或同时失败？ 消息处理超时的解决？ 消息处理失败如何解决？ 尽量保持消息接受者的幂等性 但是对于非幂等的消息消费端：要记录日志表，内次执行时进行日志校验。 当消息接收者处理失败时，能挽回失败的方法之一是系统，但是系统回滚的开销往往是很大的。 还有一种方式是人工处理，当事件发生的概率 比 写代码挽回失败Bug的概率还要小，这样我们就需要考虑是否使用人工处理了。 利用努力送达模型，失败后再重新发往mq中，重新进行消费，尽量保证数据处理成功。努力送达模型是系统希望来进行这样的设计的。 小结： 消息系统：解耦 异步 最终一致性 并行 ONS 和其他消息系统不一样的部分：高吞吐量 高并发。 面向于失败的系统： 消息安全性， 消息堆积能力 消息吞吐量 和

https://zhuanlan.zhihu.com/p/25140744 中剖析过，consumer的每个实例是靠队列分配来决定如何消费消息的。那么消费进度具体是如何管理的，又是如何保证消息成功消费的（RocketMQ有保证消息肯定消费成功的特性（失败则重试）？ 本文将详细解析消息具体是如何ack的，又是如何保证消费肯定成功的。 由于以上工作所有的机制都实现在PushConsumer中，所以本文的原理均只适用于RocketMQ中的PushConsumer即Java客户端中的DefaultPushConsumer。 若使用了PullConsumer模式，类似的工作如何ack，如何保证消费等均需要使用方自己实现。 注：广播消费和集群消费的处理有部分区别，以下均特指集群消费（CLSUTER），广播（BROADCASTING）下部分可能不适用。 保证消费成功 PushConsumer为了保证消息肯定消费成功，只有使用方明确表示消费成功，RocketMQ才会认为消息消费成功。中途断电，抛出异常等都不会认为成功——即都会重新投递。 消费的时候，我们需要注入一个消费回调，具体sample代码如下： consumer.registerMessageListener(new MessageListenerConcurrently() { @Override public

淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件，使用Mysql作为消息存储媒介，可完全水平扩容，为了进一步降低成本，我们认为存储部分可以进一步优化，2011年初，Linkin开源了Kafka这个优秀的消息中间件，淘宝中间件团队在对Kafka做过充分Review之后，Kafka无限消息堆积，高效的持久化速度吸引了我们，但是同时发现这个消息系统主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下还有诸多特性不满足，为此我们重新用Java语言编写了RocketMQ，定位于非日志的可靠消息传输（日志场景也OK），目前RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。 数据可靠性 RocketMQ支持异步实时刷盘，同步刷盘，同步Replication，异步Replication Kafka使用异步刷盘方式，异步Replication 总结：RocketMQ的同步刷盘在单机可靠性上比Kafka更高，不会因为操作系统Crash，导致数据丢失。 同时同步Replication也比Kafka异步Replication更可靠，数据完全无单点。另外Kafka的Replication以topic为单位，支持主机宕机，备机自动切换，但是这里有个问题，由于是异步Replication，那么切换后会有数据丢失

概述 其实一直想写一篇rocketMq和kafka在架构设计上的差别，但是一直有个问题没搞明白所以迟迟没动手，今天无意中听人点播了一下似乎明白了这个问题，所以就有了这篇对比。 这篇博文主要讲清楚kafka和rocketMq的两个不同点，1、rocketMq的namesvr和kafka的zookeeper对比；2、kafka为什么比rocketMq有更大的吞吐量。如果能够讲清楚上面两个问题我觉得就已经很满足了。 最后，文章引入的参考文章里面有一些比较好的链接，有兴趣的话可以好好看看，里面其实有些地方比我讲解的更深入。 namesrv VS zk 1、我们可以对比下kafka和rocketMq在协调节点选择上的差异，kafka通过zookeeper来进行协调，而rocketMq通过自身的namesrv进行协调。 2、kafka在具备选举功能，在Kafka里面，Master/Slave的选举，有2步：第1步，先通过ZK在所有机器中，选举出一个KafkaController；第2步，再由这个Controller，决定每个partition的Master是谁，Slave是谁。因为有了选举功能，所以kafka某个partition的master挂了，该partition对应的某个slave会升级为主对外提供服务。 3、rocketMQ不具备选举，Master/Slave的角色也是固定的

尊敬的阿里云用户： 您好！为方便您试用开源 RocketMQ 客户端访问阿里云MQ，我们申请了专门的优惠券，优惠券可以直接抵扣金额。请填写下您公司账号信息，点击上图，了解更多哦。 一、DLedger引入目的 在 RocketMQ 4.5 版本之前，RocketMQ 只有 Master/Slave 一种部署方式，一组 broker 中有一个 Master ，有零到多个 Slave，Slave 通过同步复制或异步复制的方式去同步 Master 数据。Master/Slave 部署模式，提供了一定的高可用性。 但这样的部署模式，有一定缺陷。比如故障转移方面，如果主节点挂了，还需要人为手动进行重启或者切换，无法自动将一个从节点转换为主节点。因此，我们希望能有一个新的多副本架构，去解决这个问题。 新的多副本架构首先需要解决自动故障转移的问题，本质上来说是自动选主的问题。这个问题的解决方案基本可以分为两种： 利用第三方协调服务集群完成选主，比如 zookeeper 或者 etcd。这种方案会引入了重量级外部组件，加重部署，运维和故障诊断成本，比如在维护 RocketMQ 集群还需要维护 zookeeper 集群，并且 zookeeper 集群故障会影响到 RocketMQ 集群。 利用 raft 协议来完成一个自动选主，raft 协议相比前者的优点是不需要引入外部组件

kafka rocketMq零拷贝对比 https://cloud.tencent.com/developer/news/333695 还有Linux目录下的基本原理 RocketMQ Kafka Consumer消费消息过程，使用了零拷贝，零拷贝包含以下两种方式 1. 使用 mmap + write 方式 RocketMQ 选择了这种方式，mmap+write 方式，因为有小块数据传输的需求，效果会比 sendfile 更好。但是RocketMQ控制mmap映射的内存分配与释放的地方非常复杂，稍有不慎就会出问题。 优点：即使频繁调用，使用小块文件传输，效率也很高。 缺点：不能很好的利用 DMA 方式，会比 sendfile 多消耗 CPU，内存安全性控制复杂，需要避免 JVM Crash问题。 2. 使用 sendfile 方式 优点：可以利用 DMA 方式，消耗 CPU 较少，大块文件传输效率高，无内存安全性问题。 缺点：小块文件效率低于 mmap 方式，只能是 BIO 方式传输，不能使用 NIO。 sendfile：FileChannel.transferTo()只有源为FileChannel才支持transfer这种高效的复制方式，其他如SocketChannel都不支持transfer模式。当然，目的Channel没有这种限制。所以一般可以做FileChannel-

QuickStart 分别启动NameServer、Broker、生产者、消费者 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 > nohup sh bin/mqnamesrv & > nohup sh bin/mqbroker -n localhost:9876 & > export NAMESRV_ADDR=localhost:9876 > sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer SendResult [sendStatus=SEND_OK, msgId=AC112A0140641B6D35866042D36B0000, offsetMsgId=AC112A0100002A9F0000000000000000, messageQueue=MessageQueue [topic=TopicTest, brokerName=dp0652, queueId=3], queueOffset=0] SendResult [sendStatus=SEND_OK, msgId=AC112A0140641B6D35866042D3F50001, offsetMsgId

SpringBoot优雅整合RocketMQ 本篇文章默认你已经有RocketMQ的基础： Producer启动过程，消息发送过程 Consumer启动过程，消息拉取消息消费过程 NameServer，Broker，Topic，Queue等相关概念 本篇内容默认你已经有SpringBoot的基础 : @Component ,@Service @PostConstruct @PreDestory ApplicationEventPublisher 你只有简单具备上述知识，就可以继续往下阅读文章 Step1 : Maven引入相关依赖 <dependency> <groupId>com.alibaba</groupId> <artifactId>fastjson</artifactId> <version>1.2.47</version> </dependency> <dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-client</artifactId> <version>4.1.0-incubating</version> </dependency> 引入fastjson及rocketmq-client依赖，这两个都是必须的。版本号根据自己实际需求可更改 Step2：生产者 思想 ：利用

一. 预备环境 1. 系统 Windows 2. 环境 JDK1.8、Maven、Git 二. RocketMQ部署 1. 下载 1.1地址： http://rocketmq.apache.org/release_notes/release-notes-4.2.0/ 1.2选择‘Binary’进行下载 1.3解压已下载工程 2. 配置 2.1 系统环境变量配置 变量名：ROCKETMQ_HOME 变量值：MQ解压路径\MQ文件夹名 2.2重启服务器 3. 启动 3.1 启动NAMESERVER Cmd命令框执行进入至‘MQ文件夹\bin’下，然后执行‘start mqnamesrv.cmd’，启动NAMESERVER。成功后会弹出提示框，此框勿关闭。 3.2 启动BROKER Cmd命令框执行进入至‘MQ文件夹\bin’下，然后执行‘start mqbroker.cmd -n 127.0.0.1:9876 autoCreateTopicEnable=true’，启动BROKER。成功后会弹出提示框，此框勿关闭。 假如弹出提示框提示‘错误: 找不到或无法加载主类 xxxxxx’。打开runbroker.cmd，然后将‘'%CLASSPATH%’'加上英文双引号。保存并重新执行start语句。 三. RocketMQ插件部署 1. 下载 地址：https://github.com