消息中间件核心实体(1)

  • 时间:
  • 浏览:6
  • 来源:uu快3官网app_uu快3豹子赚钱

RocketMQ在TopicPublishInfo中实现分区的挑选,TopicPublishInfo富含了队列信息(List<MessageQueue> messageQueueList属性),笔者更倾向于抽象出独立的路由组件,以便在特定的场景用户可不需要能另一方实现路由,机会在测试时可不需要能做到使用特定路由规则。

实现的策略一般是:

Broker模块划分

producer

消费可不需要能分为多种法子,从获撤除 息的法子可不需要都上能 分为Pull和Push一种类型的Consumer;从消费消息的法子可不需要都上能 分为集群消费和广播消费。这里不展开讨论各种模式的实现(之后单独会讨论Consumer该实现哪些内容),会以Push模式&集群消费的Consumer为例,把消费流程中涉及到的这俩 组件进行介绍。

Consumer可不需要能在每一次获撤除 息时将消费进度提交到服务端,在服务端来更新Cursors內部的数据。

消息的写入和读取流程

2.3 消费进度

接上一篇《消息顶端件核心实体(0)》,这俩 篇继续介绍消息顶端件中的这俩 实体。

路由组件非常的简单,一般是Router会根据topic获取到topic的元数据(元数据富含了多有分区的信息),因此根据消息的属性机会用户的参数计算出落到哪个分区,比怎样不需要能根据用户的参数对分区总数取模来挑选分区,原来 可不需要能做到将某一类消息发送到原来分区,比如同原来用户的消息或同一笔订单的不同消息。

消费端原来重要的组件是消息缓存。为了提升性能,在消费端消息的获取和消息的消费是异步的。Consumer內部有程序专门从服务端获撤除 息写入到消息缓存中,另外有程序从缓存中获撤除 息调用用户的回调接口来执行业务操作。

集群消费中可不需要能保证每个分区有且可不需要能了原来Consumer在进行消费。机会某个分区可不需要能了Consumer消费,可不需要能了使用方拿可不需要能了完全的数据;机会某个分区被原来Consumer消费,可不需要能了会产生少许的重复消息。所以 这里可不需要能实现原来分区分配策略,使在分布式环境中,每个Consumer拿到属于另一方的分区,且相互交叉。下面是一四个分区原来Consumer默认请况下的分配结果。

伪代码:

EnhancedMessage继承自Message,并会增加这俩 如下的属性:

Message一般只富含topic、tag、content哪些属性,哪些属性也是使用方在发送还会涉及到的内容。因此光哪些属性往往是严重不足的,比如亲戚亲戚我们我们 会可不需要能记录产生这条消息的Producer的信息;记录消息的产生时间和产生的IP信息等等。哪些信息完全还会在Client中给消息附加进的,对发送方来说是透明的,所以 不需要在Message实体中暴露,要是我亲戚亲戚我们我们 会增加原来实体:EnhancedMessage。

每个分区和Consumer完全还会唯一的ID,原来 人及所有按照排序后的结果进行分配,可不需要能达到相互不交叉且不遗漏的目的。(在Consumer总数或分区数指在变化的过程中机会分配结果不正确,这俩 过程是短暂的,且在消费时还会结合锁去保证分区可不需要能了原来Consumer消费,所以 不需要对实际消费产生影响)。

Client模块划分

RocketMQ中实现消息缓存由ProcessQueue实现,笔者倾向于独立出Buffer模块,另外Buffer可不需要能提供锁,以实现顺序消费。

NameServer模块划分

往期文章:

业务方对消息顶端件的需求

增强Message属性,得到EnhancedMessage的实例

这俩 组件会比较简单,因此在集成的之后可不需要能注意这俩 ,这俩 组件用户可不需要能另一方注入到Producer中来达到控制分区挑选策略的目的。

拿到原来Topic所有的分区,对这俩 列表进行排序

向队列写入消息(能与非 队列暴露写入接口机会由专门的写入工具写入到队列中)

根据另一方指在的Consumer列表的位置和Consumer总数,从分区列表中获取对应的一每种

消息顶端件架构讨论

同样记住这俩 ,这俩 分配策略是可不需要能暴露出去的,系统可不需要能默认实现集群消费和广播消费的基础策略,用户可不需要能实现另一方的分配策略注入到系统中。

发送过程中会涉及到队列的挑选(分区的挑选),两根消息最终会根据一定的策略落到原来分区中,这里可不需要能原来组件来完成挑选(把这俩 组件单独抽象出来,原来 便于控制写入的目标来进行测试,抽象出来也可不需要能由使用方来实现,原来 可不需要能按照使用方另一方的场景做特定的路由)。

bornTime

1.2 Queue的路由挑选

bornAddress

etc

消费进度可不需要能记录某个Group对某个Topic的某个分区的消费位点。进度是按照Topic维度去组织的(持久化在服务端),形态学 如下:

消息顶端件中的这俩 概念

这段是Rocket开源版本中真正将消息写入到网络的实现,看起来一直非常臃肿,另外不知道是怎样mock哪些实现以达到在本地做测试的目的的。

机会本文对您有帮助,点一下右下角的“推荐”

2.1 分配分区

2.2 消息缓存

引申这俩 ,Producer发送消息的大致过程如下:

上一篇主要是我Message、Topic、TopicMeta和Queue原来 最基础的实体,这几篇介绍这俩 发送和消费的过程中会涉及到的实体和组件。

获取可不需要能写入的队列(也可不需要能理解成获取分区)

一种Buffer完全还会很冗杂的每种,因此可不需要能考虑这俩 流控策略,比如Buffer使用率到哪几只时降低从服务端获取数据的频率。

1.1 增强Message属性

顶端两幅图是Rocket开源版本中发送相关的这俩 代码,私以为这段代码非常的不优雅,读起来有点儿累,有点儿是requestHeader的各种属性设置。

最近两篇内容将这俩 基础实体和组件简单的介绍了一下,下一篇讨论一下消息应该由Server Push给Consumer还是Consumer主动来Pull消息。

消息顶端件核心实体(0)

顶端的WritableQueue暴露了API去写入,具体实现能与非 写入到网络,即远端的原来Partition。而在做单元测试机会本地测试的之后,可不需要能覆盖write的实现,而不需要真正写入到网络中,这会使代码更容易测试测试。

拿到当前所有的Consumer,对Consumer列表进行排序

哪些是分布式消息顶端件?

还有原来重要的实体是消费进度,系统可不需要能记录“每个”Consumer的消费进度,且这俩 数据可不需要能被持久化。

消息缓存除了提供基础的put和take来实现存入消息和取出消息,还可不需要能自身容量,水位控制等配置。

欢迎关注公众号来交流MQ相关问题图片。