Apache Kafka综述

在大数据中，会使用到大量的数据。面对这些海量的数据，我们一是需要做到能够收集这些数据，其次是要能够分析和处理这些海量数据。在此过程中，需要一套消息系统。

Kafka专门为分布式高吞吐量系统设计。作为一个消息代理的替代品，Kafka往往做的比其他消息中间件做的更好。

与其他消息队列产品相比，它主要有以下优点：

• 吞吐量高
• 内置分区
• 复制能力
• 固有的容错能力

因此，Kafka非常适合大规模的消息处理应用。

什么是消息系统？

消息系统负责将数据从一个应用传递到另一个应用，应用就可以专注于数据，而不用担心数据如何共享。分布式消息传递基于可靠消息队列的概念。消息在客户端应用程序和消息传递系统之间异步排队。
有两种类型的消息模式可用：

• 点对点模式
• 订阅-发布模式（pub-sub），也是最常用的一种消息模式

点对点消息类型

在点对点的消息传递类型中，所有的消息都保留在消息队列中。一个或多个消费者可以消耗队列中的消息，但特定的消息只能有最多一个消费者消费。一旦消费者消费了队列中的消息，该消息将会在消息队列中消失。
点对点消息系统最典型的例子是订单处理系统，其中每个订单将有由订单处理器处理，但多个订单处理器也可以同时工作。

发布-订阅消息类型

在发布-订阅系统中，消息被保留在各个主题中。
与点对点系统不同的是，一个订阅者可以订阅一个或多个不同主题中的消息并使用这些主题中的所有消息。
在发布-订阅系统中，消息的生产者称为发布者，消息的使用者称为订阅者。
一个现实的例子是dish天线电视，它发布不同的渠道和主题，如运动、音乐、电影等，任何人都可以订阅自己需要的主题集，并接收到订阅主题的消息。

什么是Kafka?

Kafka is a distributed,partitioned,replicated commit logservice.

1. Apache Kafka 是一个分布式发布 - 订阅消息系统和一个强大的队列，可以处理大量的数据，并使你能够将消息从一个端点传递到另一个端点。
2. Kafka 适合离线和在线消息消费。
3. Kafka 消息保留在磁盘上，并在群集内复制以防止数据丢失。
4. Kafka 构建在 ZooKeeper 同步服务之上。 它与 Apache Storm 和 Spark 非常好地集成，用于实时流式数据分析。

优点

• 可靠性
  Kafka是分布式、分区复制、可容错的
• 可扩展性
  消息传递系统可以轻松扩缩容，不用关机
• 耐用性
  Kafka使用“分布式提交日志”，这意味着消息会尽可能快地保留在磁盘上，因此它是持久的。
• 高性能
  Kafka无论是发布还是订阅消息的吞吐量都是很高的。即使存储了很多TB的消息，还是能够保证高性能。

Kafka非常快，并且能保证零停机和零数据丢失

关键术语

1. 生产者和消费者：Productor & Customer
   在Kafka中，消息的发布者称为生产者Productor，消息的接受和使用者称为消费者Customer
2. broker：
   Kafka消息队列集群中有很多台server，每一台server都可以存储消息，这每一台server都可以称做是Kafka的一个实例，也称为broker
3. 主题：topic
   一个topic中会保存同一类的消息，相当于对消息进行分类。productor在向Custom发送消息的时候，需要指定topic，也就是制定了该消息属于哪一分类。
4. 分区：partition
   每个topic都划分为多个partition，每个partition在存储层面都是一个append log文件。任何写进某partition的消息都会被追加在一个log文件的尾部。
   分区的意义：Kafka基于文件进行存储，当文件内容过大的时候，很容易达到单个磁盘的上限。使用分区进行存储，一个分区存储一个文件，保证单个文件不会过大的情况下，还能将数据存在不同的broker = Kafka server上，从而实现了负载均衡，能够承载更多的消费者
5. 偏移量：offset
   一个分区存储一个文件，而消息在文件中的位置就称为是偏移量offset，offset的字符类型为long长字符类型，它可以唯一标记一条消息。由于Kafka并没有提供额外的消息索引机制，因此文件只能顺序读写，所以Kafka基本不允许对消息进行“随机读写”。

小结Kafka：

• 是基于发布-订阅的分布式消息队列
• 面向大数据，消息存储在topic中，而每个topic会分为多个patition分区；
• 消息存储在磁盘中，每个partition分区对应一个磁盘上的一个文件来存储消息，消息的写入就是在log文件后追加内容，文件可以在集群内复制防止丢失；
• 即使消息被消费，消息也不会立刻消失，可以通过配置以实现自动删除来释放空间
• Kafka依赖分布式协调服务zookeeper，适合离线/在线消息的消费，与storm/spark等实时流式数据处理工具常常结合使用。

Kafka基本原理

1. 分布式和分区：distributed、partitioned
   Kafka是一个分布式的发布-订阅消息队列，主要体现在哪些方面？
   体现在大量的数据被保存在磁盘上，但单个磁盘的容量是有限的，于是消息被生产者生产的时候分为不同的topic主题来保存，每个topic又被分为多个partition分区，而每个partition分区对应一个文件，以文件的方式来保存消息数据，每个文件又可以被保存在不同的broker上，这样就实现了Kafka集群来分布式存储消息队列。
   另外，每个partition都有一定的副本，可以备份到不同的borker上，从而提高可用性。
   总的来说就是，一个topic对应的多个partition上的文件分散保存在集群的多个不同broker上，存储的方式是一个partition对应一个文件，每个broker负责存储在自己机器上的每个文件的读写。

2. 副本：replicated
   Kafka可以通过配置指定partition的备份个数（replicas），每个partition将会被备份到多台机器上，提高了可用性，备份数量通过配置文件可以指定。
   实质上，冗余备份在分布式系统中很常见。
   有副本的存在，就会涉及到同一个文件的多个副本如何管理和调度。
   Kafka设置了“leader机制”，每个partition选举一个broker作为leader，用来负责对该分区的读写，其余broker则作为follower，只需简单地和leader同步即可。如果原来的leader失效，partition则会选举新的broker成为leader。
   至于如何选取 leader，实际上如果我们了解 ZooKeeper，就会发现其实这正是 Zookeeper 所擅长的，Kafka 使用 ZK 在 Broker 中选出一个 Controller，用于 Partition 分配和 Leader 选举。
   实际上，作为leader的server，承担了整个分区的所有读写请求，负担是比较大的。从整体考虑，有多少个partition就有多少个leader，Kafka将leader分摊到不同的broker上，也算是整体上的一种负载均衡。

3. Kafka数据流处理
   
   （1）数据产生方式：produce

生产者写入消息数据可以指定4个参数，分别为topic,partition,key,value。其中topic和value（要写入的数据）必须指定，而key和partition是可选的。
对于一条记录，要先对其进行序列化，再按照topic和partition，发送到对应的队列中去。如果没有指定partition，有两种情况：

• 指定key，按照key进行哈希，同一个key的消息进一个partition

• 未指定key， round-robin进行partition的选择
  producer将会和topic下的每个partiton leader保持socket连接，消息由producer直接发送给broker。
  其中partition leader的身份在zookeeper中已经注册，producer作为zookeeper client，已经注册了watch用来监听partition leader的变更事件，因此可以准确知道leader是谁。
  producer端采用异步发送，先将一部分的消息存在客户端的buffer里，并将其分批发送给broker，小数据io很多会增加整体网络的延迟，批量延迟发送实际上是提供了网络效率。
  （2）数据消费过程：custome

• 对于消费者，不是以单独形式存在的，每个消费者都属于一个消费群租customer group,一个group包含多个consumer。需要注意的是，消费者的订阅topic行为都是以customer group的形式来订阅的，发送到topic的消息，只会被订阅该topic的每个group中的每个customer消费。

• 如果说所有的customer都有共同的group，那么就像是一个点对点的消息系统；如果每个消费者都属于不同的group，那么消息会广播给所有的消费者。

• 实际上消息是根据partition来分的，一个partition只能被消费组里的一个消费者消费，但是可以多个不同的消费组消费，消费组里的每个消费者是关联到一个partition的；因此有一个说法：对同一个topic，同一个group中不能有多于partitions个数的customer同时消费，否则某些customer将无法得到消息。

• 同一个消费组的两个customer不能同时消费一个partition

• partition 中的消息只有一个 consumer 在消费，且不存在消息状态的控制，也没有复杂的消息确认机制，可见katka broker 端是相当轻量级的。当消息被 consumer 接收之后，需要保存 Offset 记录消费到哪，以前保存在ZK中，由于 ZK 的写性能不好，以前的解决方法都是Consumer 每隔一分钟上报一次，在0.10 版本后，Kafka 把这个Offset 的保存，从ZK 中剥离，保存在一个名叫 consumeroffsets topic 的Topic 中，由此可见consumer 客户端也很轻量级

用例

Kafka可以在很多场景中使用，以下列出一些用例：

• 指标
  Kafka通常用于操作监控数据。这涉及到聚合来自分布式应用程序的统计信息，以产生操作数据的集中馈送。
• 日志聚合解决方案
  可用于跨组织收集多个服务的日志，且以标准格式提供给多个服务器。
• 流处理
  流行的框架(如Storm和Spark Streaming)从主题中读取数据，对其进行处理，并将处理后的数据写入新主题，供用户和应用程序使用。 Kafka的强耐久性在流处理的上下文中也非常有用。