前言 本文档是针对RocketMQ使用及常见问题的说明. 一．获取项目.安装包及文档 1. alibaba/RocketMQ https://github.com/alibaba/RocketMQ 2. Download the latest release package https://github.com/alibaba/RocketMQ/releases 3. Get the latest document & Who using RocketMQ https://github.com/

概述 对于一个消息中间件来讲,高可用功能是极其重要的,RocketMQ 当然也具有其对应的高可用方案. 在 RocketMQ 中,有主从架构和 Dledger 两种高可用方案: 第一种通过主 Broker 将消息发送到从 Broker 实现高可用,在主 Broker IO 压力大或宕机的时候,从 Broker 可以接管读请求,但这种方案不支持在主 Broker 宕机后自动进行故障转移,且从 Broker 不支持写请求,也就是说在主 Broker 宕机后我们只能手动处理. 第二种是在 Rocket

概述 上一章中,已经介绍了 Broker 的文件系统的各个层次与部分细节,本章将继续了解在逻辑存储层的三个文件 CommitLog.IndexFile.ConsumerQueue 的一些细节.文章最后,还会对比下 RocketMQ 和 Kafka 的持久化结构与设计的合理性. CommitLog 现在,先从 CommitLog 的几个指针开始复习 在上一章 <RocketMQ源码详解 | Broker篇 · 其二:文件系统> 中,我们已经了解了 CommitLog 的缓存和刷盘的策略,现在来简

概述 在上文中,我们讨论了消费者对于消息拉取的实现,对于 RocketMQ 这个黑盒的心脏部分,我们顺着消息的发送流程已经将其剖析了大半部分.本章我们不妨乘胜追击,接着讨论各种不同的消息的原理与实现. 事务消息 概念 RocketMQ 中的事务消息功能,实际上是 分布式事务中的本地事务表 的实现,只不过,在这里用消息中间件来代替了数据库,同时也帮我们做好了回查的操作. 在这点上,RocketMQ 和 Kafka 是截然不同的,kafka 的事务是用来实现 Exacltly Once 语义,且该语

概述 在上一节 RocketMQ源码详解 | Producer篇 · 其二:消息组成.发送链路 中,我们终于将消息发送出了 Producer,在短暂的 tcp 握手后,很快它就会进入目的 Broker.这次我们来自底向上的看下 Broker 端是如何接收然后分发处理消息,同时了解 RocketMQ 的 Broker 的线程模型. Netty 组件 如果你还记得上一节的内容的话那应该知道,NettyRomotingAbstract 有两个实现类,分别是 NettyRemotingClient 和

概述 在 Broker 的通用请求处理器将一个消息进行分发后,就来到了 Broker 的专门处理消息存储的业务处理器部分.本篇文章,我们将要探讨关于 RocketMQ 高效的原因之一:文件结构的良好设计与对 Page Cache 的极致"压榨". 文件系统的结构设计 在 RocketMQ 的 Broker 中,有一类叫做 CommitLog 的文件,所有在该 Broker 上的 Topic 上的消息都会顺序的写入到这个文件中. 该消息的元信息存储着消息所在的 Topic 与 Queue

发现rabbitmq有一个ConnectionFactory.发现rocketmq好像没这个东西.按道理来说如果每次发送消息都新建一条连接肯定是不可能的. ps:其实之所以是有上面的疑问是因为数据库连接池那个地方来的,因为数据库连接connection并没有说是线程安全的,所以为了线程安全会为每个事物单独分配一个连接.但是rocketmq用的是netty的长连接channel,Java 上关于SocketChannel 的注释 说明是安全的. <Netty : writeAndFlush的线程安

在启动Flume的时候,出现下面的异常,但是程序照样能运行,Kafka也能够收到数据,只是偶尔会断点. 2016-08-25 15:32:54,561 (SinkRunner-PollingRunner-DefaultSinkProcessor) [INFO - kafka.utils.Logging$class.info(Logging.scala:68)] Fetching metadata from broker id:2,host:10.208.129.5,port:9092 with

在工作中遇到了一个这个问题,就是我们rocketmq是部署在云主机上的 但是我们的开发同事在自己的电脑连接rocketmq链接不上 报错显示Caused by: org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to <10.19.73.64:10911> failed 这里练级的是rocketmq云主机的内网IP,那肯定是链接不上的 这里我们就需要修改RocketMQ的 broker 的地址 #进

  在工作中遇到了一个这个问题,就是我们rocketmq是部署在云主机上的 但是我们的开发同事在自己的电脑连接rocketmq链接不上 报错显示Caused by: org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to <10.19.73.64:10911> failed 这里练级的是rocketmq云主机的内网IP,那肯定是链接不上的 这里我们就需要修改RocketMQ的 broker 的地址

RocketMQ推荐了几种Broker集群方式,这里的Slave不可写,但可读,类似于Mysql主备方式 1. 单个Master 这是一种风险比较大的集群方式,因为一旦Borker重启或宕机期间,将会导致这个服务不可用,因此是不建议线上环境去使用的. 2. 多个Master 一个集群全部都是Master,没有Slave,它的优点和缺点如下: 优点:配置简单,单个Master宕机或者是重启维护对应用没有什么影响的,在磁盘配置为RAID10时,即使机器宕机不可恢复的情况下,消息也不会丢失(异步刷盘丢

分布式消息系统作为实现分布式系统可扩展.可伸缩性的关键组件,需要具有高吞吐量.高可用等特点.而谈到消息系统的设计,就回避不了两个问题: 消息的顺序问题 消息的重复问题 RocketMQ作为阿里开源的一款高性能.高吞吐量的消息中间件,它是怎样来解决这两个问题的?RocketMQ 有哪些关键特性?其实现原理是怎样的? 关键特性以及其实现原理 一.顺序消息 消息有序指的是一类消息消费时,能按照发送的顺序来消费.例如:一个订单产生了 3 条消息,分别是订单创建.订单付款.订单完成.消费时,要按照这个顺序

一.简介 官方简介: l  RocketMQ是一款分布式.队列模型的消息中间件,具有以下特点: l  能够保证严格的消息顺序 l  提供丰富的消息拉取模式 l  高效的订阅者水平扩展能力 l  实时的消息订阅机制 l  亿级消息堆积能力 二.网络架构 三.特性 1.      nameserver 相对来说,nameserver的稳定性非常高.原因有二: 1 .nameserver互相独立,彼此没有通信关系,单台nameserver挂掉,不影响其他nameserver,即使全部挂掉,也不影响业务

RocketMQ是一款分布式.队列模型的消息中间件,具有以下特点: 1.能够保证严格的消息顺序 2.提供丰富的消息拉取模式 3.高效的订阅者水平扩展能力 4.实时的消息订阅机制 5.亿级消息堆积能力 RocketMQ网络部署 1.NameServer是一个几乎无状态的节点,可集群部署,一般用zookeeper实现,用于管理分布式Topic信息 NameServer维护信息示例:rocketMQ/brokers/myserverrocketMQ/topics/epftopic4wolfrocket

转自:http://www.jianshu.com/p/453c6e7ff81c 分布式消息系统作为实现分布式系统可扩展.可伸缩性的关键组件,需要具有高吞吐量.高可用等特点.而谈到消息系统的设计,就回避不了两个问题: 消息的顺序问题 消息的重复问题 RocketMQ作为阿里开源的一款高性能.高吞吐量的消息中间件,它是怎样来解决这两个问题的?RocketMQ 有哪些关键特性?其实现原理是怎样的? 关键特性以及其实现原理 一.顺序消息 消息有序指的是可以按照消息的发送顺序来消费.例如:一笔订单产生了

上一篇说明了RocketMQ怎么支持broker集群的,这里接着说RocketMQ实现高可用的手段之一--冗余. RocketMQ部署的时候一个broker set会有一个mater和一个或者多个slave,salve起到的作用就是同步master存储的的消息,并且会接收部分consumer读取消息的请求,下面围绕两个问题来阐明怎么做的冗余: 怎么实现冗余 冗余之后的消息读取 怎么实现冗余? RocketMQ通过主从结构来实现消息冗余,master接收来自producer发送来的消息,然后同步消

基本概念 ProducerGroup 通常具有同样属性(处理的消息种类-topic.以及消息处理逻辑流程—分布式多个客户端)的一些producer可以归为同一个group.在事务消息机制中,如果某条发送某条消息的producer-A宕机,使得事务消息一直处于PREPARED状态并超时,则broker会回查 同一个group的其他producer,确认这条消息应该commit还是rollback. ConsumerGroup 具有同样逻辑消费同样消息的consumer,可以归并为一个group.同

RocketMQ作为阿里开源的一款高性能.高吞吐量的消息中间件,它是怎样来解决这两个问题的?RocketMQ 有哪些关键特性?其实现原理是怎样的? 关键特性以及其实现原理 一.顺序消息 消息有序指的是可以按照消息的发送顺序来消费.例如:一笔订单产生了 3 条消息,分别是订单创建.订单付款.订单完成.消费时,要按照顺序依次消费才有意义.与此同时多笔订单之间又是可以并行消费的.首先已两笔消息来看如下示例: 假如生产者产生了2条消息:M1.M2,要保证这两条消息的顺序,应该怎样做?你脑中想到的可能是这

近来研究了Apache开源项目rocketMQ(原为阿里项目),并在两台linux服务器上完成了部署,现在整理下,供大家参考学习. 一.简介rocketMQRocektMQ是阿里巴巴在2012年开源的一个纯java.分布式.队列模型的第三代消息中间件,不仅在传统高频交易链路有着低延迟的出色表现,在实时计算等大数据领域也有着不错的吞吐. 2016年11月11号,双十一大促见证了RocketMQ低延迟存储架构的成功试水,99.996%的延迟落在了10ms以内,极个别由于GC引发的停顿在50ms以内,

1. rocketMQ安装: 编译完成以后准备启动项目,注意:bin的位置是编译后target目录下,启动命令在这里. linux命令目录:你的目录/rocketmq-all-4.2.0/distribution/target/apache-rocketmq/bin windows命令目录:你的目录\rocketmq-3.5.8\target\alibaba-rocketmq-broker\alibaba-rocketmq\bin 如果嫌层级太深,可以将里面的内容拷贝出去,将第一层内容覆盖掉.

rocketmq总结(消息的顺序.重复.事务.消费模式) 参考: http://www.cnblogs.com/wxd0108/p/6038543.html https://www.cnblogs.com/520playboy/p/6750023.html https://blog.csdn.net/chunlongyu/article/details/53977819 https://blog.csdn.net/zhanglianhai555/article/details/77604582?