kafka ISR设计及水印与leader epoch副本同步机制深入剖析-kafka 商业环境实战

本文主要是介绍kafka ISR设计及水印与leader epoch副本同步机制深入剖析-kafka 商业环境实战,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

版权声明:本套技术专栏是作者(秦凯新)平时工作的总结和升华,通过从真实商业环境抽取案例进行总结和分享,并给出商业应用的调优建议和集群环境容量规划等内容,请持续关注本套博客。版权声明:禁止转载,欢迎学习。QQ邮箱地址:1120746959@qq.com,如有任何商业交流,可随时联系。

1 帽子理论(Gilbert 和 Lynch )

  • 一致性

      any read operation that begins after a write operation completes must return that value, or the result of a later write operation通过某个节点的写操作结果对后面通过其它节点的读操作可见强一致性:如果更新数据后,并发访问情况下后续读操作可立即感知该更新,称为强一致性。弱一致性:如果允许之后部分或者全部感知不到该更新,称为弱一致性。最终一致性:若在之后的一段时间(通常该时间不固定)后,一定可以感知到该更新,称为最终一致性。
    
  • 可用性(Availability)

      every request received by a non-failing node in the system must result in a response任何一个没有发生故障的节点必须在有限的时间内返回合理的结果。
    
  • 分区容忍性(Partition Tolerance)

      the network will be allowed to lose arbitrarily many messages sent from one node to another部分节点宕机或者无法与其它节点通信时,各分区间还可保持分布式系统的功能。
    
  • 悖论总结:

    可用性限定在无论是否集群节点宕机,只要有活着的节点,就会立即返回请求结果。若要限制返回结果必须是最近一次写的结果,就比较悲剧,若允许分区容忍性 => 分布式系统分区之间就存在数据同步机制,那么就有可能因为分区心跳切断,导致数据不一致。

2 partition本质就是为了日志备份(对外最小的存储单元)

Kafka中topic的每个partition有一个预写式的日志文件,虽然partition可以继续细分为若干个segment文件,但是对于上层应用来说可以将partition看成最小的存储单元(一个有多个segment文件拼接的“巨型”文件),每个partition都由一些列有序的、不可变的消息组成,这些消息被连续的追加到partition中。

  • partition本质就是为了日志备份,利用多份日志文件的副本(replica)备份来共同提供冗余机制来保持系统的高可用性。
  • kafka会把副本均匀的分配到所有的Broker上。在其中所有的副本中,会挑选一个Leader副本来对外提供服务,其他的副本统称为follower副本,只能被动的向leader副本请求数据。

3 Partitioner 三分天下

下图展示了3个Partition把一个Topic主题数据流分成三份,通过Partioner路由依次追加到分区的末尾中。如果partition规则设置的合理,所有消息可以均匀分布到不同的partition里,这样就实现了水平扩展。

config/server.properties可以设置num.partitions参数,实现主题数据分流。

3 Leader副本竞选上岗(in-sync replicas)

  • 每一个分区都存在一个in-sync replicas。
  • in-sync replicas集合中的每一个副本都与leader保持同步状态,不在里面的保持不了同步状态。
  • 只有ISR中的副本才有资格被选为leader。
  • Producer写入的消息只有被ISR中的副本都接收到,才被视为"已提交"。

4 水印HW与末端位移LEO => Leader副本

  • 这里着重强调一下,Leader副本水印HW才真正决定了对外可看到的消息数量。
  • 所有的副本都有LEO和HW。
  • Leader副本水印HW的更新发生在所有的副本都更新了最新的LEO后,Leader副本最终才认为可以更新Leader副本水印。

5 ISR设计优化(replica.lag.max.messages废弃)

  • 解决了producer突然发起一大波消息,从而产生瞬时高峰流量。若设置replica.lag.max.messages=4,则follower副本会被瞬时的拉开距离,从而导致follower副本瞬间被踢出ISR。不过一段时间follower副本同步后,会再次进入ISR。
  • 同步不同步,同步不同步反复出现,是多大的性能浪费。
  • 0.9.0.0开始采用 replica. lag. time. max. ms,默认是10s,可谓是明智之举。

6 HW同步机制(Leader与follower的爱恨缠绵)

6.1 指哪打哪(HW指向哪里?)

  • 这里重点强调,都是无论HW还是LEO都是指向下一条消息
  • 举例如下:如果一个普通topic的某个分区副本的LEO是10,那么该副本当前保存了10条消息,位移值范围是[0, 9]。此时若有一个producer向该副本插入一条消息,则该条消息的位移值是10,而副本LEO值则更新成11。

6.2 Leader与follower的HW爱恨缠绵(两阶段请求定终身)

  • follower 副本会不断地向leader副本发送Fetch请求
(1)follower 副本对象何时更新LEO?
follower 副本专属线程不断地向leader副本所在broker发送FETCH请求。leader 副本发送 FETCH response 给follower副本。Follower 拿到response之后取出位移数据写入到本地底层日志中,在该过程中其LEO值会被更新。
(2)leader 端非自己副本对象何时更新LEO?
leader 端非自己副本对象 LEO值是在leader端broker处理FETCH请求过程中被更新的。
(3) follower 副本对象何时更新HW?
Follower 副本对象更新HW是在其更新本地LEO之后。一旦follower向本地日志写完数据后它就会尝试更新其HW值。
算法为取本地LEO与FETCH response中HW值的较小值
(4)leader 副本对象何时更新HW?
Leader 副本对象处理 Follower FETCH请求时在更新完leader 端非自己副本对象的LEO后将尝试更新其自己HW值producer 端写入消息会更新leader Replica的LEO副本被踢出ISR时某分区变更为leader副本后
(5)两阶段请求定终身:

第一次fetch请求仅获得了当前的数据,fetchOffset < Leader LEO, 因为leader 端的非自己的副本leo 是根据fetch请求确定的,因此,只有第二次请求时,fetchOffset才会和Leader LEO相等,进而更新 leader HW ,进而响应为 leader HW,进而更新 Folloer HW。

6.3 HW更新延迟带来的刀山火海

  • 因为 fetchOffset是实实在在的需要位移。所以只有第二轮请求时,Follower才会在其现有位移的基础上,加1进行请求,从而连锁更新 Leader非自己remoteLEO 和 Leader HW 和 Follower HW。
  • 刀山火海就在一轮请求和第二轮请求之间发生了。

7 刀山火海敬请期待

本文实在麻烦,大牛的技术博客看起来总总有些词不达意,我顺便就直接口语化,希望带来不同的效果。技术就是一层窗户纸,看我把kafka和spark剖析的体无完肤。香港美景,一览众山小,技术道路上毅然前行!!


秦凯新 于深圳 201811230124

版权声明:本套技术专栏是作者(秦凯新)平时工作的总结和升华,通过从真实商业环境抽取案例进行总结和分享,并给出商业应用的调优建议和集群环境容量规划等内容,请持续关注本套博客。版权声明:禁止转载,欢迎学习。QQ邮箱地址:1120746959@qq.com,如有任何商业交流,可随时联系。

这篇关于kafka ISR设计及水印与leader epoch副本同步机制深入剖析-kafka 商业环境实战的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/441261

相关文章

C++如何通过Qt反射机制实现数据类序列化

《C++如何通过Qt反射机制实现数据类序列化》在C++工程中经常需要使用数据类,并对数据类进行存储、打印、调试等操作,所以本文就来聊聊C++如何通过Qt反射机制实现数据类序列化吧... 目录设计预期设计思路代码实现使用方法在 C++ 工程中经常需要使用数据类,并对数据类进行存储、打印、调试等操作。由于数据类

Python列表去重的4种核心方法与实战指南详解

《Python列表去重的4种核心方法与实战指南详解》在Python开发中,处理列表数据时经常需要去除重复元素,本文将详细介绍4种最实用的列表去重方法,有需要的小伙伴可以根据自己的需要进行选择... 目录方法1:集合(set)去重法(最快速)方法2:顺序遍历法(保持顺序)方法3:副本删除法(原地修改)方法4:

在Spring Boot中浅尝内存泄漏的实战记录

《在SpringBoot中浅尝内存泄漏的实战记录》本文给大家分享在SpringBoot中浅尝内存泄漏的实战记录,结合实例代码给大家介绍的非常详细,感兴趣的朋友一起看看吧... 目录使用静态集合持有对象引用,阻止GC回收关键点:可执行代码:验证:1,运行程序(启动时添加JVM参数限制堆大小):2,访问 htt

JS+HTML实现在线图片水印添加工具

《JS+HTML实现在线图片水印添加工具》在社交媒体和内容创作日益频繁的今天,如何保护原创内容、展示品牌身份成了一个不得不面对的问题,本文将实现一个完全基于HTML+CSS构建的现代化图片水印在线工具... 目录概述功能亮点使用方法技术解析延伸思考运行效果项目源码下载总结概述在社交媒体和内容创作日益频繁的

Python如何自动生成环境依赖包requirements

《Python如何自动生成环境依赖包requirements》:本文主要介绍Python如何自动生成环境依赖包requirements问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑... 目录生成当前 python 环境 安装的所有依赖包1、命令2、常见问题只生成当前 项目 的所有依赖包1、

深入理解Apache Kafka(分布式流处理平台)

《深入理解ApacheKafka(分布式流处理平台)》ApacheKafka作为现代分布式系统中的核心中间件,为构建高吞吐量、低延迟的数据管道提供了强大支持,本文将深入探讨Kafka的核心概念、架构... 目录引言一、Apache Kafka概述1.1 什么是Kafka?1.2 Kafka的核心概念二、Ka

SpringRetry重试机制之@Retryable注解与重试策略详解

《SpringRetry重试机制之@Retryable注解与重试策略详解》本文将详细介绍SpringRetry的重试机制,特别是@Retryable注解的使用及各种重试策略的配置,帮助开发者构建更加健... 目录引言一、SpringRetry基础知识二、启用SpringRetry三、@Retryable注解

SpringKafka错误处理(重试机制与死信队列)

《SpringKafka错误处理(重试机制与死信队列)》SpringKafka提供了全面的错误处理机制,通过灵活的重试策略和死信队列处理,下面就来介绍一下,具有一定的参考价值,感兴趣的可以了解一下... 目录引言一、Spring Kafka错误处理基础二、配置重试机制三、死信队列实现四、特定异常的处理策略五

Redis在windows环境下如何启动

《Redis在windows环境下如何启动》:本文主要介绍Redis在windows环境下如何启动的实现方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录Redis在Windows环境下启动1.在redis的安装目录下2.输入·redis-server.exe

Pytest多环境切换的常见方法介绍

《Pytest多环境切换的常见方法介绍》Pytest作为自动化测试的主力框架,如何实现本地、测试、预发、生产环境的灵活切换,本文总结了通过pytest框架实现自由环境切换的几种方法,大家可以根据需要进... 目录1.pytest-base-url2.hooks函数3.yml和fixture结论你是否也遇到过