是什么
kafka是一个消息中间件，一个分布式流*台，作为一个集群运行在一个或多个服务器上
- 可发布订阅消息（流）
- 以容错（故障转移）方式存储消息（流）
- 在消息（流）发生时处理它们
核心API
- Producer API ：用来发布消息到1个或多个topic（主题）中
- Consumer API ：用来订阅一个或多个topic，并处理产生的消息
- Streams API ：充当一个流处理器，从1个或多个topic消费输入流，并生产一个输出流到1个或多个输出topic，完成转换工作
- Connector API ：将topic连接到应用程序或数据系统
- Admin API ：用于管理和检查topic，broker
基本概念
record： kafka的数据单元，也叫消息，每个消息（也叫record）由一个key，一个value和时间戳构成
topic： kafka将消息分类，每一类消息称为一个主题（Topic），这是一个逻辑概念
producer： 发布消息的对象称之为主题生产者（Kafka topic producer）
consumer：订阅消息并处理发布的消息的对象称之为主题消费者（consumers）
broker： 已发布的消息保存在一组服务器中，称之为Kafka集群。集群中的每一个服务器都是一个代理（Broker）
消费者可以订阅一个或多个主题（topic），并从Broker拉数据，从而消费这些已发布的消息
partition： 一个分区就是一个提交日志，是一个物理的概念，存在于具体的broker上(每个broker上可以有很多分区)，
每个分区对应一个文件夹，可以看作是一个顺序的消息队列，新消息被顺序添加到分区中。
生产者可以只关心topic，不用关心消息被发送到哪个broker上的哪个partition，
消费者可以并行的从不同的broker上的不同分区消费消息，因此分区可以实现水*扩展，且突破单个broker的瓶颈限制
segment：partition内部存储日志文件的基本单位，叫日志段，主要由消息日志文件（.log）,位移索引文件（.index），时间戳
索引文件（.timeindex）组成
offset： partition中的消息都会被分配一个序列号，称为offset，消费者可控制的提交，consumer消费消息时，offset线性增加
在新版本中（0.9以后的，我们用的0.10+），这个值存在__consumer_offsets这个topic中，并不在zk中管理，存的是consumer
提交的位移
batch： 批次，就是一组消息，批次的大小要在时间延迟和吞吐量之间做权衡
rebalance：当分区数量或消费组中消费者数量发生变化时，kafka会进行rebalance操作
consumer group 消费者组
重要的概念，单独讲。消息模型一般可以分为以下两种
- queue模型：一组消费者读取消息，一条消息只有其中的一个消费者来处理
- publish-subscribe模型：消息被广播给所有的消费者，接收到消息的消费者都可以处理此消息
Kafka为两种模型提供了单一的消费者抽象模型： consumer group，消费者用一个groupId标记自己，消息被分发给此group中的一个消费者
- 假如所有的消费者都在一个组中，就变成了queue模型。
- 假如所有的消费者都在不同的组中，就完全变成了发布-订阅模型
- 可以创建一些消费者组作为逻辑上的订阅者。每个组包含数目不等的消费者，一个组内多个消费者可以用来扩展性能和容错
分区和顺序问题
发送到broker上的单个分区的消息可以保证顺序
但是并行消费不能保证消费到的消息的先后顺序
分区中消息只能由消费者组中的唯一一个消费者处理，基于这点，按照业务需要考虑以下两种方案：
单分区保证顺序+单consumer消费，这种没办法，顺序化基本没问题了
单分区保证顺序+多consumer消费，这里要保证consumer处理消息的能力（速度）基本是一样的
多分区+消息key路由保证一定顺序+多consumer消费
项目中遇到过具体业务，后续给出具体实践
几个注意点
kafka的每个topic中的消息消费时都有以下两种模式：
队列： 允许同名的消费者组成员瓜分处理消息
发布订阅：允许广播消息给多个消费者组
topic的parition设计为kafka提供了顺序保证和负载均衡
每个partition仅由同一个消费者组中的一个消费者按顺序消费到消息。并确保消费者是该partition的唯一消费者
每个topic有多个分区，则需要对多个消费者做负载均衡，但请注意，
相同的消费者组中不能有比分区数量更多的消费者，否则多出的消费者一直处于空等待，不会收到消息
流处理Stream API
kafka提供了读，写，存3个大功能，也支持实时流处理，如处理无序的数据，代码更改的再处理，执行状态计算等
Sterams API在Kafka中的位置：使用producer和consumer API作为输入，利用Kafka做状态存储，使用相同的组机制
在stream处理器实例之间进行容错保障
需要辨析理解的点
不同partition中的消息，消费时不保证顺序
一般情况下，消费组里的成员（消费者）消费时接**分消息
3个分区给组里的2个消费者，那么一个消费者会消费2个分区，一个只消费1个分区
获取消息一般很快，瓶颈一般在于消费下来的一批消息怎么做业务处理
关于__consumer_offsets
做项目的时候发生过单独处理offset的问题，比较好奇这个topic里消息到底是什么结构，找到一张图：
可以理解为每个offset值由groupId+topicName+partitionNum来唯一确定，对于有rebalance情况的消费者变化，
只关心这个topic下，某个分区内最新提交的offset值，至于consumer有没有变更，其实不用关心，不管哪个消费
者接管，都是识别该分区里最新的这个offset