rocketMq官网 http://rocketmq.apache.org/ rocketMq逻辑概念介绍 rocketMq逻辑图 备注:    改图片分享自李占卫的网上家园 说明: 在rocketMq的中核心4组件为namesrv.broker.consumer.producer. broker:消息存储中心,主要用来存储消息并通过namesrv对外提供服务. namesrv:无状态的注册中心,功能用来保存broker的相关的元信息并提供给producer在发送消息过程中和提供给consume

可能我们对 RocketMQ 的消费者认知乍一想很简单,就是一个拿来消费消息的客户端而已,你只需要指定对应的 Topic 和 ConsumerGroup,剩下的就是只需要: 接收消息 处理消息 就完事了. 简略消费模型 当然,可能在实际业务场景下,确实是这样.但是如果我们不清楚 Consumer 启动之后到底会做些什么,底层的实现的一些细节,在面对复杂业务场景时,排查起来就会如同大海捞针般迷茫. 相反,你如果了解其中的细节,那么在排查问题时就会有更多的上下文,就有可能会提出更多的解决方案. 关于

CLIENT 之前讲过tools里面有大量调用client的东西.为了从源码层面了解rocket,决定啃下client这块骨头. pom 先看pom,看看CLIENT依赖谁.看完后原来是依赖common的.common又依赖remoting的 翻开remoting看了看,都是一些接口定义.明白了,remoting应该是通信协议,公共接口.看来如果讲框架的时候,应该从remoting开始讲. 而common,看名字就知道是个公共包,里面提供了各种公用的东西.先不讲了,用到再看吧. 好的,开始分析源

RocketMQ初步应用架构理论 写给RocketMQ架构应用入门,内容涉及它的设计机理以及推到出来的应用注意事项,入门人员请看. 稍微涉及技术细节,留以我设计中间件时参考,将来整理深度文档时会抽取走,入门人员可以无视. 以下RocketMQ简称为RQ,理论部分采用版本为3.2.4,测试部分采用版本为3.2.6. MQ的需求 我们对MQ的需求,相比JMS标准有几点要求更高: 1. 必须优美灵活地支持集群消费. 2. 尽量支持消息堆积. 3. 服务高可用性和消息可靠性. 4. 有起码的运维工具做集

背景 我们在很早之前大约在2015年8月份左右我们开始使用Rocketmq作为公司消息中间件,那个时候RocketMQ还没有捐赠给Acaphe. RocketMQ版本还是3.2.6,中间升级了一次版本,目前版本是3.5.8. 但是随着RocketMQ版本不断更新并且功能与稳定性也不断提高,所以打算升级为4.3.X版本 上一次升级停机了10分钟不到还是很快的,这次的目标是不停机升级版本.(题外话,上次因为升级还燃起了一波“干架”) 架构深入了解 先简单附上一张RocketMQ的整体架构图,通过架构

用户U1从A银行系统转账给B银行系统的用户U2的处理过程如下:第一步:A银行系统生成一条转账消息,以事务消息的方式写入RocketMQ,此时B银行系统不可见这条消息(Prepare阶段) 第二步:写入MQ成功后,回调A银行系统,对T1,T2表进行操作(很显然需要是一个事务)我们重点关注下T2表,这个表是用来干嘛的呢?每条转账消息都会在T2表中,该表有2个特殊的字段:status,updatetime. 第三步:完成第二步,接下来发送确认消息给MQ,如果这个确认消息发送成功,那么这条转账消息,将对

这是一篇分享文 转自:http://www.cnblogs.com/williamjie/p/9481780.html  尊重原作,谢谢 消息队列 为什么写这篇文章? 博主有两位朋友分别是小A和小B: 小A,工作于传统软件行业(某社保局的软件外包公司),每天工作内容就是和产品聊聊需求,改改业务逻辑.再不然就是和运营聊聊天,写几个SQL,生成下报表.又或者接到客服的通知,某某功能故障了,改改数据,然后下班部署上线.每天过的都是这种生活,技术零成长. 小B,工作于某国企,虽然能接触到一些中间件技术.

学而时习之,不亦说乎! 自己搭建个学习用的RocketMQ总是很麻烦,需要虚拟机环境,网络,需要安装rocketmq,启动.时间久了再去看,又不知道这个虚拟机是干嘛的了. 直接在eclipse中启动,简单省事,用的时候启动,用完关掉就行了. 先看下图,给还没开始的你一点信心. RocketMQ 官网:http://rocketmq.apache.org/ 源码:https://github.com/apache/rocketmq github:https://github.com/apache/

初学RocketMQ,认识一门新技术,还是哪三问:是什么?能干什么?怎么用? 消息中间件主要是实现分布式系统中解耦.异步消息.流量销锋.日志处理等场景. Rocketmq是阿里捐赠给Apache的.3.x以下版本为阿里版本.4.x为Apache托管版本.由于目前Apache没有提供直编译的下载文件,所以一般需要maven编译. 一.是什么? 大多数网友都给出答案,不赘述了(关注基础概念.功能特点 http://jameswxx.iteye.com/blog/2091966)     Rocket

Broker的HA策略分为两部分①同步元数据②同步消息数据 同步元数据 在Slave启动时,会启动一个定时任务用来从master同步元数据 if (role == BrokerRole.SLAVE) { if (null != slaveSyncFuture) { slaveSyncFuture.cancel(false); } this.slaveSynchronize.setMasterAddr(null); slaveSyncFuture = this.scheduledExecutorS

面试题 为什么使用消息队列? 消息队列有什么优点和缺点? Kafka.ActiveMQ.RabbitMQ.RocketMQ 都有什么区别,以及适合哪些场景? 面试官心理分析 其实面试官主要是想看看: 第一,你知不知道你们系统里为什么要用消息队列这个东西? 不少候选人,说自己项目里用了 Redis.MQ,但是其实他并不知道自己为什么要用这个东西.其实说白了,就是为了用而用,或者是别人设计的架构,他从头到尾都没思考过. 没有对自己的架构问过为什么的人,一定是平时没有思考的人,面试官对这类候选人印象通

消息中间件是为解耦生产者和消费者的目的,三大服务点:解耦.异步.削峰. 现在的的互联网系统中,mq已经必备基础设施了,我们已明显感觉它的必要性与强大.然而,它的本质是啥?存储转发系统罢了! MQ有很多成熟产品,以RocketMQ作为切入点,成本较低.MQ主要角色为:生产者.消费者.消息服务端. 本文先来看看消费者的实现.现在通用的消费模型中,有推和拉两种模型.各有优劣,一言以避之,推更实时,拉更容易控制. 一. push模式消费例子 /** * This example shows how to

面试题 为什么使用消息队列? 消息队列有什么优点和缺点? Kafka.ActiveMQ.RabbitMQ.RocketMQ 都有什么区别,以及适合哪些场景? 面试官心理分析 其实面试官主要是想看看: 第一,你知不知道你们系统里为什么要用消息队列这个东西? 不少候选人,说自己项目里用了 Redis.MQ,但是其实他并不知道自己为什么要用这个东西.其实说白了,就是为了用而用,或者是别人设计的架构,他从头到尾都没思考过. 没有对自己的架构问过为什么的人,一定是平时没有思考的人,面试官对这类候选人印象通

这是一篇分享文 转自:http://www.cnblogs.com/williamjie/p/9481780.html  尊重原作,谢谢 消息队列 为什么写这篇文章? 博主有两位朋友分别是小A和小B: 小A,工作于传统软件行业(某社保局的软件外包公司),每天工作内容就是和产品聊聊需求,改改业务逻辑.再不然就是和运营聊聊天,写几个SQL,生成下报表.又或者接到客服的通知,某某功能故障了,改改数据,然后下班部署上线.每天过的都是这种生活,技术零成长. 小B,工作于某国企,虽然能接触到一些中间件技术.

一.发展历程 早期淘宝内部有两套消息中间件系统:Notify和Napoli. 先有的Notify(至今12历史),后来因有序场景需求,且恰好当时Kafka开源(2011年),所以参照Kafka的设计理念自研了RocketMQ. 目前Notify和RocketMQ二者的定位如下: RocketQ 主要面向消息有序的场景,能够提供更大的消息堆积能力,拉模式,消息持久化在磁盘 Notify主要面向更加安全可靠地交易类场景,无序.推模式.消息持久化在mysql RocketMQ发展历程如下: Metaq

0.汇总 RocketMQ入门到入土(一)新手也能看懂的原理和实战! RocketMQ入门到入土(二)事务消息&顺序消息 从入门到入土(三)RocketMQ 怎么保证的消息不丢失? RocketMQ入门到入土(四)producer生产消息源码剖析 RocketMQ入门到入土(五)消息持久化存储源码解析 RocketMQ入门到入土(六)发消息的时候选择queue的算法有哪些? RocketMQ入门到入土(七 )为什么同一个消费组设置不同tag会出现奇怪现象 从入门到入土(八)RocketMQ的Co

每个时代,都不会亏待会学习的人. 大家好,我是 yes. 继上一篇 头条终面:写个消息中间件 ,我提到实现消息中间件的一些关键点,今天就和大家一起深入生产级别消息中间件 - RocketMQ 的内核实现,来看看真正落地能支撑万亿级消息容量.低延迟的消息队列到底是如何设计的. 这篇文章我会先介绍整体的架构设计,然后再深入各核心模块的详细设计.核心流程的剖析. 还会提及使用的一些注意点和最佳实践. 对于消息队列的用处和一些概念不太清楚的同学强烈建议先看消息队列面试连环问,这篇文章介绍了消息队列的使用

rocketmq作为一个高性能的消息中间件,咱们光停留在使用层面,总感觉缺点什么.虽然rocketmq的官方设计文档讲得还是比较详细的,但纸上得来终觉浅!今天我们就来亲自挖一挖rocketmq的实现细节:server端处理框架以及如果进行消费消息. 说白了,就是先走马观花一下,然后就消费消息这个细节看看如何处理就行. 1. rocketmq的通信模型 咱们先来个整体部署架构图,有个整体概念. 上面的图中,producer和consumer属于客户端,虽然也都非常重要.但在服务端的部署中,我们并不

前言 在使用SpringBoot的starter集成包时,要特别注意版本.因为SpringBoot集成RocketMQ的starter依赖是由Spring社区提供的,目前正在快速迭代的过程当中,不同版本之间的差距非常大,甚至基础的底层对象都会经常有改动.例如如果使用rocketmq-spring-boot-starter:2.0.4版本开发的代码,升级到目前最新的rocketmq-spring-boot-starter:2.1.1后,基本就用不了了 应用结构 TestController: 测试

在rocketmq中,nameserver充当了一个配置管理者的角色,看起来好似不太重要.然而它是一个不或缺的角色,没有了它的存在,各个broker就是一盘散沙,各自为战. 所以,实际上,在rocketmq中,nameserver也是一个领导者的角色.它可以决定哪个消息存储到哪里,哪个broker干活或者上下线,在出现异常情况时,它要能够及时处理.以便让整个团队发挥应有的作用.nameserver相当于一个分布式系统的协调者.但是这个名字,是不是看起来很熟悉?请看后续! 1. 为什么会有name

RocketMQ作为消息中间件,经常会被用来和其他消息中间件做比较,比对rabbitmq, kafka... 但个人觉得它一直对标的,都是kafka.因为它们面对的场景往往都是超高并发,超高性能要求的场景. 所以,有必要深挖下其实现高性能,高并发的原因.实际上,这是非常大的话题,我这里也不打算一口吃个大胖子.我会给出个大概答案,然后我们再深入挖掘其中部分实现.如题所述. 1. 高性能高并发系统的底层技能概述 我不打算单讲rocketmq到底是如何实现高性能高并发的,因为实际上的底层原则都是差不多