[NameServer简述] 对于一个消息队列集群来说,系统由很多机器组成,每个机器的角色.IP地址都不相同,而且这些信息是变动的(如在某些情况下,会有新的Producer或Consumer加入). NameServer的存在主要是为了解决这类问题,由NameServer维护这些配置信息.状态信息,其他角色都通过NameServer来协同执行. [NameServer的功能] NameServer是整个消息队列中的状态服务器,集群的各个组件通过它来了解全局的信息.各个角色的机器要定时向NameS…

[不同类型的消费者] DefaultMQPushConsumer 由系统控制读取操作,收到消息后自动调用传入的处理方法来处理. DefaultMQPullConsumer 读取操作中的大部分功能由使用者自动控制. [DefaultMQPushConsumer的使用] [特点] 1.系统收到消息后自动调用处理方法来处理消息,自动保存Offset. 2.加入的新的DefaultMQPushConsumer会自动做负载均衡. public class QuickStart { /** * Defaul…

[生产者的不同写入策略] 生产者向消息队列里写入数据,不同的业务需要生产者采用不同的写入策略: 同步发送.异步发送.延迟发送.发送事务消息等. [DefaultMQProduce示例] public class ProducerQuickStart { public static void main(String[] args) throws MQClientException,InterruptedException { /**1.设置Producer的GroupName**/ Default…

[消息队列的功能介绍] 分布式消息队列可以提供应用解耦.流量削峰.消息分发.保证最终一致性.方便动态扩容等功能. [MQ使用场景1——应用解耦] 复杂的系统如电商系统,会存在多个子系统,如订单系统.库存系统.物流系统.支付系统.如果各个子系统之间耦合性太强,会导致整体系统的可用性大幅降低,多个低错误率的子系统强耦合,会得到一个高错误率的整体系统. 用户创建订单后,如果耦合地调用库存系统.物流系统.支付系统,任何一个子系统出现故障不可用,都会造成下单操作异常,影响用户体验. [ 举例——通过MQ解…

[顺序消息] 顺序消费是指消息的产生顺序和消费顺序相同. 比如订单的生成.付款.发货,这三个消息必须按顺序处理才可以. [顺序消息的分类] 全局顺序消息和部分顺序消息. 上面订单的例子,其实是部分顺序消息,只要保证同一个订单ID的三个消息能顺序消费即可. [全局顺序消息] [部分顺序消费] 在实际的场景中,更多的是像订单类消息那样,只需要部分有序即可. [ MessageQueueSelector ] Producer发送端使用MessageQueueSelector类来控制把消息发往哪个Mes…

协调者保存的消费组元数据中记录了消费组的状态机 , 消费组状态机的转换主要发生在“加入组请求”和“同步组请求”的处理过程中 .协调者处理“离开消费组请求”“迁移消费组请求”“心跳请求” “提交偏移量请求”也会更新消费组的状态.机,或者依赖消费组的状态进行不同的处理.消费者要加入消费组 , 需要依次发送“加入组请求”和“同步组请求”给协调者 . 消费者加入组的过程叫作再平衡,因为协调者处理这两种请求会更新消费组状态,所以再平衡操作跟消费组状态也息息相关. 监听器回调方法和再平衡操作的执行顺序如下…

  协调者处理不同消费者的“加入组请求”,由于不能立即返回“加入组响应”给每个消费者,它会创建一个“延迟操作”,表示协调者会延迟发送“加入组响应”给消费者 . 但协调者不会为每个消费者的 “加入组请求”都创建一个 “延迟操作”,而是仅当消费组状态从“稳定”转变为“准备再平衡”,才创建一个“延迟操作”对象 . (1)初始时消费组状态为“稳定”,第一个消费者加入消费组 . 因为消费组状态为“稳定”,所以协调者允许消费者执行再平衡操作 .协调者更改消费       组的状态为“准备再平衡”,并创建一个…

消费者客户端使用“消费者的协调者对象”( ConsumerCoordinator )来代表所有和服务端协调者节点有关的请求处理,比如心跳请求.获取和提交分区的偏移量(自动提交任务).发送“加入组请求”和“同步组请求”从协调者获取到分区 . 服务端处理客户端请求的人口都是KafkaApis类,它会针对不同的请求类型分发给不同的方法处理 . 服务端定义发送响应结果的回调方法 不同消费者在不同时刻发送请求给服务端,服务端并不会立即发送响应结果给消费者. 为了保证服务端的高性能,虽然服务端不能立即返回响…

消费者客户端轮询的3个步骤:发送拉取请求,客户端轮询,获取拉取结果 . 消费者在发送拉取请求之前,必须首先满足下面的两个条件.- 确保消费者已经连接协调者, 即找到服务端中管理这个消费者的协调者节点 .- 确保消费者已经分配到分区, 即获取到协调者节点分配给消费者的分区信息 . 消费者客户端除了从协调者节点获取到分区,还会发送心跳请求.提交偏移量给协调者节点 . 其中,提交偏移量主要和消息的处理有关,协调者只是作为偏移量的存储介质. 而消费者发送心跳请求给协调者,则有可能归现各种各样的问题,如下…

[Broker端进行消息过滤] 在Broker端进行消息过滤,可以减少无效消息发送到Consumer,少占用网络宽带从而提高吞吐量. [过滤方式1——通过Tag过滤] [ 关于Tag和Key ] 对一个应用来说,尽可能只用一个Topic,不同消息子类型用Tag来标识,每条消息只能有一个Tag,服务端基于Tag进行过滤,并不需要读取消息体的内容,效率较高.Producer发送消息设置了Tag以后,Consumer在订阅消息时,才会利用Tag在Broker端做消息过滤. 消息的Key,发送的消息设置…