kafka 基本知识
一、基本术语
- 消息：Record，是 Kafka 处理的主要对象
- 消息位移：Offset，对应分区中每条消息的位置信息，是一个单调递增且不变的值
- 主题：Topic，是承载消息的逻辑容器；实际使用中多用来区分具体的业务，不同topic即为不同业务
- 生产者：Producer，发布消息
- 消费者：Consumer，订阅主题消息；多个消费者实例共同组成Consumer Group消费者组，消费者组里面的所有消费者实例不仅“瓜分”订阅主题的数据，还能彼此协助。假设组内某个实例挂掉了，Kafka 能够自动检测到，然后把这个 Failed 实例之前负责的分区转移给其他活着的消费者
- 消费者位移：Consumer Offset，用于表示消费者的消费进度，每个消费者都有自己的消费者位移
二、从结构上理解kafka的高可用手段
-
消费者和生产者都是kafka的客户端，Kafka 的服务器端是由被称为 Broker 的服务进程构成，即一个 Kafka 集群由多个 Broker 组成。
-
Broker 负责接收和处理客户端发送过来的请求，以及对消息进行持久化。虽然多个 Broker 进程能够运行在同一台机器上，但更常见的做法是将不同的 Broker 分散运行在不同的机器上，这样如果集群中某一台机器宕机，即使在它上面运行的所有 Broker 进程都挂掉了，其他机器上的 Broker 也依然能够对外提供服务。这就是 Kafka 提供高可用的手段之一
-
备份机制（Replication），就是把相同的数据拷贝到多台broker机器上，而这些相同的数据拷贝在 Kafka 中被称为副本（Replica）副本被分类为领导者副本（Leader Replica）和追随者副本（Follower Replica）
- 前者对外提供服务，生产者总是向领导者副本写消息；而消费者总是从领导者副本读消息；
- 后者只是被动地追随领导者副本而已，不能与外界进行交互，它只做一件事：向领导者副本发送请求，请求领导者把最新生产的消息发给它，这样它能保持与领导者的同步
-
领导者副本是唯一对外的副本，那么可能就存在单台broker都无法容纳，kafka有分区的概念，即每个主题划分为多个分区，每个分区是一组有序的消息日志；副本是分区的层级下定义的，每个分区可以配置若干个副本分区，也就是说实际上从broker层级上看，生产者向分区写入消息，消费者从分区读取消息
- 其中kafka源码中会对副本数进行参数检查要满足大于0且小于等于broker数量，以保证副本平均分布在不同的broker上；每个不同的领导者副本尽可能分布在不同的broker去实现各个broker负载均衡
可以通过下图对kafka整体有更形象的认知：
注：图片来源于网络
三、分区策略
分区策略其实就是决定生产者将消息发送到哪个分区的算法
java api中如果指定了partition就直接发送到该分区；如果没有指定分区但是指定了key，就按照key的hash值选择分区；如果partition和key都没有指定就使用轮询策略
- 轮询策略
默认策略，即将数据按顺序分配地发送到每个分区，比如一个主题下有 3 个分区，那么第一条消息被发送到分区 0，第二条被发送到分区 1，第三条被发送到分区 2，以此类推 - 随机策略
将消息放置到任意一个分区上，类似于random.nextInt()去获得一个小于总分区数的值，该值即为要发送的分区 - 自定义策略
通过编写一个具体实现类且配置生产者端参数partitioner.class即可，主要需要实现partition方法
四、消息确认机制
生产者发送消息的确认机制，通过配置生产者acks实现
- acks = 0：生产者根本不会等待服务器的任何确认。消息将立即添加到套接字缓冲区并视为已发送。这种情况下不能保证服务器已经收到消息，为每条记录返回的偏移量将始终设置为-1
- acks = 1：领导者副本会将消息写入其本地日志，并在不等待所有追随者完全确认同步到消息的情况下做出响应。如果领导者在确认消息后但在追随者复制它之前立即失败，消息将丢失
- acks = all / acks = -1 ：领导者将等待
副本同步队列的所有副本确认收到消息。这保证只要至少一个同步副本保持活动状态，消息就不会丢失 - 默认设置为
all
副本同步队列ISR(In-Sync Replicas)：每个分区的leader负责维护和跟踪ISR中所有follower滞后的状态。当producer发送一条消息到broker后，leader写入消息并复制到ISR中所有follower。消息复制延迟受最慢的follower限制，重要的是快速检测慢副本，如果follower“落后”太多或者失效，leader将会把它从ISR中删除。所有的副本统称为Assigned Replicas，ISR是它的一个子集，follower从leader同步数据有一些延迟时间，任意一个超过阈值replica.lag.time.max.ms都会把follower剔除出ISR
小思考：
kafka的副本机制为什么不像MySQL那样允许追随者副本也对外提供读服务
1、MySQL从库提供读服务，实现了读负载，减轻主库的读压力；而kafka的broker以及分区分配规则已经实现了多台broker的负载均衡
2、kafka保存的数据和数据库数据实质的区别就是kafka数据具有消费的概念，消费需要位移，而数据库是实体数据不存在这个概念，如果从kafka的follower读，消费者offset控制将会更复杂
3、如果从follower读，就要确保领导者收到生产者的消息之后，follower也必须同步数据才不会造成副本间数据的不一致性，按照kafka设置的消息确认机制，那就必须需要等所有的追随者副本数据同步之后才是真正的消息确认，可能比acks = all的情况还需要更长的时间