
消息中间件Kafka/RabbitMQ/ActiveMQ
文章平均质量分 94
消息中间件笔记
程序猿进阶
要做就做第一,就算结果不是第一,也会是一个好成绩。 加油!我的未来不是梦。
展开
-
Kafka 物理存储机制
一个商业化消息队列的性能好坏,其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。下面将从Kafka文件存储机制和物理结构角度,分析Kafka是如何实现高效文件存储,及实际应用效果。Kafka的基本存储单位是分区。在配置Kafka的时候,管理员指定了一个用于存储分区的目录清单log.dirs参数的值。原创 2024-10-30 05:30:00 · 11780 阅读 · 87 评论 -
消费者Rebalance机制
【4】优化消费者性能:提高消费者的处理能力,确保消费者能够及时处理消息,避免因为处理延迟导致的重平衡。这种策略的好处是分区分配简单且稳定,减少了分区在消费者组成员变化时的重新分配范围,从而减少了重平衡的频率和影响。这种策略的好处是减少了重平衡带来的影响,提高了分区分配的稳定性,减少了因分区移动带来的数据重新加载和处理的开销。的改进版本,它引入了协作重平衡的概念,使得重平衡过程更加平滑,减少了重平衡期间的停顿时间。及以上版本引入的一种分区分配策略,它的目标是尽量保持分区分配的稳定性,减少重平衡的频率。原创 2024-10-07 05:30:00 · 1693 阅读 · 84 评论 -
QMQ 上云方案
对于不一致的区间,灰度流量减少的机房需要等待灰度流量增多的机房确认后,才能使新的配置生效减少流量,中间产生的重复消费,靠强制幂等来解决。由于该问题只会在灰度配置变更后短时间内产生,所以我们可以设定一个时间,应用监听灰度配置的变化,当灰度配置发生变更后的指定时间内,才需要使用这个机制去保证幂等,过了该时间后可以直接全量消费。和私有云的消息进行互通,这样公有云的消息可以在私有云消费,同时私有云的消息可以在公有云消费,消息同步存在延迟(300-500ms)或者更长。的数据,此时无法确定需要在哪个数据中心消费。原创 2024-09-13 05:15:00 · 1560 阅读 · 52 评论 -
消息中间件选型
消息中间件选型常用的 MQ组件有 Kafka、RabbitMQ、RocketMQ、ActiveMQ、ZeroMQ、MetaMQ。当然 Kafka的功能更加强大,其它 MQ都有自己的特点和优势,如下:特性KafkaRabbitMQRocketMQActiveMQ开发语言ScalaErlangJavaJava单击吞吐量十万级万级十万级万级时效性ms级以内us(微秒)级ms级ms级可用性非常高(分布式架构)高(主从架构)非常高(分布式架原创 2020-12-16 23:53:26 · 1650 阅读 · 3 评论 -
Kafka为什么比其他消息中间件快
无论 Kafka 作为 MQ 也好,还是作为存储层也罢,无非就是两个功能,一是 Producer 生产的数据存到 Broker,二是 Consumer 从 Broker 读取数据。那 Kafka 的快也就体现在读写两个方面了,下面我们就聊聊 Kafka 快的原因。原创 2024-09-04 05:15:00 · 1235 阅读 · 92 评论 -
RabbitMQ 消息中间件总结
RabbitMQ是实现高级消息队列协议()的开源代理软件,也称为面向消息的中间件。支持多种操作系统、多种编程语言。RabbitMQ服务器使用Erlang语言编写,其集群和故障转移是构建在开放电信平台框架上的。AMQP是一个面向消息中间件的开放式应用层协议。定义消息方向、消息队列、消息路由、可靠性、安全性等特性。要求消息的提供者和客户端接收者的行为要实现对不同供应商可以用相同的方式(等)进行互相操作。以往的JMS,主要是建立在API级别,建立标准化的程序间的互操作性。而AMQP是一个线路级协议。原创 2024-08-05 05:30:00 · 1451 阅读 · 55 评论 -
Kafka 实现延迟队列、死信队列、重试队列
Kafka中实现延迟队列在发送延时消息的时候并不是先投递到要发送的真实主题(real_topic)中,而是先投递到一些 Kafka 内部的主题(delay_topic)中,这些内部主题对用户不可见,然后通过一个自定义的服务拉取这些内部主题中的消息,并将满足条件的消息再投递到要发送的真实的主题中,消费者所订阅的还是真实的主题。如果采用这种方案,那么一般是按照不同的延时等级来划分的,比如设定5s、10s、30s、1min、2min、5min、10min、20min、30min、45min、1hour、2原创 2021-04-24 09:40:42 · 5089 阅读 · 44 评论 -
Kafka 事务
在了解 Kafka的事务之前,先说一下 Kafka中幂等和事务(Kafka 0.11.0.0版本引入的两个特性)以此来实现 Exactly once(精确一次)了解更多链接。幂等:生产者在进行重试的时候有可能会重复写入消息,而使用 Kafka的幂等性功能之后就可以避免这种情况。生产者事务相关配置开启幂等性功能的方式很简单,只需显式地将生产者客户端参数 enable.idempotence=true(默认值为false)Kafka的幂等只能保证单个生产者会话(session)中单分区的幂等。幂原创 2021-04-24 09:40:45 · 1615 阅读 · 5 评论 -
leader epoch
leader epoch 代表 Leader 的纪元信息(epoch),初始值为0。每当 Leader 变更一次,leader epoch 的值就会加1,相当于为 Leader 增设了一个版本号。每个副本中还会增设一个矢量 <LeaderEpoch >= StartOffset>,其中 StartOffset 表示当前 LeaderEpoch 下写入的第一条消息的偏移量。假设有两个节点A 和 B,B是 leader节点,里面的数据如图:A发生重启之后,A不是先忙着截断日志而是先发送原创 2021-04-23 23:20:19 · 2212 阅读 · 1 评论 -
Kafka 消息送达语义
消息送达语义是消息系统中一个常见的问题,主要包含三种语义:【1】At most once:消息发送或消费至多一次;【2】At least once:消息发送或消费至少一次;【3】Exactly once:消息恰好只发送一次或只消费一次;下面分别从生产者和消费者的角度来阐述这三种消息送达语义。生产者 Producer从 Producer的角度来看,At most once意味着 Producer发送完一条消息后,不会确认消息是否成功送达。这样从 Producer的角度来看,消息仅仅被发送一次,也就存原创 2021-04-23 23:15:45 · 1204 阅读 · 0 评论 -
Kafka 集群调优
kafka 集群搭建链接单个 kafka服务器足以满足本地开发或 POC要求,使用集群的最大好处是可以跨服务器进行负载均衡,再则就是可以使用复制功能来避免因单点故障造成的数据丢失。在维护 Kafka 或底层系统时,使用集群可以确保为客户端提供高可用性。需要多少个 Broker一个 kafka 需要多少个 broker取决于以下几个因素:【1】需要多少磁盘空间来保留数据,以及单个broker 有多少空间可用。如果整个集群需要保留 10TB(每天2千万的数据,够用2年)的数据,每个 broke原创 2021-04-23 23:09:39 · 1131 阅读 · 38 评论 -
Kafka 管理【主题、分区、消费者组】
主题操作使用 kafka-topics.sh 工具可以执行主题的大部分操作。可以用它创建、修改、删除和查看集群里的主题。要使用该工具的全部功能,需要通过 --zookeeper参数提供 Zookeeper的连接字符串。kafka 的大部分命令行工具直接操作 Zookeeper 上的元数据,并不会连接到 broker上。因此,要确保所使用工具版本与集群里的 broker版本相匹配。直接使用集群 broker自带的工具是最保险的。创建主题在集群中创建一个主题需要3个参数:主题名字(可以包含字原创 2021-04-23 23:05:03 · 2025 阅读 · 0 评论 -
SpringBoot 整合 Avro 与 Kafka
【需求】:生产者发送数据至 kafka 序列化使用 Avro,消费者通过 Avro 进行反序列化,并将数据通过 MyBatisPlus 存入数据库。一、环境介绍【1】Apache Avro 1.8;【2】Spring Kafka 1.2;【3】Spring Boot 1.5;【4】Maven 3.5;<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0"原创 2021-04-23 22:54:32 · 7998 阅读 · 9 评论 -
Kafka 消费者读取数据
消费者不需要自行管理 offset(分组+topic+分区),系统通过 broker 将 offset 存放在本地。低版本通过 zk 自行管理。系统自行管理分区和副本情况。消费者断线后会自动根据上一次记录的 offset 去获取数据(默认一分钟更新一次 offset),同一个分组中的客户不能同时消费同一个分片。不同的 group 记录不同的 offset,这样不同程序读取同一个 topic 才不会因为 offset 互相影响。一、消费者组分区的所有权从一个消费者转移到另一个消费者,这样的行为称为原创 2021-04-23 22:37:41 · 5163 阅读 · 63 评论 -
Kafka 之 HW 与 LEO
HW(High Watermark):俗称高水位,它标识了一个特定的消息偏移量(offset),消费者只能拉取到这个 offset 之前的消息。分区 ISR 集合中的每个副本都会维护自身的 LEO(Log End Offset):俗称日志末端位移,而 ISR 集合中最小的 LEO 即为分区的 HW,对消费者而言只能消费 HW 之前的消息。LEO:该副本底层 log文件下一条要写入的消息的位移,例如 LEO=10则当前文件已经写了了10条消息,位移是[0,10)。HW:所有分区已提交的的位移,一般HW&原创 2021-04-23 22:08:47 · 6017 阅读 · 24 评论 -
Kafka 生产者写入数据
一、生产者发送消息的步骤创建一个 ProducerRecord 对象,对象中包含目标主题和要发送的内容。还可以指定键或分区。在发送 ProducerRecord 对象时,生产者要先把键和值对象序列化成字节数组,这样它们才能够在网络上传输。接下来,数据被传给分区器。分区器直接把指定的分区返回。如果没有指定分区,分区器会根据 ProducerRecord 对象的键来选择一个分区。选择好分区之后,生产者就知道该往哪个这主题和分区发送这条记录了。接着,这条记录被添加到一个记录批次里(Segment),这个批次原创 2021-04-22 23:27:46 · 8992 阅读 · 44 评论 -
Java面试——消息队列
一、消息队列的使用场景☞ 以下介绍消息队列在实际应用常用的使用场景。异步处理、应用解耦、流量削锋和消息通讯四个场景。【1】异步处理:场景说明:用户注册后,需要发注册邮件和注册短信。引入消息队列后架构如下:用户的响应时间=注册信息写入数据库的时间,例如50毫秒。发注册邮箱、发注册短信写入消息队列后,直接返回客户端,因写入消息队列的速度很快,基本可以忽略,因此用户的响应时间可能是50毫秒。按照传统的做法①、串行方式,将注册信息写入数据库成功后,发注册邮件,再发送注册短信,以上三个成功后,返回客户端.原创 2021-04-17 15:45:25 · 3806 阅读 · 48 评论