深入Kafka client

分区分配策略

客户端可以自定义分区分配策略, 当然也需要考虑分区消费之后的offset提交, 是否有冲突。

消费者协调器和组协调器

a. 消费者的不同分区策略, 消费者之间的负载均衡(新消费者加入或者存量消费者退出), 需要broker做必要的协调。
b. Kafka按照消费组管理消费者, 鉴于offset提交最终都是在某个broker节点上完成。该broker扮演GroupCoordinator角色, 具体的选择则是通过hash快速定位。
c. client端存在一个ClientCoordinator与目标的GroupCoordinator进行通信实现最终协调;
d. 具体过程如下

ClientCoordinator Broker(Min Load) Broker(GroupCoordinator) Broker(To consumer) 1. Find_Coordinator request Find_Coordinator response 2. Join_Group request 3.1 calculate brokerId 3.2 Elect leader consumer 3.3 Elect partition strategy . Join_Group response, isLeader 4. Sync_Group Request Sync_Group Response 5. Poll offset/message, HeartBeat response offset/heartbeat/message ClientCoordinator Broker(Min Load) Broker(GroupCoordinator) Broker(To consumer)

关于__consumer_offset

__consumer_offset是一个特殊的topic, 用于存储每个topic中partition中client提交的offset。其中的数据保留时间通过offset.retention.minutes配置。如果consumer消费消息的间隔超过了配置时间, 则offset会丢失, consumer再次获取offset时会因为没有存量的offset而自动重置(auto.offset.reset)。该topic下的消息清理采用压缩策略(仅保留最新消息)。Kafka中会有定时清理任务清理过期的消费位移。

消息发送QoS

  1. at-least-once, 至少一次, 消息不会丢失, 但消息会重复;
  2. at-most-once, 至多一次, 消息不会重复, 但可能会丢失;
  3. exact-once, 恰好一次, 消息肯定被传输且只传输一次;(如果开发即时消息系统, 那么这个语义就是我们的目标)
    默认情况下, Kafka producer在发送时, 如果消息发送失败会自动进行重试, 重试过程可能会导致消息重复。而一旦发送成功, Kafka通过多副本机制保证消息一定会被保存。因此从consumer角度观察, producer发送的结果, 其QoS是at-least-once。如果需要exact-once, 则需要启用Kafka的幂等特性。

幂等

  1. 配置参数
    enable.idompotence=true
    retrics > 0
    max.in.flight.requests.per.connection <=5
    ack=-1

  2. 实现细节
    首先幂等是partition级别, broker端自动为producer分配一个PID, 并维护PID->分区(序列号 lastSeq) 的状态。当producer发送消息时, 必须携带该序列号newSeq。broker端收到消息时做校验:
    a. newSeq = lastSeq+1, broker接收;
    b. newSeq > lastSeq+1, 中间存在消息丢失, 抛出OutOfOrderException;
    c. newSeq < lastSeq+1, 消息存在重复, 直接丢弃即可.

事务消息

如果要实现跨parition的exact-once语义, 则需要基于事务消息。一般来说事务有ACID的特性, 但这个是数据库事务的通用场景。Kafka下消息需要考虑生产和消费, 这里的事务消息更多是生产端的事务消息。消费端可能会因为某些原因无法以事务的形式消费。比如:

  1. 对于采用日志压缩策略的主题而言, 事务中的消息被清理(对相同key的消息后写入的消息会覆盖之前写入的消息);
  2. 事务涉及的分区多个日志段, 如果老的日志分段被删除, 对应的消息也会消失;
  3. 消费者通过seek消费消息, 造成消息遗漏;
  4. 消费者在消费时没有消费到事务涉及的所有分区, 因此不能读取事务中的所有消息;
    总的来说, 事务保证了生产者可以以事务的方式实现消息发送的exact
    -once语义, 但消息清理和消费并未引入事务约束。

实现原理

  1. 开启幂等;
  2. 设置事务ID, transactional.id;
  3. 生产者通过事务ID得到PID和producer epoch, 进而实现跨生产者会话的消息发送和事务恢复。前者保证相同transactionId的生产者仅有1个可以有效发送消息, 后者保证如果事务消息发送后宕机新恢复出来的生产者可以继续提交或者终止事务。其中包含2个方面, 生产者的唯一性, 其关联的在途事务的可见性和可操作性。
  4. broker端为支持事务消息引入了事务协调器, 与组协调器类似, 用于处理事务的提交和终止。
  5. 具体交互流程如下
    发送事务消息交互细节

事务存储

  1. 日志存储按Topic, Partition和LogSegment层级存储, 事务消息也不例外;
  2. 与普通消息的区别是, 事务消息更多适用于发送一组消息的场景, 具体到LogSegment就是有一组连续的消息, 因此Kafka引入了ControlBatch消息来标志消息结束。
  3. 事务消息的开始在哪里呢? 严格来说, producer跨分区发送成功后, consumer是无法恢复出原有的顺序, 在分区级别仅可以做到与某个事务关联的一组消息(通过消息的属性标志是否为事务消息), 结束通过ControlBatch标志一组消息结束。

小结

本文讨论了Kafka发送消息的三种语义at-least-once, at-most-once, exact-once,并针对exact-once的单分区实现(幂等控制)和跨分区实现(事务消息)做简要介绍, 希望能帮助你梳理出Kafka broker端对消息发送QoS实现的基本脉络, 为进一步学习打基础。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.hqwc.cn/news/506225.html

如若内容造成侵权/违法违规/事实不符,请联系编程知识网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

每日一题——LeetCode1566.重复至少K次且长度为M的模式

方法一 暴力枚举 var containsPattern function(arr, m, k) {const n arr.length;for (let l 0; l < n - m * k; l) {let offset;for (offset 0; offset < m * k; offset) {if (arr[l offset] ! arr[l offset % m]) {break;}}if (offset m * k) {return true;}}r…

【数据结构与算法】整数二分

问题描述 对一个排好序的数组&#xff0c;要求找到大于等于7的最小位置和小于等于7的最大位置 大于等于7的最小位置 易知从某个点开始到最右边的边界都满足条件&#xff0c;我们要找到这个区域的最左边的点。 开始二分&#xff01; left指针指向最左边界&#xff0c;right…

【JGit 】一个完整的使用案例

需求 生成一系列结构相同的项目代码&#xff0c;将这些项目的代码推送至一个指定的 Git 仓库&#xff0c;每个项目独占一个分支。 推送时若仓库不存在&#xff0c;则自动创建仓库。 分析 生成代码使用 Java 程序模拟&#xff0c;每个项目中模拟三个文件。Project.cpp 、Pro…

C习题002:澡堂洗澡

问题 输入样例 在这里给出一组输入。例如&#xff1a; 2 5 1 3 3 2 3 3 输出样例 在这里给出相应的输出。例如&#xff1a; No代码长度限制 16 KB 时间限制 400 ms 内存限制 64 MB 栈限制 8192 KB 代码 #include<stdio.h> int main() {int N,W,s,t,p;int arr_s[…

将任何网页变成桌面应用,全平台支持 | 开源日报 No.184

tw93/Pake Stars: 20.9k License: MIT Pake 是利用 Rust 轻松构建轻量级多端桌面应用的工具。 与 Electron 包大小相比几乎小了 20 倍&#xff08;约 5M&#xff01;&#xff09;使用 Rust Tauri&#xff0c;Pake 比基于 JS 的框架更轻量和更快内置功能包括快捷方式传递、沉浸…

测试需求平台9-Table 组件应用产品列表优化

✍此系列为整理分享已完结入门搭建《TPM提测平台》系列的迭代版&#xff0c;拥抱Vue3.0将前端框架替换成字节最新开源的arco.design&#xff0c;其中约60%重构和20%新增内容&#xff0c;定位为从 0-1手把手实现简单的测试平台开发教程&#xff0c;内容将囊括基础、扩展和实战&a…

(每日持续更新)信息系统项目管理(第四版)(高级项目管理)考试重点整理 第13章 项目资源管理(一)

项目建议与立项申请、初步可行性研究、详细可行性研究、评估与决策是项目投资前使其的四个阶段。在实际工作中&#xff0c;初步可行性研究和详细可行性研究可以依据项目的规模和繁简程度合二为一&#xff0c;但详细可行性研究是不可缺少的。升级改造项目制作初步和详细研究&…

2024年十大前景职业揭晓!提前布局,抢占未来职场制高点!

随着科技的飞速发展和社会的不断进步&#xff0c;各行各业都在经历着翻天覆地的变化。2024年即将到来&#xff0c;哪些职业将会成为未来的热门选择呢&#xff1f;本文将为您揭晓2024年十大前景职业&#xff0c;助您提前布局&#xff0c;抢占未来职场制高点&#xff01; 一、人…

Covalent Network(CQT)将链下收入引入链上,在全新阶段开启 Token 回购

Covalent Network&#xff08;CQT&#xff09;&#xff0c;是 Web3 领域跨越 225 个链的领先数据索引服务商&#xff0c;通过统一 API 的方式提供结构化数据可用性服务&#xff0c;并正在成为 AI、DeFi、分析和治理等多样化需求的关键参与者。为了支持去中心化技术的采用&#…

分布式系统中常用的缓存方案

1. 引言 随着互联网应用的发展和规模的不断扩大&#xff0c;分布式系统中的缓存成为了提升性能和扩展性的重要手段之一。本文将介绍几种在分布式系统中常用的缓存方案&#xff0c;包括分布式内存缓存、分布式键值存储、分布式对象存储和缓存网关等。 1.1 缓存在分布式系统中的…

基于 Amazon EKS 的 Stable Diffusion ComfyUI 部署方案

01 背景介绍 Stable Diffusion 作为当下最流行的开源 AI 图像生成模型在游戏行业有着广泛的应用实践&#xff0c;无论是 ToC 面向玩家的游戏社区场景&#xff0c;还是 ToB 面向游戏工作室的美术制作场景&#xff0c;都可以发挥很大的价值&#xff0c;如何更好地使用 Stable Dif…

【高级数据结构】Trie树

原理 介绍 高效地存储和查询字符串的数据结构。所以其重点在于&#xff1a;存储、查询两个操作。 存储操作 示例和图片来自&#xff1a;https://blog.csdn.net/qq_42024195/article/details/88364485 假设有这么几个字符串&#xff1a;b&#xff0c;abc&#xff0c;abd&…