一、Kafka简介

Kafka基于Scala编写，其中也包含有大量的Java代码。2021年6月份之前强依赖与Zookeeper，6月份最新版有了变动(目前还不能使用)。 Zookeeper（连续写性能较慢）
分布式流处理平台

1.1 Topic

消息主题（队列）。
生产者可以将消息发送到多个主题，消费者也可以从多个主题消息消息。

1.2 Partion

数据分区。与分库分表的概念类似。
试想，在高并发环境下，Topic中的数据会迅速增多，如果消息的存储、访问都由一台服务来做，那么性能可想而知，必然会迅速下降，此时更好的方式就是做集群、分布式解决。因此kafka引入了Partion的概念，会将一个Topic划分为多个分区，分区是在创建Topic时指定，至少有一个分区。
假如一个集群有三台 Broker（服务），Topic partion数量为9，那么三台服务将分摊，每台服务有3partion。
kafka在消费数据后是不对消息做删除处理的。因此在写入数据时，都是顺序追加写入，在磁盘IO操作会更快。

（IO操作之所以慢就是因为要对磁盘进行寻址。举个栗子：现在有100个苹果编号为 1-100，需要放在10个篮子里1-10，11-20，这种情况下，你要放苹果就需要看编号，找到编号对应的篮子，放进去。那如果你可以不看编号，按照顺序一个一个往后放，速度会不会快很多，因此在计算机领域数据的有序无序对于程序性能的影响也是很大的，比如MYSQL 使用顺序自增主键性能要远大于无序的UUID）

1.3 Replica

副本。如果Partion数据只存储一份，那么在服务异常的时候，分区的数据就无法访问了，严重影响了可用性。所以引入Repllica概念对数据进行备份，类似于数据库主从。
副本必须在不同的broker上边，否则没有意义。另外，副本只是副本，生产者和消费者只会跟Leader(主体)打交道，Leader挂了之后副本才有出头之日,没挂之前副本制作数据备份。

1.4 Group

准确来说应该叫Consumer Group。表示消费组。
上边我们已经知道在一个Kafka集群中，同一个Topic通常会分为多个Partion。如果此时Topic只有一个消费者，那么该消费者只需要消费所有的partion就OK了。但是通常消费速率都会小于生产速率，为了不造成消费不及时，肯定要增加消费者，这种情况下，如何来分配呢？是否会重复，是否会遗漏？如果多个消费者需要处理不同的业务，两个消费者就是都要消费到2个Partion的消息又该如何判断呢？

这时引入了消费组的概念，一个消费组可以有多个消费者，对于Topic来说，消息只会被一个消费组消费一次。消费组中的消费者，通常是需要绑定Topic中的Partion的。比如Topic有4个Partion，消费组也有4个消费者，这时可以1个消费者绑定一个Partion。如果有2个消费者，那么1个消费者绑定2个partion。如果有6个消费者，那么让两个消费者摸鱼就OK。

1.5 offset

由于Kafka不删除消息，因此需要记录消费者消费到的消息位置。避免重复消费。所以引入offset概念。limit offset。也是针对消费者。offset的记录是保存在服务端的。

此处思考一下：什么情况下会重置Offset的值导致消费组从头开始消费。如何设置消费组Offset的值。

1.6 生产者

发送消息并非逐条发送，而是批量的发送。主要通过batch.size决定，默认是16K（条数），此外还有其他的比如时间、数据大小参数来控制发送频率。减少了建立连接的过程，增加了单次发送的数据内容，提高了发送数据性能，但是也产生了一定的延迟，以及可用性（生产者服务宕机，可能丢失数据），对于消息可靠性保证增加了实现难度。

1.7 消费者

消费者采用Pull模式消费数据，Rabbit MQ是push。
对于Pull模式来说，消费者主动从服务拉取要消费的数据，消费的时机，频次都有消费者决定，可控性更好。同时相对于push模式，kafka服务Broker无需感知消费端的情况，比如控制发送给哪个消费者逻辑，推送负载均衡算法等功能也无需考虑。这样减轻了服务端的重量。消费端来负责做这个事情，平摊了重量，增加了吞吐性能。同时也避免了在push模式下，生产者生产消息速率远大于消费者情况下带来的消费者不堪重负问题。