【知识体系】Kafka文档汇总、组成及架构，配置，常见名词解释，命令行及api操作，官方文档内容，各部分深入，zookeeper和security，监控和运维

〇、相关资料

1、快速搭建文档：

2、详细讲义

3、在线官方文档：http://kafka.apache.org/documentation/

4、Kafka知识个人总结

5、KafkaPPT汇报

链接：https://pan.baidu.com/s/16VufOVYu8H1I13sENnvN1A
提取码：USTC （1，2，4，5）

一、基本介绍

1、概念

• 分布式的、基于发布/订阅模式的数据流式传输平台

• 消息队列的5种工作模式：https://www.cnblogs.com/misscai/p/9989276.html

• 特点：流式数据、集群方式运行、容错方式存储、消息及时处理、通过保留期限参数持久化保存发布的记录、副本机制
• 消息记录的组成：键、值、时间戳

2、架构

3、项目目录

4、配置文件详解

server.properties   https://www.cnblogs.com/alan319/p/8651434.html

生产者与消费者 https://blog.csdn.net/universsky2015/article/details/115234772

二、概念/参数/特性详解

1、常见名词解释

• 基本组成
  • Broker
  • Topic
  • Partition：一个partition只能被一个consumer消费
    • Leader
    • Follower
  • Producer
  • Consumer
    • Offset
    • log
  • Consumer Group：对同一个topic的多个consumer，GC内的多个consumer会进行负载均衡【消息可能会发送到一个组（单播）或多个组（广播）】
• Quotas：配额，控制客户端使用的代理资源，避免流量超过阈值从而降低用户体验，会根据user和client进行设置
  • 使用kafka-configs.sh命令行进行设置
• 认证方式
  • PLAINTEXT：明文/纯文本，在broker客户端配置kafka_server_jaas.conf认证信息，是无安全认证的监听方式
  • SSL：Secure Sockets Layer，安全套接字协议（密文）
  • SASL：Simple Authentication and Security Layer，简单认证和安全层，SASL_PLAINTEXT/SASL_SSL是有安全认证的监听方式，SASL可以使用PLAIN和SCRAM机制
    • PLAIN：明文，只需要在JAAS中配置server和client的认证信息
      • JAAS：Java Authentication and Authorization Service，Java认证和授权服务，需要在客户端中配置kafka_client_jaas.conf文件，配置明文认证信息KafkaClient
    • SCRAM：Salted Challenge Response Authentication Mechanism，盐化的质询响应认证机制，可以不用重启就能新增用户，与PLAIN是两种常用的权限认证方式
      • 只能使用安全传输层协议TLS，Transport Layer Security，配置JAAS文件的同时使用命令行设置认证方式
      • 通过 SCRAM-SHA-256【Strong Hash，强密码和强迭代技术】和SCRAM-SHA-512两种安全认证方式配合TLS完成安全权限认证
• ACL：用户权限控制/访问控制列表，一种权限认证方式
  • 需要配置allow.everyone.if.no.acl.found=true【如果无ACL权限控制，就允许任意用户进行访问】
  • 通过kafka-acls.sh对用户/主机/principal主体设置读写等权限
• Multi-tenancy：多租户模式，可以实现用户空间、集群共享，权限认证
• 关系：SASL(_PLAINTEXT)安全认证，需要先配置broker和client的JAAS文件，可以使用PLAIN（只需要配置jaas即可）/SCRAM（包含两种安全认证/加密方式，配置jaas+命令行添加配置）进行加密【jaas+命令行】

三、使用

1、命令行操作（见文档）

• 安装与配置
• 启动停止
• topic的CRUD
• 消息的生产消费

2、Kafka Client API操作

3、Producer API

• 异步发送包括两个线程：main线程和sender线程

• • main将消息发送到RecordAccumulator，sender从RecordAccumulator拉取到broker
  • 包含带回调函数的api和不带回调函数的api
  • producer收到ack时调用，ProducerRecord构造中多一个参数--Callback的匿名内部类的onCompletion方法
• 同步发送API
  • 发送消息后阻塞进程，直至返回ack
  • 方式：producer.send()后加.get()

4、Consumer API

• Kafka数据持久化，不会丢失
• 消费者需要考虑对offset的维护
  • 自动提交offset：参数--enable、interval.ms时间间隔
    • 缺陷：基于时间，无法把握时机
  • 手动提交offset
    • 分为commitSync（同步提交）和commitAsync（异步提交）
    • 同步提交阻塞进程直至成功，自动失败重试，可靠，但吞吐量受影响
    • 异步提交无失败重试。
    • 两种方式均可能导致数据漏消费（先提交后消费）或重复消费（先消费后提交）

5、自定义Interceptor拦截器

• 对client的定制化逻辑控制
  • 在消息发送前或producer回调逻辑前对消息做定制化需求
  • 可以指定多个Interceptor形成拦截器链
• 实现接口是ProducerInterceptor，包括configure、onSend（可以对消息进行操作）、onAcknowledgement（成功或失败时调用）、close方法
• 配置对象prop.put(interceptorsList)

6、官方文档内容

• 快速入门
• 常用API（需要导入的maven包）
• 配置（不同属性描述）
• 设计（ISR、log、Partition的副本Replica机制、配额Quota）
• 实施（消息记录格式头、集群结构）
• 常见操作（多租户）
• 安全（SSL/SASL/授权/ACL）
• Kafka连接（Java连接函数）
• Kafka流

五、深入介绍

1、工作流程

• topic即目录，partition是物理概念，与log一一对应
• log存储生产的数据，数据会追加到log/partition末尾，通过offset记录索引
• consumer会实时记录offset，便于出错时恢复并继续消费

2、文件存储【分片和索引机制】

• 防止log过大，将其拆分为多个segment
• 每个segment包括.log和.index文件，均以当前segment第一条消息的偏移量命名
• 方便old segment的删除，提高磁盘利用率，生命周期由服务器端参数配置

• .log存消息内容，.index存放索引（二分查找到指定消息）及物理偏移量/元数据的内存地址（快速定位消息）

3、生产者

• 数据会被封装为ProducerRecord对象
• 保证可靠性：partition向生产者发送ack
• 分区（得到生产者向第几个partition发送消息，是ProducerRecord构造的参数）：便于扩展，提高并发
• 分区策略：指明、key的hash与partition数取余、round-robin算法（随机数与partition数取余）等

副本同步策略：leader维护ISR，副本未同步(根据副本数量，发送ack)会被踢出

• 出故障后会从ISR中选取leader
• acks应答机制，参数（0，1，-1）：对leader和followers约束是否落盘，提高可靠性

故障处理：通过对follower使用LEO和HW方法，选举产生leader，解决生产者和消费者故障

• LEO：每个副本的最后一个offset
• HW：所有ISR副本中最小的LEO
• 重要消息的幂等机制：exactly once语义保证消息只被发送一次

4、消费者

• 消费方式：pull模式，根据消费能力从broker获取消息，并通过timeout参数避免长时间获取空参数
• 分区分配策略：确定partition由哪个CG消费
  • RoundRobin（基于topic级别轮询消费）
  • Range（基于整体partition均分消费）
• 分区再平衡：reblance
  • CG新增消费者，消费者离开CG，topic新增partition
• 用于offset维护的topic，避免consumer宕机：zookeeper维护             →           内部topic：__consumer_offsets
• GC：同一GC内的多个消费者，在同一时刻只能有一个消费者在读取数据

5、高效读写的实现

• 写：往硬盘中追加写而不随机写（先写到cache，再同步写入硬盘）
• 读：Linux和Unix的零拷贝机制（直接将数据发送到网卡，而无需拷贝到Kafka服务中）
  • 往磁盘中循环读写，保证数据不会丢失

6、zookeeper的作用

• 对broker和Consumer的元数据进行管理
• 选举并管理Controller
  • Controller负责：管理集群中的其他broker上下线，以及分区副本分配和leader选举等

7、监控运维

• Kafka Manager：IP ADDR:30990
• Kafka Monitor
• ZK Web UI：IP ADDR:8098

8、其他问题

• config中的Bootstrap-server：源码内部使用的实际上就是broker-list，但并未使用Kafka的服务，而是使用了外部服务Bootstrap-server　　

六、Security

1、安全认证方式