首页
Python
Java
IOS
Andorid
NodeJS
JavaScript
HTML5
kafka技术内幕 读书笔记
2024-09-06
Kafka技术内幕 读书笔记之(四) 新消费者——心跳任务
消费者拉取数据是在拉取器中完成的,发送心跳是在消费者的协调者上完成的,但并不是说拉取器和消费者的协调者就没有关联关系 . “消费者的协调者”的作用是确保客户端的消费者和服务端的协调者之间的正常通信,如果消费者没有连接上协调者(比如协调者认为消费者挂了,或者消费者认或者消费者认为协调者挂了),那么拉取器的拉取工作以及后续的消息消费等工作就都无法正常进行. 每个消费者都需要定时地向协调者发送心跳,以表明向己是存活的 . 如果消费者一段时间内没有发送心跳,协调者就会认为消费者挂掉了 . 协调者还要能够
Kafka技术内幕 读书笔记之(一) Kafka入门
在0.10版本之前, Kafka仅仅作为一个消息系统,主要用来解决应用解耦. 异步消息 . 流量削峰等问题. 在0.10版本之后, Kafka提供了连接器与流处理的能力,它也从分布式的消息系统逐渐成为一个流式的数据平台 . Kafka 流式数据平台 作为一个流式数据平台,最重要的是要具备下面3个特点 . 类似消息系统,提供事件流的发布和订阅,即具备数据注入功能 : 存储事件流数据的节点具有故障容错的特点,即具备数据存储功能 : 能够对实时的事件流进行流式地处理和分析,即具备流处理功能 . Kaf
Kafka技术内幕 读书笔记之(六) 存储层——服务端处理读写请求、分区与副本
如下图中分区到 日 志的虚线表示 : 业务逻辑层的一个分区对应物理存储层的一个日志 . 消息集到数据文件的虚线表示 : 客户端发送的消息集最终会写入日志分段对应的数据文件,存储到Kafka的消息代理节点 . Kafka服务在启动时会先创建各种相关的组件,最后才会创建 KafkaApis . 业务组件一般都有后台的线程,除了创建组件后,也要启动这些后台线程. 消费者客户端发送“加入组请求”和“同步组请求”给服务端,服务端通过KafkaApis将每请求的处理交给消费组的协调者( GroupCoor
Kafka技术内幕 读书笔记之(六) 存储层——日志的读写
-Kafka是一个分布式的( distributed ).分区的( partitioned ).复制的( replicated )提交日志( commitlog )服务 . “分布式”是所有分布式系统的特性 :“分区”指消息会按照分区分布在集群的所有节点上 :“复制”指每个分区都会有多个副本存储在不同的节点上:“提交日志”指新的消息总是以追加的方式进行存储. 写到提交日志的目的是防止节点宕机后,因内存中的数据来不及刷写到磁盘而导致数据丢失 . 分布式存储系统除了提交日志,一般还有真正的数据存储格
Kafka技术内幕 读书笔记之(五) 协调者——消费组状态机
协调者保存的消费组元数据中记录了消费组的状态机 , 消费组状态机的转换主要发生在“加入组请求”和“同步组请求”的处理过程中 .协调者处理“离开消费组请求”“迁移消费组请求”“心跳请求” “提交偏移量请求”也会更新消费组的状态.机,或者依赖消费组的状态进行不同的处理.消费者要加入消费组 , 需要依次发送“加入组请求”和“同步组请求”给协调者 . 消费者加入组的过程叫作再平衡,因为协调者处理这两种请求会更新消费组状态,所以再平衡操作跟消费组状态也息息相关. 监听器回调方法和再平衡操作的执行顺序如下
Kafka技术内幕 读书笔记之(五) 协调者——延迟的加入组操作
协调者处理不同消费者的“加入组请求”,由于不能立即返回“加入组响应”给每个消费者,它会创建一个“延迟操作”,表示协调者会延迟发送“加入组响应”给消费者 . 但协调者不会为每个消费者的 “加入组请求”都创建一个 “延迟操作”,而是仅当消费组状态从“稳定”转变为“准备再平衡”,才创建一个“延迟操作”对象 . (1)初始时消费组状态为“稳定”,第一个消费者加入消费组 . 因为消费组状态为“稳定”,所以协调者允许消费者执行再平衡操作 .协调者更改消费 组的状态为“准备再平衡”,并创建一个
Kafka技术内幕 读书笔记之(五) 协调者——消费者加入消费组
消费者客户端轮询的3个步骤:发送拉取请求,客户端轮询,获取拉取结果 . 消费者在发送拉取请求之前,必须首先满足下面的两个条件.- 确保消费者已经连接协调者, 即找到服务端中管理这个消费者的协调者节点 .- 确保消费者已经分配到分区, 即获取到协调者节点分配给消费者的分区信息 . 消费者客户端除了从协调者节点获取到分区,还会发送心跳请求.提交偏移量给协调者节点 . 其中,提交偏移量主要和消息的处理有关,协调者只是作为偏移量的存储介质. 而消费者发送心跳请求给协调者,则有可能归现各种各样的问题,如下
Kafka技术内幕 读书笔记之(四) 新消费者——消费者提交偏移量
消费组发生再平衡时分区会被分配给新的消费者,为了保证新消费者能够从分区的上一次消费位置继续拉取并处理消息,每个消费者需要将分区的消费进度,定时地同步给消费组对应的协调者节点 .新AP I为客户端提供了两种提交偏移盐的方式:异步模式和同步模式 . 另外,如果消费者客户端设置了向动提交( enable . auto . commit=true ,默认开启)的选项,会在客户端的轮询操作中调度定时任务,定时任务也属于异步模式提交偏移量的一种运用场景 自动提交任务 如果消费者开启自动提交 消费者会通过“消
Kafka技术内幕 读书笔记之(四) 新消费者——新消费者客户端(二)
消费者拉取消息 消费者创建拉取请求的准备工作,和生产者创建生产请求的准备工作类似,它们都必须和分区的主副本交互.一个生产者写入的分区和消费者分配的分区都可能有多个,同时多个分区的主副本有可能在同一个节点上 . 为了减少客户端和服务端集群的网络连接,客户端并不是以分区为粒度和服务端交互,而是以服务端节点为粒度 .如果分区的主副本在同一个节点上,应当在客户端先把数据按照节点整理好,把属于同一个节点的多个分区作为一个请求发送出去 . 一个消费者可以允许同时向多个主副本节点发送请求,这个请求包括属于这个
Kafka技术内幕 读书笔记之(三) 消费者:高级API和低级API——消费者消费消息和提交分区偏移量
消费者拉取钱程拉取每个分区的数据,会将分区的消息集包装成一个数据块( FetchedDataChunk )放入分区信息的队列中 . 而每个队列都对应一个消息流( KafkaStream ),消费者客户端选代消息流,实际上是迭代每个数据块中消息集的每条消息 . 一个队列包含多个数据块,每个数据块对应一个分区的消息集, 一个消息集包含多条消息 . 消费者迭代器( ConsumerIterator)封装了迭代获取消息的逻辑,客户端不需要面向数据块.消息集这些内部对象,只需要对消费者迭代器循环获取消息即
Kafka技术内幕 读书笔记之(三) 生产者——消费者:高级API和低级API——基础知识
1. 使用消费组实现消息队列的两种模式 分布式的消息系统Kafka支持多个生产者和多个消费者,生产者可以将消息发布到集群中不同节点的不同分区上:消费者也可以消费集群中多个节点的多个分区上的消息 . 写消息时,多个生产者可以写到同一个分区 . 读消息时,如果多个消费者同时读取一个分区,为了保证将日志文件的不同数据分配给不同的消费者,需要采用加锁 . 同步等方式,在分区级别的日志文件上做些控制 . 如果约定“同一个分区只可被一个消费者处理”,就不需要加锁同步了,从而可提升消费者的处理能力 . 下图给
Kafka技术内幕 读书笔记之(二) 生产者——服务端网络连接
KafkaServer是Kafka服务端的主类, KafkaServer中和网络层有关的服务组件包括 SocketServer.KafkaApis 和 KafkaRequestHandlerPool后两者都使用了 SocketServer暴露出来的请求通道( RequestChannel )来处理网络请求 . SocketServer主要关注网络层的通信协议,具体的业务处理逻辑 则交给KafkaRequestHandler和 KafkaApis来完成 . SocketServer和这两个组件一起
Kafka技术内幕 读书笔记之(二) 生产者——新生产者客户端
消息系统通常由生产者(producer ). 消费者( consumer )和消息代理( broker ) 三大部分组成,生产者会将消息写入消息代理,消费者会从消息代理中读取消息 . 对于消息代理而言,生产者和消费者都属于客户端:生产者和消费者会发送客户端请求给服务端,服务端的处理分别是存储消息和获取消息,最后服务端返回响应结果给客户端. 这里主要分析新旧两个版本的生产者客户端,以及服务端的网络连接实现. 新生产者客户端 Kafka初期使用 Sca la编写 . 最新的客户端使用了 Java重新
Kafka技术内幕 读书笔记之(五) 协调者——协调者处理请求
消费者客户端使用“消费者的协调者对象”( ConsumerCoordinator )来代表所有和服务端协调者节点有关的请求处理,比如心跳请求.获取和提交分区的偏移量(自动提交任务).发送“加入组请求”和“同步组请求”从协调者获取到分区 . 服务端处理客户端请求的人口都是KafkaApis类,它会针对不同的请求类型分发给不同的方法处理 . 服务端定义发送响应结果的回调方法 不同消费者在不同时刻发送请求给服务端,服务端并不会立即发送响应结果给消费者. 为了保证服务端的高性能,虽然服务端不能立即返回响
Struts2技术内幕 读书笔记一 框架的本质
本读书笔记系列,主要针对陆舟所著<<Struts2技术内幕 深入解析Strtus2架构设计与实现原理>>一书.笔记中所用的图片若无特殊说明,就都取自书中,特此声明. 什么是框架?我们为什么要用框架?框架能给我们带来什么? 这几个问题既简单又复杂.说它简单,是因为框架确实存在在软件设计中,说它复杂是因为我们现在所使用的框架不论是spring还是struts都是经过多年的发展,其内部已经十分庞杂了,因此想一句话两句话说清楚一个框架就不是那么简单了. OK,既然现有的框架都很复杂,那我们
Struts2技术内幕 读书笔记三 表示层的困惑
表示层能有什么疑惑?很简单,我们暂时忘记所有的框架,就写一个注册的servlet来看看. index.jsp <form id="form1" name="form1" method="post" action="loginServlet"> <table width="357" border="0" align="center"> <t
深入理解linux网络技术内幕读书笔记(三)--用户空间与内核的接口
Table of Contents 1 概论 1.1 procfs (/proc 文件系统) 1.1.1 编程接口 1.2 sysctl (/proc/sys目录) 1.2.1 编程接口 1.3 sysfs (/sys 文件系统) 1.4 ioctl 系统调用 1.5 netlink 套接字 概论 procfs (/proc 文件系统) 允许内核以文件的形式向用户空间输出内部信息. 可以通过cat, more和> shell重定向进行查看与写入. 编程接口 内核proc文件系统与seq接口(1)
Struts2技术内幕 读书笔记二 web开发的基本模式
最佳实践 在讨论基本模式之前,我们先说说一个词:最佳实践 任何程序的编写都得遵循一个特定的规范.这种规范有约定俗称的例如:包名全小写,类名每个单词第一个字母大写等等等等;另外还有一些需要我们严格遵守的:例如我们写自己的servlet的时候就得继承javax.servlet.http.HttpServlet接口. 在标准之上的是对不同标准的具体实现.例如同是servlet标准,tomcat有一套实现方式,Websphere又有不同的实现方式. 在程序员级别来说,面对复杂的业务流程,不同的程序员会有
MySQL技术内幕读书笔记(八)——事务
事务的实现 事务隔离性由锁来实现.原子性.一致性.持久性通过数据库的redo log和undo log来完成.redo log称为重做日志,用来保证事务的原子性和持久性.undo log用来保证事务的一致性. redo和undo作用都是一种恢复操作. redo: 恢复提交事务修改的页操作, 物理日志,记录的是页的物理修改操作. 保证事务的持久性 顺序写 undo: 回滚行记录到某个特定版本 逻辑日志,根据每行进行记录 帮助事务回滚和MVCC功能 随机读写 redo 基本概念 重做日志用来
MySQL技术内幕读书笔记(七)——锁
锁 锁是数据库系统区分与文件系统的一个关键特性.为了保证数据一致性,必须有锁的介入.数据库系统使用锁是为了支持对共享资源进行并发访问,提供数据的完整性和一致性. lock与latch 使用命令可以查询latch信息 SHOW ENGINE INNODB MUTEX; 对于lock信息查看就很直观 1.SHOW ENGINE INNODB STATUS 2.information_schema架构下的表INNODB_TRX INNODB_LOCKS INNODB_LOCK_WAITS
热门专题
oracle 非归档模式 连续备份
sqlserver 大数据插入
extract($_POST) 二维数组
redisTemplate特定Key失效回调事件
win7nodejs配置环境变量
C# ISubscriber.Subscribe 订阅状态
python标准异常有哪些
windows自带的dos
xxljob调用第三方接口
springboot整合graylog
memcache支持简单数据类型
tp5 图片上传 base64
sqlserver 同时删除两个表的数据
er图描述不同权限的用户
物理机centos只有一个lo
多一个catalina.%Y-%m-%d.out
centos 7已安装samba,但启动不起来
c# arrary转成list
tomcat日志保存项目日志中
Postgres 空闲连接查看