Kafka学习小结

什么是kafka

1. 类别：消息中间 （分布式的消息队列系统）
2. 特性：高性能、高可用 、消息有序
3. 关键对象：Broker、Topic、Partition、Producer、Consumer。
4. 用途：存储数据、流量削峰

总体架构图

我使用kafka的先决背景
需要给兄弟方提供数据，且数据量大，兄弟方用于做大数据分析。
同步到的数据发送到指定的topic，供兄弟方消费。

为什么不用其他的消息中间件

1. kafka性能有保证，且社区活跃。
2. 公司的分布式系统统一使用Kafka。

使用kafka可能会出现什么问题

1. 消息丢失
2. 重复消费

注：这是所有消息中间件共同可能出现的问题，消息中间件本身是没有问题的，在于使用者使用过程中。

为什么会出现消息丢失和重复消费，如何解决
消息丢失：发送与生产端
生产方式：同步和异步，可以通过producer.type配置，默认是同步，确认 消息的生产可以通过request.required.acks来配置，0（不确认）， 1（Leader确认即可），-1（Leader和Fllower都要确认）
消息丢失的情况：

1. 异步生产（acks=0）：生产者只管向Kafka集群发送消息，当网络异常Topic中满了之后，会出现消息丢失的情况。
2. 同步生产（acks=1）：生产者向Topic发送消息，Leader返回收到确认的消息，还没来得及同步到Fllower的时候程序出现异常，造成数据丢失。

解决方案：
可以在配置文件设置不限制阻塞超时时间，当缓冲区满了后，当缓冲区满时让生产者一直处于阻塞状态。
使用同步生产（Leader和Fllower都要确认收到消息）。

重复消费：发生在消费端
Kafka消息消费有两个consumer接口，Low-level API和High-level API：

1. Low-level API：消费者自己维护offset的值，可以实现对Kafka的完全控制。

2. High-level API：封装了partition和offset，使用简单。

   Topic中有至少一个partition，partition中的每一条消息都有一个偏移量（offset），消费端消费数据，如果使用Hign-level API，每隔一段时间会自动提交一次offset，告诉topic我已经消费到哪里来了，下次我要从offset+1的地方消费。天有不测风云，客户端还没来得及提交offset，当系统出现异常，或者客户端进程被人为的kill掉，客户端恢复正常以后，有一部分数据其实已经消费过了，但是客户端没有提交offset，那么服务端认为你没有消费，此时这部分数据又会被消费一次，于是造成了数据重复消费的情况，产生脏数据。

解决方案：
数据库主键或者联合主键：如果有重复数的话，会导致数据更新失败。
数据唯一编号：消费端和生产端协商好，消费端每次消费的时候去redis查一下编号，如果有，则表示已经消费过了，不入库，如果没有则正常消费。

疑惑：Kafka如何保证高性能和高可用
Kafka的Leader选举机制：
Kafka可以将Topic进行多个分区Partition，来并行的处理消息，提高性能，同时为了保证高可用，每个分区都会有一定数量的副本Replica，这样当部分服务器不可用时，副本所在的服务器就可以顶上来，保证系统可用性。
Leader负责读写，Fllower负责数据同步。当一个Leader发生故障后怎么从Fllower中选择新的Leader呢？

Kafka在zookeeper上针对每个Topic都维护了一个ISR（IN-sync-replica 已同步的副本）的集合，集合的增减Kafka都会更新该记录，如果某分区的Leader不可用，Kafka就从ISR中选择一个副本作为一个新的Leader，这样就可以容忍的失败数比较高，假如某Topic有N+1个副本，那么可以容忍N个服务器不可用。