惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

罗磊的独立博客
G
Google Developers Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
腾讯CDC
有赞技术团队
有赞技术团队
Vercel News
Vercel News
MongoDB | Blog
MongoDB | Blog
M
MIT News - Artificial intelligence
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
B
Blog RSS Feed
I
InfoQ
Blog — PlanetScale
Blog — PlanetScale
博客园_首页
The Cloudflare Blog
B
Blog
C
Check Point Blog
Stack Overflow Blog
Stack Overflow Blog
IT之家
IT之家
U
Unit 42
D
Docker
月光博客
月光博客
aimingoo的专栏
aimingoo的专栏
博客园 - Franky
A
About on SuperTechFans

mafeifan 的编程技术分享

mafengwo-mp3-downloader | mafeifan 的编程技术分享 示例页面 | mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 查看 default namespace 下的 default service account名称 mafeifan 的编程技术分享 检查日志 | mafeifan 的编程技术分享 bridge fdb show dev flannel.1 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享 mafeifan 的编程技术分享
mafeifan 的编程技术分享
2026-01-16 · via mafeifan 的编程技术分享

消息队列的两种模式

基本概念 ​

  • 一台服务器就是一个broker,一个集群由多个broker组成,一个broker可以有多个topic,一个topic可以有多个partition分区,一个partition可以有多个segment

  • topic: 可以理解为一个队列或文件系统中的文件夹,所有的生产者和消费者都是面向topic的。每个partitions一般都会有一个消费者。

  • Kafka 通过分区来实现数据冗余和伸缩性。分区可以分布在不同的服务器上,也就是说,一个主题可以横跨多个服务器,以此来提供比单个服务器更强大的性能。

  • Kafka broker 默认的消息保留策略是这样的:要么保留一段时间(比如 7 天),要么保留到消息达到一定大小的字节数(比如 1GB)。当消息数量达到这些上限时,旧消息就会过期并被删除,所以在任何时刻,可用消息的总量都不会超过配置参数所指定的大小。

  • 分区数的确定可以用主题吞吐量除以消费者吞吐量估算,如果每秒钟要从主题上写入和读取 1GB 的数据,并且每个消费者每秒钟可以处理 50MB 的数据,那么至少需要 20 个分区。这样就可以让 20 个消费者同时读取这些分区,从而达到每秒钟 1GB 的吞吐量。

  • 主题可以配置自己的保留策略。例如,用于跟踪用户活动的数据可能需要保留几天,而应用程序的度量指标可能只需要保留几个小时。

  • Kafka 使用 Zookeeper 保存 Broker 的元数据,Kafka3 中使用Zookeeper已经不是必须的了

ack应答 ​

三种qos:

  • 级别0:不等待broker的ack回应,直接返回,毕竟没有经过leader与follower确认,优点是快,缺点是不可靠,生产环境很少使用

  • 级别1:Producer发送消息到broker后,会等待leader落盘后再给producer返回信号,告诉producer数据已经收到了,但是也存在一种情况,那就是follower没有确认数据是否落盘,如果存在leader于follower数据不一致的情况,又碰巧leader挂了,选举了一个数据不健全的follower为新的leader,这就造成了数据丢失。所以它可靠性中等,性能不如0级。传输日志,允许丢失个别数据

  • 级别-1:他要等leader与isr(可以看做一些比较活跃的follower集合)中follower确认全部落盘后在给producer回应,这种方式可靠,但是牺牲了性能,所以它是三种模式里最慢的。跟钱相关的数据,不允许丢失

  • 数据完全可靠条件:ACK级别为-1 + 分区副本数>=2 + ISR 应答的最小副本数量>=2

  • 精确一次 = 幂等性 + ACK级别为-1 + 分区副本数>=2 + ISR 应答的最小副本数量>=2

参考 ​

https://www.cnblogs.com/rainple/p/15914065.html