核心概念
-
broker是kafka的节点，多台broker集群就是kafka
-
topic消息分为多个topic
-
partition分区，topic划分了多个partition分区，存在负载均衡策略
每个分区由一个个消息构成，消息在分区中被标识了递增的序号（表明了消息的偏移量）
每个分区各自维护一套偏移量
-
producer生产者，选择topic插入消息数据。根据kafka的分配策略，将消息插入某个分区队尾。
-
consumer消费者，选择topic并根据offset偏移量来获取消息数据，记录当前读取的消息的偏移量，下次读取从前一次的偏移量基础上继续读取。
消费者需要自己保存偏移量，通过修改偏移量实现读取不同位置的消息。多个消费者不会相互影响，线程安全，实现高并发消费。
-
消息数据的删除时间默认为7天
-
以partition为单位进行备份，每个partition设置一个leader（本身）和若干follower，随机分配在集群上。leader处理读写请求，follower不对外服务，拉取leader数据。
-
消费者组
偏移量实际属于消费者组。用户绑定消费者组，消费者组之间相互独立。
一条消息在一个组内只能消费一次，组中的多个用户不能多次读取这条消息
组会阻塞多用户同时访问一个分区
集群部署
消息同步ISR
isr列表监控follower的同步状态，isr列表由leader动态维护。
将同步状态满足条件的follower记录在列表中，将不满足条件的follower移出列表。
leader下线后，从isr列表中的follower中选举新的leader
条件参数
-
follower的fech拉取请求间隔时间（10s）
replica.lag.time.max.ms=10000
-
leader与follower相差记录数（4000）
replica.lag.max.messages=4000
API
生产者
消费者
数据丢失和重复读取
生产者消息丢失
原因1：kafka数据先存储在内存中，一段时间后溢写到硬盘中。那么节点宕机，在内存中的消息未持久化，随着内存一起丢失。
原因2：分区主从备份，leader分区宕机，从分区未及时拉取同步，导致数据丢失
处理方式：修改持久化触发参数（数据量，时间）
处理方式：修改。。。。
消息丢失（消费者）
原因：在High level模式下，客户端向zk提交了偏移量，但数据读取时消费节点挂了，导致偏移量之前的数据没处理完毕。消费节点再次上线，从zk获取偏移量并向后读取，之前的数据不再处理，最终导致消费数据的丢失。
解决：客户端每条消息处理完，再手动提交偏移量，关闭偏移量自动提交。
重复消费（消费者）
原因：数据处理完以后，偏移量自动提交，设置间隔时间较长。节点宕机后，获取的偏移量是前一次的，节点会重复执行已执行的消息。
解决：手动提交数偏移量
高吞吐
高吞量
-
pagecache（页缓存），基于系统内存的数据接收
-
磁盘顺序写，相对随机存效率百倍以上，尤其对于磁盘存储。
高吐量
-
零拷贝计数
pagecache -- 网卡bufffer（数据）+socket（描述符）-- 客户端
高吞吐
-
producer消息存入速度与consumer读取数据速度维持均衡，保证在数据flush到磁盘前读取数据，实现只在pagecache内存层面的队列高速吞吐。