Kafka笔记

应用领域

主要应用在大数据领域，数据集成，流计算集成。
主要使用场景：MQ，监控，分布式日志聚合，数据集成+流计算

---

安装

需要JDK环境依赖
ZooKeeper依赖
没有自带的界面管理工具，目前有kafka-manager和kafka-eagle

---

架构分析

关键字

Broker：kafka节点服务
Topic：可以理解为队列名（生产者发送消息时，如果topic不存在，会自动创建，也可以取消该设置）
partition：分区（分片的思想来拆分topic，实现横向扩展和负载）

1. 每个partition都有一个物理目录，在配置的数据目录下
2. 和RabbitMQ不同，partition中的消息被读取之后不会被删除
3. 同一批消息在一个partition里面顺序、追加写入（这也是Kafka吞吐量大的一个重要原因）
4. 每个partition可以有若干个副本，副本必须在不同的broker上面
5. 多个相同的partition副本有leader和follower，leader在哪台机器不一定
6. 生产者发消息，消费者读消息都是针对leader（避免了读写一致性问题）

消息：传输过程需要序列化
生产者：不是逐条发送消息给Broker，而是批量发送
消费者：只支持pull模式消费
消费者组：通过group id来配置

1. 消费同一个topic的消费者不一定是一个组，只有group id相同的消费者才是一个组
2. 同一个group中的消费者，不能消费相同的partition，partition要在消费者之间分配
3. 消费者比partition少：一个消费者可以消费多个partition
4. 消费者比partition多：肯定有消费者没有partition可以消费
5. 如果想要同时消费同一个partition的消息，需要其他组来消费。

Segment：partition再切分，切分出来的单位就叫段（segment），实际上Kafka的存储文件是划分成段来存储的。
Consumer Offset：因为消息是有序的，所以可以对消息进行编号，用来标识一条唯一的消息。这个编号叫offset，偏移量。offset记录着下一条将要发送给consumer的消息的序号。

---

解读架构图

1. 有3台节点（broker）
2. 有两个topic：topic0 和 topic1
3. topic0有两个分区：partition0 和 partition1， 每个partition有3个副本， partition0的leader在节点broker0上， partition1的learder在节点broker1上
4. topic1有1个分区：partition0，partition0有三个副本，leader在节点broker2上
5. 其中红色的partition代表副本的leader
6. 有两个消费者组， group0 和 group 1
7. group0 只消费 topic0，有1个consumer， 这是consumer比partition多的情况：1个consumer消费2个partition
8. group1 消费 topic0和topic1， 有3个consumer，这是consumer比partition少的情况：consumer0和consumer1分别消费topic0的partition0和partition1， consumer0消费topic1的partition0

---

消息幂等性

为什么要做幂等性校验？
如果消息失败了，消息要重发。但是在不清楚消费者是不是真的消费失败的情况下，有可能会出现消息重复的情况。
Kafka在broker实现了消息的重复性判断，大大解放了消费者的双手。
生产者做如下配置：

properties.put("enable.idempotence", true);

enable.idempotence 设置成true后，Producer自动升级成幂等性producer，Kafka会自动去重。

1. PID(producer ID)，幂等性的生产者每个客户端都有一个唯一的编号；
2. sequence number，幂等性的生产者发送的每条消息都会带相应的 sequence number（连续的），server端就是根据这个值来判断数据是否重复。如果说发现 sequence number 比服务端已经记录的值要小，那肯定是出现消息重复了。
3. sequence number 并不是全局有序的，不能保证所有时间上的幂等。所以它的作用范围有限。
   – 只能保证单分区上的幂等性；
   – 只能实现单会话上的幂等性（当重启了producer进程之后，幂等性不保证）

也就是说不允许生产者在一次会话中向同一个partition发送相同的消息。
如果要实现多个分区的消息的原子性，就要用到Kafka的事务机制了。

---

生产者事务

为什么要引入事务？什么时候才需要开启事务？

• 假设只有1个broker，1个topic的分区只有1个副本，如果我们要发送多条消息，想要让这些消息全部成功或者全部失败。
• 更加复杂的情况，如果生产者发送消息到多个topic或者多个partition，它们有可能分布在不同的服务器上，我们需要它们全部发送成功或者全部发送失败。
• 消费者和生产者在同一块代码中（consumer-process-produce），从上游接收消息，经过处理后发送给下游，要保证接收消息和发送消息同时成功。
  

---

Kafka的分布式事务实现的几个关键点

• 分布式事务的实现方式有很多，Kafka选择了最常见的两阶段提交(2PC)。如果大家都可以commit，那就commit，否则abort。
• 既然是2PC，必须要有一个协调者的角色，叫做 transaction coordinator。
• 事务管理必须要有事务日志，来记录事务的状态，以便 coordinator 在意外挂掉之后继续处理原来的事务。跟消费者 offset 的存储一样，Kafka使用一个特殊的topic_transaction_state 来记录事务状态。
• 如果生产者挂了，事务要在重启后可以继续处理，接着之前未处理完的事务，或者在其他机器上处理，必须要有一个唯一的ID，这个就是 transaction.id 。配置了 transaction.id，则此时 enable.idempotence 会被设置为 true（事务实现的前提是幂等性）。事务ID相同的生产者，可以接着处理原来的事务。
  

Kafka和RabbitMQ对比

Kafka主要特性

• 高吞吐，低延迟：kakfa 最大的特点就是收发消息非常快，kafka 每秒可以处理
几十万条消息，它的最低延迟只有几毫秒;
• 高伸缩性∶如果可以通过增加分区 partition来实现扩容。不同的分区可以在不同的 Broker中。通过ZK来管理 Broker实现扩展，ZK管理Consumer可以实现负载;
• 持久性、可靠性∶Kafka能够允许数据的持久化存储，消息被持久化到磁盘，并支持数据备份防止数据丢失;
• 容错性∶允许集群中的节点失败，某个节点宕机，Kafka集群能够正常工作;
• 高并发∶支持数千个客户端同时读写。

---

Kafka和RabbitMQ的主要区别

• 产品侧重∶ kafka∶ 流式消息处理、消息引擎;RabbitMQ∶ 消息代理性能∶
• kafka 有更高的吞吐量。RabbitMQ主要是 push，kafka只有pull。
• 消息顺序∶ 分区里面的消息是有序的，同一个consumer group里面的一个消费者只能消费一个 partition，能保证消息的顺序性。
• 消息的路由和分发∶ RabbitMQ 更加灵活。
• 延迟消息、死信队列∶ RabbitMQ 支持。
• 消息的留存∶kafka消费完之后消息会留存，RabbitMQ消费完就会删除。Kafka 可以设置 retention，清理消息。