Kafka学习总结

Kafka的来源

LinkedIn 2003年在美国创立，号称全球最大的社交网站。而他使用的消息队列初期是ActiveMQ，但是经常会出现消息阻塞和服务不可用的情况，所以就自己开发了一个消息引擎，就是Kafka。
kafka不仅仅是消息中间件，而且还是消息引擎、分布式实时流处理平台。

使用场景

消息传递就是发送数据，作为TCP HTTP或者RPC的替代方案，可以实现异步、解耦、削峰。kafka的吞吐量更高，在大规模消息系统有更有优势。
网站活动跟踪，用户行为分析等系统中的使用。
日志聚合，配合Elastic Stack一起使用。
metrics应用指标监控
数据集成和流计算。

Kafka和zookeeper的关系

Kafka必须依赖于zookeeper。
利用了zookeeper的有序节点、临时节点和监听机制：
配置中心（管理Broker、Topic、Partition、Consumer的信息，包括元数据的变动）、负载均衡、命名服务、分布式通知、集群管理、选举、分布式锁。

Kafka Data Flow

下面这张图大概描述了kafka的架构。

最上边2个producer发送消息到Broker上，红色的是leader节点，leader节点收到消息之后，把消息同步到replica节点，consumer group消费leader节点的消息。

Broker

kafka作为一个消息中间件，是帮我们存储和转发消息的，它做的事情有点像中介，所以我们把Kafka的服务叫Broker。生产者和消费者都需要跟这个Broker建立连接，才可以实现消息的收发。

消息

客户端之间传输的数据叫消息（Record）。在客户端的代码中，Record是一个KV的键值对。
生产者对应的封装类是ProducerRecord，消费者对应的封装类是ConsumerRecord。
消息在传输的过程中需要序列化，所以我们在配置的时候一般都会配置key和value的序列化工具类。

消费者

一般来说消费者获取消息有两种模式，pull和push。
而Kafka只支持pull模式。不支持的原因是在push模式下，如果消息的产生速度远远大于消费的速度的话，消费者就会不堪重负，直到挂掉。

Topic

生产者跟消费者可以通过Topic来进行关联。生产者和消费者的关系都是多对多。一个生产者可以发送消息到多个Topic，一个消费者也可以从多个Topic获取消息。

Partition

一个Topic可以创建多个分区，分区的思想有点类似于分库分表，实现的也是横向扩展和负载的目的。Partition里边的消息被读取之后也不会删除，所以同一批消息在一个Partition里边顺序、追加写入。这也是Kafka吞吐量大的一个很重要的原因。

Replica

如果Partition的数据只存储一份，在发生网络或者硬件故障的时候，该分区的数据就无法访问到了，所以这就有了Replica机制。
每个Partition可以有若干个副本，副本必须在不同的Broker上。生产者发消息、消费者读消息都是针对于leader，follower的数据是从leader同步过来的。为什么不让客户端读取leader呢？是因为写入和读取消息都走leader的话，就无需解决leader和follower之间的数据一致性的问题了。

Segment

Kafka的数据是放在后缀.log的文件里边的，如果一个Partition只有一个log文件的话，消息不断的追加，这个log文件也会变的越来越大，这个时候的检索数据效率也就很低了。所以把Partition再做一个切分，切分出来的单位就交段（Segment）。Kafka的存储文件是按照Segment来存储的。每个Segment都有至少一个数据文件和2个索引文件。

Consumer Group

消费组：消费同一个topic并且group id相同的消费者就是一个消费组。
同一个Consumer Group中的消费者，不能消费相同的Partition，Partition要在消费者之间进行分配。
如果消费者比Partition少，一个消费者可以消费多个Partition。
如果消费者比Partition多，有消费者无法消费Partition的情况出现。不会出现同一个group里边的消费者消费同一个Partition的情况。

Consumer Offset

Partition中的消息是顺序写入的，且读取之后不会被删除。因为消息是有序的，我们对这个消息进行编号，用来标识唯一的一条消息，这就是Offset（偏移量）。