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

相关文章

Pandas使用SQLite3实战

《Pandas使用SQLite3实战》本文主要介绍了Pandas使用SQLite3实战,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学... 目录1 环境准备2 从 SQLite3VlfrWQzgt 读取数据到 DataFrame基础用法:读

java中反射(Reflection)机制举例详解

《java中反射(Reflection)机制举例详解》Java中的反射机制是指Java程序在运行期间可以获取到一个对象的全部信息,:本文主要介绍java中反射(Reflection)机制的相关资料... 目录一、什么是反射?二、反射的用途三、获取Class对象四、Class类型的对象使用场景1五、Class

Python 中的异步与同步深度解析(实践记录)

《Python中的异步与同步深度解析(实践记录)》在Python编程世界里,异步和同步的概念是理解程序执行流程和性能优化的关键,这篇文章将带你深入了解它们的差异,以及阻塞和非阻塞的特性,同时通过实际... 目录python中的异步与同步:深度解析与实践异步与同步的定义异步同步阻塞与非阻塞的概念阻塞非阻塞同步

Python实战之屏幕录制功能的实现

《Python实战之屏幕录制功能的实现》屏幕录制,即屏幕捕获,是指将计算机屏幕上的活动记录下来,生成视频文件,本文主要为大家介绍了如何使用Python实现这一功能,希望对大家有所帮助... 目录屏幕录制原理图像捕获音频捕获编码压缩输出保存完整的屏幕录制工具高级功能实时预览增加水印多平台支持屏幕录制原理屏幕

一文带你深入了解Python中的GeneratorExit异常处理

《一文带你深入了解Python中的GeneratorExit异常处理》GeneratorExit是Python内置的异常,当生成器或协程被强制关闭时,Python解释器会向其发送这个异常,下面我们来看... 目录GeneratorExit:协程世界的死亡通知书什么是GeneratorExit实际中的问题案例

最新Spring Security实战教程之Spring Security安全框架指南

《最新SpringSecurity实战教程之SpringSecurity安全框架指南》SpringSecurity是Spring生态系统中的核心组件,提供认证、授权和防护机制,以保护应用免受各种安... 目录前言什么是Spring Security?同类框架对比Spring Security典型应用场景传统

最新Spring Security实战教程之表单登录定制到处理逻辑的深度改造(最新推荐)

《最新SpringSecurity实战教程之表单登录定制到处理逻辑的深度改造(最新推荐)》本章节介绍了如何通过SpringSecurity实现从配置自定义登录页面、表单登录处理逻辑的配置,并简单模拟... 目录前言改造准备开始登录页改造自定义用户名密码登陆成功失败跳转问题自定义登出前后端分离适配方案结语前言

Centos环境下Tomcat虚拟主机配置详细教程

《Centos环境下Tomcat虚拟主机配置详细教程》这篇文章主要讲的是在CentOS系统上,如何一步步配置Tomcat的虚拟主机,内容很简单,从目录准备到配置文件修改,再到重启和测试,手把手带你搞定... 目录1. 准备虚拟主机的目录和内容创建目录添加测试文件2. 修改 Tomcat 的 server.X

OpenManus本地部署实战亲测有效完全免费(最新推荐)

《OpenManus本地部署实战亲测有效完全免费(最新推荐)》文章介绍了如何在本地部署OpenManus大语言模型,包括环境搭建、LLM编程接口配置和测试步骤,本文给大家讲解的非常详细,感兴趣的朋友一... 目录1.概况2.环境搭建2.1安装miniconda或者anaconda2.2 LLM编程接口配置2

VSCode配置Anaconda Python环境的实现

《VSCode配置AnacondaPython环境的实现》VisualStudioCode中可以使用Anaconda环境进行Python开发,本文主要介绍了VSCode配置AnacondaPytho... 目录前言一、安装 Visual Studio Code 和 Anaconda二、创建或激活 conda