消息队列的好处
- 解耦:传统模式的缺点：系统间耦合性太强，假设系统A在代码中直接调用系统B和系统C的代码,如果将来D系统接入,系统A还需要修改代码,过于麻烦。中间件模式的的优点：将消息写入消息队列,需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。
- 削峰/限流:传统模式的缺点：并发量大的时候，所有的请求直接怼到数据库,造成数据库连接异常。中间件模式的的优点:系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。
- 异步:传统模式的缺点：一些非必要的业务逻辑以同步的方式运行， 太耗费时间。中间件模式的的优点：将消息写入消息队列，非必要的业务逻辑以异步的方式运行， 加快响应速度。
kafka架构图
topic、partition、segment三者关系
segment示例
一个partition由多个segment组成，而segment对应两个文件，分别是.index文件和.log文件；这些文件位于一个文件夹下， 该文件夹的命名规则为： topic 名称+分区序号。例如， first 这个 topic 有三个分区，则其对应的文件夹为 first- 0,first-1,first-2。
Kafka Producer
分区
分区原因
- 方便在集群中扩展
- 可以提高并发
分区原则
数据可靠性
ack
- 0：producer不等待broker的ack，一接收到还没写入磁盘就返回，造成数据丢失
- 1：producer等待broker的ack, leader落盘成功后返回ack；存在leader向follower同步时leader发生故障的情况，造成数据丢失
- -1：producer等待broker的ack，partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复
HW和LEO
Exactly Once 语义
将服务器的 ACK 级别设置为-1，可以保证 Producer 到 Server 之间不会丢失数据，即 At Least Once 语义。相对的，将服务器 ACK 级别设置为 0，可以保证生产者每条消息只会被 发送一次，即 At Most Once 语义。
At Least Once 可以保证数据不丢失，但是不能保证数据不重复；相对的， At Least Once 可以保证数据不重复，但是不能保证数据不丢失。 但是，对于一些非常重要的信息，比如说 交易数据，下游数据消费者要求数据既不重复也不丢失，即 Exactly Once 语义。 在 0.11 版 本以前的 Kafka，对此是无能为力的，只能保证数据不丢失，再在下游消费者对数据做全局 去重。对于多个下游应用的情况，每个都需要单独做全局去重，这就对性能造成了很大影响。 0.11 版本的 Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指 Producer 不论 向 Server 发送多少次重复数据， Server 端都只会持久化一条。幂等性结合 At Least Once 语 义，就构成了 Kafka 的 Exactly Once 语义。即：
At Least Once + 幂等性 = Exactly Once
要启用幂等性，只需要将 Producer 的参数中 enable.idompotence 设置为 true 即可。 Kafka 的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。开启幂等性的 Producer 在 初始化的时候会被分配一个 PID，发往同一 Partition 的消息会附带 Sequence Number。而 Broker 端会对<PID, Partition, SeqNumber>做缓存，当具有相同主键的消息提交时， Broker 只 会持久化一条。但是 PID 重启就会变化，同时不同的 Partition 也具有不同主键，所以幂等性无法保证跨 分区跨会话的 Exactly Once。
Kafka Consumer
Push or Pull??
分区分配策略
- RoundRobin
- Range
Kafka 的再均衡
在Kafka中，当有新消费者加入或者订阅的topic数发生变化时，会触发Rebalance(再均衡：在同一个消费者组当中，分区的所有权从一个消费者转移到另外一个消费者)机制，Rebalance顾名思义就是重新均衡消费者消费。Rebalance的过程如下：
- 第一步：所有成员都向coordinator发送请求，请求入组。一旦所有成员都发送了请求，coordinator会从中选择一个consumer担任leader的角色，并把组成员信息以及订阅信息发给leader。
- 第二步：leader开始分配消费方案，指明具体哪个consumer负责消费哪些topic的哪些partition。一旦完成分配，leader会将这个方案发给coordinator。coordinator接收到分配方案之后会把方案发给各个consumer，这样组内的所有成员就都知道自己应该消费哪些分区了。 所以对于Rebalance来说，Coordinator起着至关重要的作用
kafka事务
- 查找Transaction coordinator
Producer向任意一个brokers发送 FindCoordinatorRequest请求来获取Transaction Coordinator的地址。
- 初始化事务 initTransaction
Producer发送InitpidRequest给Transaction Coordinator，获取pid。Transaction Coordinator在Transaciton Log中记录这<TransactionId,pid>的映射关系。另外，它还会做两件事：
恢复（Commit或Abort）之前的Producer未完成的事务 对PID对应的epoch进行递增，这样可以保证同一个app的不同实例对应的PID是一样，而epoch是不同的。只要开启了幂等特性即必须执行InitpidRequest，而无须考虑该Producer是否开启了事务特性。
- 开始事务beginTransaction
执行Producer的beginTransacion()，它的作用是Producer在本地记录下这个transaction的状态为开始状态。这个操作并没有通知Transaction Coordinator，因为Transaction Coordinator只有在Producer发送第一条消息后才认为事务已经开启。
- read-process-write流程
一旦Producer开始发送消息，Transaction Coordinator会将该<Transaction, Topic, Partition>存于Transaction Log内，并将其状态置为BEGIN。另外，如果该<Topic, Partition>为该事务中第一个<Topic, Partition>，Transaction Coordinator还会启动对该事务的计时（每个事务都有自己的超时时间）。
在注册<Transaction, Topic, Partition>到Transaction Log后，生产者发送数据，虽然没有还没有执行commit或者abort，但是此时消息已经保存到Broker上了。即使后面执行abort，消息也不会删除，只是更改状态字段标识消息为abort状态。
- 事务提交或终结 commitTransaction/abortTransaction
在Producer执行commitTransaction/abortTransaction时，Transaction Coordinator会执行一个两阶段提交：
第一阶段，将Transaction Log内的该事务状态设置为PREPARE_COMMIT或PREPARE_ABORT
第二阶段，将Transaction Marker写入该事务涉及到的所有消息（即将消息标记为committed或aborted）。这一步骤 Transaction Coordinator 会发送给当前事务涉及到的每个<Topic, Partition>的Leader，Broker收到该请求后，会将对应的Transaction Marker控制信息写入日志。
一旦Transaction Marker写入完成，Transaction Coordinator会将最终的COMPLETE_COMMIT或COMPLETE_ABORT状态写入Transaction Log中以标明该事务结束。
kafka经典面试题
1、Kafka为什么吞吐量大、速度快？blog.csdn.net/kzadmxz/art…
- 顺序读写
- Page Cache，就是利用操作系统自身的内存而不是JVM空间内存。这样做的好处有：
- 1、避免Object消耗：如果是使用 Java 堆，Java对象的内存消耗比较大，通常是所存储数据的两倍甚至更多。
- 2、 避免GC问题：随着JVM中数据不断增多，垃圾回收将会变得复杂与缓慢，使用系统缓存就不会存在GC问题
- 零拷贝
- linux操作系统 “零拷贝” 机制使用了sendfile方法， 允许操作系统将数据从Page Cache 直接发送到网络，只需要最后一步的copy操作将数据复制到 NIC 缓冲区， 这样避免重新复制数据
- 分区分段+索引
- 批量读写
- 批量压缩
2、kafka为什么需要zookeeper？
- 管理所有的broker
- 记录消息消费进度Offset记录
- 生产者消费者负载均衡
- 记录消息分区于消费者的关系，都是通过创建修改zookeeper上相应的节点实现
