核心概念

  • 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内存层面的队列高速吞吐。