《apache kafka 实战》读书笔记

断断续续看了点书，写个博客记录下，图片是百科找的，博客内容都是我比较感兴趣的，书里很多内容都特别详细，感兴趣的可以去买来阅读。

<第一章 认识apache kafka>

kafka核心功能？

高性能的消息发送与高性能的消息消费

消息引擎系统？

1.消息队列模型，提供了点对点的消息传递方式

生产者发布一条消息只能被一个消费者消费

2.发布/订阅模型(kafka 引入消费者组来支持这种模型)

生成者发布一条消息可以被多个消费者消费

kafka为什么高吞吐，低延时?

1.持久化数据只是将数据写入到OS的页缓存，由OS决定数据什么时候写入磁盘，页缓存在内存中分配，写入速度快，不直接与磁盘打交道，都交给了OS

2.写入操作采用追加(append)方式，只能在日志文件啊末尾追加消息，顺序写磁盘速度快

3.消费者读取消息时，会优先从页缓存中读取，"命中"的话直接网络发送socket。大量使用页缓存，"命中率"高。

基本术语？

1，消息：由消息头部(CRC码，时间戳，key长度，value长度等等)，key，value组成，key用来对该条消息进行partition，决定该消息保存在topic的哪个partition

2，topic：逻辑概念，代表一类消息，可以理解为;消息被生产者发送到的地方

3，partition：一个topic可以由一个或多个partition，单纯地为了提升系统的吞吐量，做分布式用，每个partition有自己的唯一的下标，从0开始

4，offset：partition每条消息都有一个唯一的偏移量，从0开始递增（与消费者维护的offset不一样）

5，replica：副本，防止数据丢失，分为leader和follower，follower不响应客户端的消息写入和消息消费请求，只是被动的向leader同步数据，一旦leader挂掉，从follower选举出新leader

6.ISR：同步副本集合，kafka为每个partition动态的维护一个replica集合，只有该集合中的replica才能被选举成leader，正常情况下，partition所有的replica都在ISR中，当某些replica进度"落后"leader大于某个值时，会被提出ISR，当重新追上时，会再次加入到ISR中

<第二章 kafka发展历史>

kafka版本迁移？

版本	功能变化	说明
0.8	增加了备份机制	使kafka成为分布式消息引擎解决方案
0.9.x	使用java重写了consumer	消费者组的offset可以不用通过zk保存，存在topic中
0.10.x	增加了kafka streams组件	增加流式数据处理功能
0.11.x	增加了对事务的支持以及精准一次处理语义	正式支持Exactly-Once

0.9.x版本的producer?

将待发送的消息封装成一个ProducerRecord对象，然后使用KafkaProducer.send()进行发送，KafkaProducer拿到消息后，先对其进行序列化，然后根据元数据信息确定目标分区，最后写入内存缓冲区，同时，KafkaProducer还有一个专门的Sender I/O线程，负责将缓冲区数据分批次发给broker。

producer较旧版本优点？

1，发送过程分为两个线程，一个主线程和Sender I/O线程

2，完全异步发送，回调机制用来判断发送是否成功

3，分批次发送，提高吞吐量

4，更合理的分区策略，旧版本对于没key的消息，会发送到固定分区，0.9.x采用轮询方式

0.9.x版本的consumer？

消费者组的offset不依赖于zk旧版，大量的zk I/O会成为系统瓶颈，将消息封装到ConsumerRecord对象，然后使用KafkaConsumer.poll()进行拉取数据，

consumer较旧版本优点？

1.，摒弃了消费不同分区时采用多线程的思想，只使用一个线程可以管理不同broker的多个socket

2，摆脱了offset对zk的依赖

<第三章 kafka线上环境部署>

暂时还不知道写啥。

<第四章 producer开发>

暂时还不知道写啥。

<第五章 consumer开发>

暂时还不知道写啥。

<第六章 kafka 设计原理>

一.broker端设计

1.副本与ISR

只有leader副本对外提供服务，而其它follower副本只是被动地向leader副本同步数据

ISR，为partition动态维护的同步副本集合，leader副本也在ISR中，只有ISR中的副本可以选举leader

High watermark，高水印值，超过该值的消息被视为“未提交成功”的，决定了consumer能够获取到的消息最大offset

uncommitted，未提交的消息，表示producer已发送到leader副本，而ISR中别的副本还未全部同步，也表示还未给客户端发response的消息

log end offset，日志末端位移，LEO，该值表示的位置是下一条消息要写入的位置

当leader副本接收到消息时，先更新自己的LEO，然后followe副本向leader副本请求数据后也更新follower的LEO，只有ISR的所有副本更新了自己LEO后，leader副本才将HW值向右移动，后给客户端发送写入成功。

ISR副本中什么原因导致follower被"踢出"该队列？

1.follower副本请求速度跟不上leader的接收速度
2.follower由于某些原因（GC等），一段时间内未向leader请求数据                                                                                                3.新增的副本

0.9.x版本之前对于ISR设置？

replica.lag.max.messages，该值检测如果LEO落后消息数达到该值被踢出

replica.lag.time.max.ms，该值用于检测如果follower副本多长时间以内未向leader请求数据，则被踢出

0.9.x版本之后对于ISR设置？

replica.lag.time.max.ms，该值默认10s，如果follower副本落后leader副本持续时间超过该值，被踢出

2.水印和LEO

如果把LEO和HW看作两个指针，它们的定位是不同的，任意时刻，HW指向是实实在在的消息，而LEO总是指向下一条待写入的消息的，也就是说LEO指向的位置是没有的消息的，上面那张图则表示为：HW为7，LEO为15，则消费者可消费的消息数为0-7 8条消息，而8-14是生产者已提交leader，而ISR集合别的follower还未全部请求的数据。

LEO更新机制？

1. follower副本的LEO更新机制？

follower副本的LEO属性，一份保存在leader副本所在的broker，另一份保存在follower副本所在的broker，为什么保存两份？kafka需要利用前者来确定leader副本的HW值，利用后者来帮助follower副本更新HW值

保存在follower副本所在broker的follower副本LEO更新时机？

当follower副本向leader副本请求数据后，向底层log写数据时，更新其LEO值

保存在leader副本所在broker的follower副本LEO更新时机？

当leader处理follower数据请求时，首先从log读取数据，然后更新LEO值，再发数据给follower。

2. leader副本LEO更新时机？

当接收到producer发的消息时，会更新自己的LEO

HW更新机制？

1.follower副本的HW更新时机？

follower副本更新LEO后，一旦写完log数据，更新HW值，具体方法是：比较当前follower副本LEO值与刚请求数据时leader的HW值，取小值作为follower副本的HW值，也就是follower副本的HW值不会大于leader副本的HW值

2. leader副本的HW更新时机？

正常情况：producer向leader写入数据时，更新完LEO后，查看HW是否更新

leader处理完follower副本数据请求后，查看HW是否更新

异常情况：某follower副本成为leader副本

某broker副本被踢出ISR时

具体方法：比较ISR中所有副本的LEO值（保存在leader副本所在broker的follower副本LEO），取最小的值作为HW值

因此分区的HW实际上是所有ISR副本LEO的最小值