2021年4月19日，Kafka 2.8.0正式发布！这次升级包括了很多重要的改动，其中最引人瞩目的就是kafka通过自我管理的仲裁来替代ZooKeeper，通俗的说，Kafka将不再需要ZooKeeper，正式分手！
1. Kafka概述
Kafka是一个分布式、支持分区的（partition）、多副本的（replica），多订阅者的消息发布订阅系统，常见可以用于web/nginx日志、访问日志，消息服务等等。
2. Kafka的特性
- 高吞吐量、低延迟：Kafka每秒可以处理几十万条消息，他的延迟最低只有几毫秒，每个topic可以分多个partition、consumer group对partition进行consumer操作（同时支持离线数据处理和实时数据处理）
- 可扩展性：Kafka集群支持热扩展
- 持久性、可靠性：消息被持久化到本地磁盘，并支持数据备份防止数据丢失
- 容错性：允许集群中节点失败（若副本数量为n，则允许n-1个节点失败）
- 顺序保证：在大多数使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partiton内的消息的有序性（分区间数据是无序的，如果对数据的顺序有要求，应将在创建主题时将分区数partitions设置为1）
- 高并发：支持数千个客户端同时读写
3. Kafka的使用场景
- 日志收集：一个公司可以用Kafka收集各种服务的log，通过Kafka以同一的接口服务的方式开放给各种consumer，例如hadoop、Hbase等
- 消息系统：解耦和生产者和消费者、缓存消息等
- 用户活动跟踪：Kafka经常用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到Kafka的topic中，然后订阅者通过订阅这些topic来做实施的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘
- 运营指标：Kafka也经常用来记录运营监控数据，包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告
- 流式处理：比如spark streaming和storm
- 事件源
4.Kafka发布-订阅消息传递模式
在发布-订阅消息系统中，消息被持久化到一个topic中。与点对点消息系统（一条消息只能被消费一次）不同的是，消费者可以订阅一个或多个topic，消费者可以消费该topic中所有数据，同一条数据可以被多个消费者消费，数据被消费后不会被立马删除。在发布-订阅消息系统中，消息的生产者被称为发布者，消费者被称为订阅者。
发布者发送到topic的消息，只有订阅了topic的订阅者才会收到消息
5. 常用消息队列（Message Queue）对比
5.1 RabbitMQ
RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。
5.2 Redis
Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
5.3 ZeroMQ
ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演这个服务器角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果宕机，数据将会丢失。其中，Twitter的Storm 0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输（Storm从0.9版本开始同时支持ZeroMQ和Netty作为传输模块）。
5.4 ActiveMQ
ActiveMQ是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。
5.5 Kafka/Jafka
Kafka是Apache下的一个子项目，是一个高性能跨语言分布式发布/订阅消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制统一了在线和离线的消息处理。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。
6.Kafka API介绍
6.1 Producer API
Producer API允许各个app将数据流发送到Kafka集群的主题中，为了使用Producer API，我们需要在Maven工程中添加如下依赖
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-clients</artifactId>
<version>2.8.0</version>
</dependency>6.2 Consumer API
COnsumer API允许各个app通过Kafka集群中的主题读取数据流，为了使用Consumer API，我们需要在Maven工程中添加如下依赖
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-clients</artifactId>
<version>2.8.0</version>
</dependency>6.3 Streams API
Streams API允许数据写入topics中并从topics中读取，为了使用Streams API，需要在Maven工程中添加如下依赖
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-streams</artifactId>
<version>2.8.0</version>
</dependency>如果使用的是scala Maven工程，则还需要添加如下依赖
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-streams-scala_2.12</artifactId>
<version>2.8.0</version>
</dependency>6.4 Connect API
Connect API 允许继承该接口的connectors将数据从source data system存入Kafka中或者将Kafka中的数据存入sink data system
6.5 Admin API
Admin API 支持管理和索引topics,brokers,acks,和其他的Kafka对象，如果需要使用Admin API，需要向Maven工程中添加如下依赖
<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-clients</artifactId>
<version>2.8.0</version>
</dependency>7. Kafka中的术语解释
在深入理解Kafka之前，先介绍一下Kafka中的术语。下图展示了Kafka的相关术语以及之间的关系：
上图中一个topic配置了3个partition。Partition1有两个offset：0和1。Partition2有4个offset。Partition3有1个offset。副本的id和副本所在的机器的id恰好相同。
如果一个topic的副本数为3，那么Kafka将在集群中为每个partition创建3个相同的副本。集群中的每个broker存储一个或多个partition。多个producer和consumer可同时生产和消费数据。
7.1 broker
Kafka 集群包含一个或多个服务器，服务器节点称为broker。
broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。
如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。
如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。
7.2 topic
每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）
类似于数据库的表名
7.3 partition
topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。
7.4 Producer
生产者即数据的发布者，该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。
7.5 Consumer
消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。
7.6 Consumer Group
每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。
7.7 Leader
每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。
7.8 Follower
Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。
