【Spark内存计算】KafKa消息传输与消费模式

KafKa 是非常流行的日志采集系统，它是一个分布式的，支持多分区、多副本，基于 Zookeeper 的分布式消息流平台，它同时也是一款开源的基于发布订阅模式的消息引擎系统。
听到这里，你可能还是一头雾水，我的理解用一句话直观的说明KafKa的作用，那就是：

KafKa 是一个消息平台，主要用来处理大量数据状态下的消息队列，一般用来做日志的处理。

1、KafKa的特性：

首先从KafKa的特性来看这样的一个消息平台的样子。先有个印象，这其中的内容大多数我们都会在后面详细的说明。

特性	备注
高吞吐、低延迟：	kakfa最大的特点就是收发消息非常快，kafka每秒可以处理几十万条消息，它的最低延迟只有几毫秒。
高伸缩性：	每个主题(topic)包含多个分区(partition)，主题中的分区可以分布在不同的主机(broker)中。
持久性、可靠性：	Kafka能够允许数据的持久化存储，消息被持久化到磁盘，并支持数据备份防止数据丢失， Kafka底层的数据存储是基于Zookeeper存储的，Zookeepe的数据能够持久存储。
容错性：	允许集群中的节点失败，某个节点宕机，Kafka集群能够正常工作。
高并发：	支持数千个客户端同时读写。

2、KafKa长什么样子：

2.1、KafKa消息传输的流程（Producer、Topic、Consumer）：

从KafKa的概念图中我们可以看出，关键的信息是Procuder生产者、Topic KafKa主题、Consumer 消费者。
如果我们把KafKa比作是一个超市，那么Topic就是超市中物品的类别，我们用 方便面 来举例子：
Producer 代表着方便面的生产厂家，当然会有不同的Producer；
假设：P1代表A牌方便面在X市的生产厂，P2代表A牌方便面在Y市的生产厂，P3代表B牌方便面在X厂的生产厂。
Topic 代表着方便面摆放在超市的货架上，等待顾客购买，根据关系：Topic A就是A牌方便面，Topic B就是B牌方便面。
Consumer 就是超市的顾客了，有的顾客就想吃A牌的面，有的就想吃B牌的面。

通过上面的举例，我们可以理解出关键的对应信息：
集群中的不同的 Producer 可以向同一个 Topic 中传递信息；
集群中的同一 Topic 中的信息也可以被不同的 Consumer 消费。

2.2、向Topic中深入探索：

Topic 即主题，通过对消息指定主题可以将消息分类，消费者可以只关注自己需要的 Topic 中的消息。
在了解Topic 中的消息如何被 Consumer 消费者获取，Producer中的消息又如何向 Topic 中提交之前，我们先来看一下 Topic 的内部结构。

分区，即partitions
创建一个 Topic 时，同时可以指定分区数目，分区数越多，其吞吐量也越大，但是需要的资源也越多，同时也会导致更高的不可用性，KafKa 在接收到生产者发送的消息之后，会根据 均衡策略 将消息存储到不同的分区中。

对于方便面来说，就是 A牌的方便面 数量太多了，怎么办呢？
超市的提供的结构就是给你多个货架，（正常来说）在一个货架内的商品是会按时间的顺序来上货的；
但是不同的货架之间的时间顺序可能会被打乱，也就是说这种分区的结构：只有局部的分区有序，但不能保证全局分区有序。

同一个主题中的分区可以不在一个机器上，有可能会部署在多个机器上，由此来实现 KafKa 的伸缩性。
单一主题中的分区有序，但是无法保证主题中所有的分区有序。
分区可以为 KafKa 集群带来良好的扩展性，同时多路的存储读取也提高了 I/O 的效率，提高了并发。

2.3、消费者的消费模式：

偏移量（Consumer Offset）
在消费者消费消息时，kafka使用offset来记录当前消费的位置
在kafka的设计中，可以有多个不同的group来同时消费同一个topic下的消息，他们的的消费的记录位置offset各不项目，不互相干扰。

消费者是以 Consumer Group 消费者组的方式工作，由一个或者多个消费者组成一个组，共同消费一个 Topic。
每个分区在同一时间只能由 Group 中的一个消费者读取，但是多个 Group 可以同时消费这个 Partition。

broker: 一个独立的 Kafka 服务器就被称为broker，broker接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。
broker 集群： broker是集群的组成部分，broker集群由一个或多个broker组成，每个集群都有一个broker同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。

Consumer采用 Pull（拉） 模式从 broker 中读取数据。
Pull模式可简化 broker 的设计，Consumer 可自主控制消费消息的速率，同时 Consumer 可以自己控制消费方式，同时还能选择不同的提交方式从而实现不同的传输语义。
对于消费者而言，从 broker 中获取数据有两种可能的途径：Push（推） 与 Pull（拉）。

Push 模式：是指 broker 将数据文件 Push 给消费者，但这种模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。 尽管 broker的目标是尽可能以最快速度传递消息，并且 broker 也确实有能力做到极快的将数据打包发送，但是这样很容易造成 Consumer来不及处理消息，典型的表现就是 拒绝服务 以及 网络拥塞 。

Pull 模式：是指消费者主动从broker中拉取数据，可以根据 Consumer 的消费能力以适当的速率消费消息。 但是，如果 KafKa 中没有数据，消费者可能会陷入循环中。为了避免这种情况，Pull 请求中有参数，允许消费者请求在等待数据到达的“长轮询”中进行阻塞。