电子商务网站 开发,wordpress 示例,google ajax wordpress,wordpress 合并js消费者#xff08;Consumer#xff09;在Kafka的体系结构中是用来负责订阅Kafka中的主题#xff08;Topic#xff09;#xff0c;并从订阅的主题中拉取消息后进行处理。
与其他消息中间件不同#xff0c;Kafka引入一个逻辑概念——消费组#xff08;Consumer GroupConsumer在Kafka的体系结构中是用来负责订阅Kafka中的主题Topic并从订阅的主题中拉取消息后进行处理。
与其他消息中间件不同Kafka引入一个逻辑概念——消费组Consumer Group我们可以理解为消费者的分类每个消费者都对应一个消费组消费组与消费组之间的关系是完全独立的互不影响。
1 消费组
我对消费组的理解是这样的为了便于理解我将它看做一个“大号的消费者”既然它是一个“消费者”那它就能订阅主题即从主题那里拉取消息所以对于主题中的一个消息来说订阅了该主题的所有“大号的消费者即消费组”们都能拉取到该消息实际上是消费组中的消费者如下图
图①的理解是将消费组A和消费组B看做两个“大号的消费者”并且都订阅了主题A。图②的理解是由于“大号的消费者A”和“大号的消费者B”都订阅了主题A所以【消息A-1】会发送给这两个“大号的消费者实际是消费组”。图③的理解是实际上【消息A-1】是被“大号消费者A”即消费组A和“大号消费者B”即消费组B中的【消费者A-1】和【消费者B-1】拉取了并处理了。
再进一步来说消费组内的消费者们实质上都处理相同的业务可以将他们理解为同一个消费者的多个副本而不同消费组的消费者通常来说处理的都是不同的业务。 我们再举个例子来解释下 假设这样一个场景 一个请假的审批流程请假审批通过后会分别通知请假申请人和人力资源部门。 从中我们定义出一个主题和二个消费者
主题请假审批结果消费者A0通知请假申请人消费者B0通知人力资源部门
期初公司人员较少请假审批的申请并不多也就是说要消费的消息并不多此时一个处理“通知请假申请人”的消费者节点和一个处理“通知人力资源部门”的消费者节点就可以支撑业务了如下图 假设公司团队迅速扩张员工人数大量增加请假也越来越多之前分别处理“通知请假申请人”、“通知人力资源部门”的单节点无法快速的处理消息所以这个时候我们就需要增加节点如下图
2 分区分配逻辑
基于默认的分区分配策略我们再来看下消费组内的消费者数量变化会对分区分配有怎样的影响也就是分配逻辑是什么样的如下图
图①表示消费组内只有一个消费者时所有分区的消息将都分配给该消费者。图②、图③表示将原本分配给【消费者A-0】的部分分区分配给【消费者A-1】和【消费者A-2会】。图④表示当消费组内消费者的数量等于分区数量的时候则每个分区都会被分配一个对应消费者。图⑤表示当消费组内的消费者数量大于分区数量的时候并不能提高消费的效率因为多出来的消费者分配不到任何分区也就无法消费任何消息。
3 Kafka的消息投递模式
消息的投递方式主要有以下两种
点对点P2PPoint-to-Point模式点对点模式是基于队列的消息生产者Producer将消息发送给队列消息消费者Consumer从队列中接收消息并进行消费。发布/订阅Pub/Sub模式发布/订阅模式是基于主题Topic的消息生产者Producer将消息发送给主题消息消费者Consumer接收所订阅主题的消息并进行消费。
这两种消息投递方式Kafka同时支持那么Kafka是如何实现的点对点模式和订阅/发布模式的呢
点对点模式将所有订阅某主题的消费者放到一个消费组中这样的话该主题的每条消息就只会被消费组中的一个消费者消费掉也就相当于点对点模式的应用了。 以上图为例被分配到【分区0】的消息只能被【消费者A-0】拉取到。订阅/发布模式使订阅某主题的所有消费者都隶属一个专属的消费组这样的话该主题的每条消息将会被所有消费者都处理一遍也就相当于发布/订阅模式的应用了。 以上图为例被分配到【分区0】的消息会被【消费者0】、【消费者1】、【消费者2】…【消费者N】拉取到。
上一篇《Kafka之生产者》 下一篇《Kafka之消费者客户端开发》
