rocket源码解析

客户端管理Channel

因为客户端要主动发起请求,以consumer为例,在对topic进行消费时,不同的topic可能在不同的broker上,因此consumer端需要对连接的多个server的Channel进行管理

流程如下:consumer和nameserver通信,获取broker地址,根据地址查询是否存在Channel,若不存在就创建Channel,并在本地缓存,下次通信时从缓存中获取Channel。通过Channel和broker进行通信。

关于自动创建topic的逻辑

发送消息时,如果是新的topic,producer会先使用默认的topicKey(TBW102)去nameserver请求一个默认的TopicRoute,这个topicRoute会包含broker等信息,然后根据这个topicRoute再构建一个新的topic对应的TopicPublishInfo,将这个TopicPublishInfo放入producerImpl的缓存即topicPublishInfoTable中。这样做是为了后期发送消息的统一性(发送消息需要按照topic和broker的对应关系来做),这样在发送消息时就直接选择一个broker进行发送即可,broker端对于不存在的topic再进行创建。

nameserver返回的TopicRouteInfo中存有topic对应的所有broker的信息,以及broker中所有的master和slave,客户端会将其转化为自己使用的,例如producer会将其转换为TopicPublishInfo。

发送消息时根据brokerName找到brokerAddress

rocket集群相关

客户端做负载均衡,会在客户端选择broker进行通信,是在客户端将消息发送到broker,因此相当于在客户端将topic进行了分片处理,高可用场景下可以使用异步复制或者同步双写保证数据一致性

目前高可用模式是多master多slave,一个master对应一个slave,master负责读写,slave可以帮助读。在master挂掉后slave并不能升级成为master,但是可以继续从slave读。后期写时只会写到其他的master。

不同的master broker的brokerName不同,master和对应slave的brokerName相同,brokerId不同,brokerId为0为master,brokerId不为0的为slave。

一个master可以对应多个slave,但是只有brokerId为1的才参与读消息,别的slave还是可以帮忙存储消息的。。。

参考文档中这段话

注意:当前RocketMQ版本在部署架构上支持一Master多Slave,但只有BrokerId=1的从服务器才会参与消息的读负载。

高可用实现

master和slave两种同步模式

同步双写

异步复制

如果当前broker为slave,在将自己注册到nameserver时,若nameserver的注册列表中存在对应的master,将会返回master的信息,包括master的地址和ha地址。ha地址就是master配置的brokerIP2。随后slave会启动一个线程(是在HAService中的HAClient),不停的将当前broker的消息位置的最大物理偏移量发送给master,master接收后会返回这个位置之后的消息,slave接收后写入commitlog,达到异步复制的功能。

ConsumerGroup相关逻辑

如果两个consumer的group相同,在cluster模式下,会平均的消费消息。

如果两个consumer的group不同,一条消息会在两个consumer处各消费一次。

Consumer端负载均衡的核心设计理念:一个消息消费队列在同一时间只允许被同一消费组内的一个消费者消费,一个消息消费者能同时消费多个消息队列。

consumer端负载均衡的逻辑在RebalanceService。

cluster模式下

从broker获取同一个group下的consumer列表,按照平均分配的分页算法,找到当前consumer对应的MessageQueue列表,将该MessageQueue列表和当前的processQueueTable做比对,将不在processQueueTable中的MessageQueue构造PullRequest,发送给PullService。

此处的分页算法,是先将consumer和MessqgeQueueList排序,用consumer作为页码,将MessageQueueList分为记录,根据页码划分记录,并求出每一页的size和每一页的范围range。最后根据consumerId找到对应的MessageQueue。

消息存储

几个重要的类

  • CommitLog
  • MappedFile
  • MappedFileQueue

主要用到的jdk中的类

  • RandomAccessFile
  • MappedByteBuffer
  • FileChannel
    主要用到的技术,内存映射
    消息落盘之后,ReputMessageService线程会更新ConsumeQueue和Index文件。
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,332评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,508评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,812评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,607评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,728评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,919评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,071评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,802评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,256评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,576评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,712评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,389评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,032评论 3 316
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,798评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,026评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,473评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,606评论 2 350