摘要：一、 _consumer_offsets主题 ### zookeeper不适合大批量的频繁写入操作 ~~~ Zookeeper不适合大批量的频繁写入操作。 ~~~ Kafka 1.0.2将consumer的位移信息保存在Kafka内部的topic中，即__consumer_offsets主题， ~~
阅读全文
摘要：一、生产者阶段重复场景 ### 消息重复的场景及解决方案 ~~~ # 消息重复和丢失是kafka中很常见的问题，主要发生在以下三个阶段： ~~~ 生产者阶段 ~~~ broke阶段 ~~~ 消费者阶段 ### 根本原因 ~~~ 生产发送的消息没有收到正确的broke响应，导致生产者重试。 ~~~ 生
阅读全文
摘要：一、消费者数据重复场景及解决方案 ### 根本原因 ~~~ 数据消费完没有及时提交offset到broker。 ### 场景 ~~~ 消息消费端在消费过程中挂掉没有及时提交offset到broke， ~~~ 另一个消费端启动拿之前记录的offset开始消费， ~~~ 由于offset的滞后性可能会导
阅读全文
摘要：一、HW和LEO异常案例 ### HW和LEO异常案例 ~~~ Kafka使用HW值来决定副本备份的进度，而HW值的更新通常需要额外一轮FETCH RPC才能完成。 ~~~ 但这种设计是有问题的，可能引起的问题包括： ~~~ 备份数据丢失 ~~~ 备份数据不一致 ### 数据丢失 ~~~ 使用HW值
阅读全文
摘要：一、Leader Epoch使用 ### Kafka解决方案：造成上述两个问题的根本原因在于 ~~~ # HW值被用于衡量副本备份的成功与否。 ~~~ # 在出现失败重启时作为日志截断的依据。 ~~~ 但HW值的更新是异步延迟的，特别是需要额外的FETCH请求处理流程才能更新， ~~~ 故这中间发生
阅读全文
摘要：一、HW和LEO正常更新案例 ### HW和LEO正常更新案例 ~~~ 我们假设有一个topic，单分区，副本因子是2，即一个Leader副本和一个Follower副本。 ~~~ 我们看下当producer发送一条消息时broker端的副本到底会发生什么事情以及分区HW是如何被更新的。 ### 初始
阅读全文
摘要：一、可靠性保证 ### 概念 ~~~ 创建Topic的时候可以指定--replication-factor 3 ，表示分区的副本数，不要超过broker的数量。 ~~~ Leader是负责读写的节点，而其他副本则是Follower。 ~~~ Producer只把消息发送到Leader，Followe
阅读全文
摘要：一、致性保证 ### 概念 ~~~ # 水位标记 ~~~ 水位或水印（watermark）一词，表示位置信息，即位移（offset）。 ~~~ Kafka源码中使用的名字是高水位，HW（high watermark）。 ~~~ # 副本角色 ~~~ Kafka分区使用多个副本(replica)提供高
阅读全文
摘要：一、事务操作 ### 事务操作 ~~~ # 在Kafka事务中，一个原子性操作，根据操作类型可以分为3种情况。情况如下： ~~~ 只有Producer生产消息，这种场景需要事务的介入； ~~~ 消费消息和生产消息并存，比如Consumer&Producer模式， ~~~ 这种场景是一般Kafka项目
阅读全文
摘要：一、控制器 ### 控制器 ~~~ Kafka集群包含若干个broker，broker.id指定broker的编号，编号不要重复。 ~~~ Kafka集群上创建的主题，包含若干个分区。 ~~~ 每个分区包含若干个副本，副本因子包括了Follower副本和Leader副本。 ~~~ 副本又分为ISR（
阅读全文
摘要：一、稳定性：幂等性 ### 幂等性 ~~~ Kafka在引入幂等性之前，Producer向Broker发送消息， ~~~ 然后Broker将消息追加到消息流中后给Producer返回Ack信号值。实现流程如下： ~~~ 生产中，会出现各种不确定的因素，比如在Producer在发送给Broker的时候
阅读全文
摘要：一、事务的中止 ### 事务的中止 ~~~ 当事务生产者发送业务消息的时候如果发生异常，可以中止该事务。 ~~~ 如果事务提交超时，事务协调器也会中止当前事务。 ~~~ # Producer：向事务协调器发送AbortTransaction(TxId)请求并等待响应。 ~~~ (一个没有异常的响应表
阅读全文
摘要：一、事务概览 ### 事务概览 ~~~ 生产者将表示事务开始/结束/中止状态的事务控制消息发送给 ~~~ 使用多阶段协议管理事务的高可用==事务协调器==。 ~~~ 生产者将事务控制记录（开始/结束/中止）发送到事务协调器， ~~~ 并将事务的消息直接发送到目标数据分区。 ### 消费者需要了解事务
阅读全文
摘要：一、稳定性：事务相关配置 ### 事务场景 ~~~ 如producer发的多条消息组成一个事务这些消息需要对consumer同时可见或者同时不可见。 ~~~ producer可能会给多个topic，多个partition发消息，这些消息也需要能放在一个事务里面， ~~~ 这就形成了一个典型的分布式事
阅读全文
摘要：一、 磁盘存储：顺序写入 ### 顺序写入 ~~~ 操作系统可以针对线性读写做深层次的优化， ~~~ 比如预读(read-ahead，提前将一个比较大的磁盘块读入内存) 和后写(write-behind， ~~~ 将很多小的逻辑写操作合并起来组成一个大的物理写操作)技术。 ~~~ Kafka 在设计
阅读全文
摘要：一、磁盘存储：零拷贝 ### [kafka高级特性解析] ~~~ [磁盘存储：零拷贝] ~~~ [磁盘存储：页缓存] ~~~ [磁盘存储：顺序写入] ### 零拷贝 ~~~ kafka高性能，是多方面协同的结果，包括宏观架构、分布式partition存储、ISR数据同步、 ~~~ 以及“无所不用其极
阅读全文
摘要：一、磁盘存储：页缓存 ### 页缓存 ~~~ 页缓存是操作系统实现的一种主要的磁盘缓存，以此用来减少对磁盘 I/O 的操作。 ~~~ 具体来说，就是把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问。 ~~~ Kafka接收来自socket buffer的网络数据，应用进程不需要中间处理、直
阅读全文
摘要：一、日志压缩策略 ### 概念 ~~~ 日志压缩是Kafka的一种机制，可以提供较为细粒度的记录保留， ~~~ 而不是基于粗粒度的基于时间的保留。 ~~~ 对于具有相同的Key，而数据不同，只保留最后一条数据，前面的数据在合适的情况下删除。 ### 应用场景 ~~~ 日志压缩特性，就实时计算来说，可
阅读全文
摘要：一、时间戳索引 ### 时间戳 ~~~ 在偏移量索引文件中，索引数据都是顺序记录 offset ， ~~~ 但时间戳索引文件中每个追加的索引时间戳必须大于之前追加的索引项，否则不予追加。 ~~~ 在 Kafka 0.11.0.0 以后，消息信息中存在若干的时间戳信息。 ~~~ 如果 broker 端
阅读全文
摘要：一、日志清理 ### 日志清理 ~~~ # Kafka 提供两种日志清理策略： ~~~ 日志删除：按照一定的删除策略，将不满足条件的数据进行数据删除 ~~~ 日志压缩：针对每个消息的 Key 进行整合，对于有相同 Key 的不同 Value 值，只保留最后一个版本。 ~~~ Kafka 提供 log
阅读全文
