初识Kafka

1.Kafka背景故事

Franz Kafka，他是奥匈帝国作家，代表作《审判》、《城堡》、《变形记》。Apache Kafka 取名的来源也正是来源于这位作家的名字。Kafka 的作者之一 Jay Kreps 在大学期间很喜欢这位作家，而 Kafka 的写性能很强，找个作家的名字来命名正好“对应”。

Kafka 最初是由 LinkedIn 公司开发的，后来三位原作者 Jun Rao、Jay Kreps、Neha Narkhede 出走成立了 Confluent。Neha Narkhede 是Confluent CTO，也是《Kafka 权威指南》的作者之一。在大数据领域，Jay Kreps 针对 Lambda 架构的缺点提出了 Kappa 架构。

 

2.Kafka是什么

消息系统

Kafka 和传统的消息系统(也称作消息中间件)都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时，Kafka 还提供了大多数消息系统难以实现的消息顺序性保障及回溯消费的功能。

存储系统

Kafka 把消息持久化到磁盘，相比于其他基于内存存储的系统而言，有效地降低了数据丢失的风险。也正是得益于 Kafka 的消息持久化功能和多副本机制，我们可以把 Kafka 作为长期的数据存储系统来使用，只需要把对应的数据保留策略设置 为“永久”或启用主题的日志压缩功能即可。

流式处理平台

Kafka 不仅为每个流行的流式处理框架提供了可靠的数据来源，还提供了一个完整的流式处理类库，比如窗口、连接、变换和聚合等各类操作。

 

3..Kafka相关概念

Kafka是一种高吞吐量的分布式发布订阅消息系统，为了更好地理解和使用 Kafka，这里介绍一下Kafka的相关概念：

Broker：Kafka集群包含一个或多个服务器，这些服务器被称为“Broker”。

Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为“Topic（主题）”。物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个Broker上，但用户只需指定消息的Topic，即可生产或消费数据，而不必关心数据存于何处。

Partition：是物理上的概念，每个Topic包含一个或多个Partition。

Producer：负责发布消息到Kafka Broker。

Consumer：消息消费者，向Kafka Broker读取消息的客户端。

Consumer Group：每个Consumer属于一个特定的Consumer Group，可为每个Consumer指定Group Name，若不指定Group Name，则属于默认的Group。同一个Topic的一条消息只能被同一个Consumer Group内的一个Consumer消费，但多个Consumer Group可同时消费这一消息。

 

4.Kafka的特性

Kafka具有以下良好的特性：

高吞吐量、低延迟：Kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒；

可扩展性：Kafka集群具有良好的可扩展性；

持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份，防止数据丢失；

容错性：允许集群中节点失败（若副本数量为n，则允许n-1个节点失败）；

高并发：支持数千个客户端同时读写。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃；

顺序保证：在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个分区内的消息的有序性；

异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

 

5.Kafka的应用场景

Kafka的主要应用场景包括：

日志收集：一个公司可以用Kafka收集各种日志，这些日志被Kafka收集以后，可以通过Kafka的统一接口服务开放给各种消费者，例如Hadoop、HBase、Solr等；

消息系统：可以对生产者和消费者实现解耦，并可以缓存消息；

用户活动跟踪：Kafka经常被用来记录Web用户或者APP用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到Kafka的主题（Topic）中，然后订阅者通过订阅这些主题来做实时的监控分析，或者装载到Hadoop、数据仓库中做离线分析和挖掘；

运营指标：Kafka也经常用来记录运营监控数据，包括收集各种分布式应用的数据，生产环节各种操作的集中反馈，比如报警和报告；

流式处理：Kafka实时采集的数据可以传递给流处理框架（比如Spark Streaming和Storm）进行实时处理。

 

6.Kafka的消息传递模式

一个消息系统负责将数据从一个应用传递到另外一个应用，应用只需关注于数据，无需关注数据在两个或多个应用间是如何传递的。分布式消息传递基于可靠的消息队列，在客户端应用和消息系统之间异步传递消息。 对于消息系统而言，一般有两种主要的消息传递模式：点对点传递模式和发布订阅模式。 大部分的消息系统选用发布订阅模式。Kafka就是一种发布订阅模式。

点对点消息传递模式

在点对点消息系统中，消息持久化到一个队列中。此时，将有一个或多个消费者消费队列中的数据。但是一条消息只能被消费一次。当一个消费者消费了队列中的某条数据之后，该条数据则从消息队列中删除。该模式即使有多个消费者同时消费数据，也能保证数据处理的顺序。

发布订阅消息传递模式

在发布订阅消息系统中，消息被持久化到一个主题（topic）中。与点对点消息系统不同的是，消费者可以订阅一个或多个主题，消费者可以消费该主题中所有的数据，同一条数据可以被多个消费者消费，数据被消费后不会立马删除。在发布订阅消息系统中，消息的生产者称为“发布者”，消费者称为“订阅者”。

 

7.Kafka和Flume之间的联系与区别

Kafka与Flume的很多功能确实是重叠的，二者的联系与区别如下：

（1）Kafka是一个通用型系统，可以有许多的生产者和消费者分享多个主题。相反地，Flume被设计成特定用途的工作，特定地向 HDFS 和 HBase 发送数据。Flume为了更好地为 HDFS 服务而做了特定的优化，并且与 Hadoop 的安全体系整合在了一起。因此，如果数据需要被多个应用程序消费的话，推荐使用 Kafka，如果数据只是面向 Hadoop 的，可以使用 Flume。

（2）Flume拥有许多配置的数据源 (source) 和数据槽(sink)，而Kafka拥有的是非常小的生产者和消费者环境体系。如果数据来源已经确定，不需要额外的编码，那么可以使用Flume 提供的数据源和数据槽，反之，如果需要准备自己的生产者和消费者，那么就需要使用Kafka。

（3）Flume可以在拦截器里面实时处理数据，这个特性对于过滤数据非常有用。Kafka需要一个外部系统帮助处理数据。

（4）无论是Kafka或是Flume，两个系统都可以保证不丢失数据。

（5）Flume和Kafka可以一起工作。Kafka是分布式消息中间件，自带存储，更合适做日志缓存，Flume数据采集部分做得很好，可以使用Flume采集日志，然后，把采集到的日志发送到Kafka中，再由Kafka把数据传送给Hadoop、Spark等消费者。