大数据技术Kafka--Kafka概述（一）

一、Kafka概述

1.1 kafka是什么

    在流式计算中，Kafka一般用于缓存数据，Storm通过消费Kafka的数据进行计算。
    1）Apache Kafka是一个开源消息系统，由Scala编写而成，是由Apache软件基金会开发的一个开源消息系统项目；
    2）Kafka最初是由LinkedIn公司开发，并于2011年开源，2012年10月从Apache incubator毕业，该项目的目标是为了处理实时数据提供一个统一，高通用，低等待的平台。
    3）Kafka是一个分布式消息队列。Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer消息接受者称为Consumer，此外，Kafka集群有多个Kafka实例组成，每个实例（server）称为broker。
    4）无论是Kafka集群还是producer和consumer都依赖于Zookeeper集群保存一些meta信息，来保证系统的可用性。

1.2 消息队列内部实现原理

    （1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）
    点对点模型通常是一个基于拉取或者轮训的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接受者接收处理，即使有多个消息监听者也是如此
    （2）发布/订阅模式（一对多，数据生产后，推送给所有订阅者）
     发布订阅模型则是一个基于推送的消息传送模型。发布订阅模块可以有多种不同的订阅者，历史订阅者只在主动监听主体时才能接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。

1.3 为什么需要消息队列

1）解耦
    允许你独立的扩展或者修改两边的处理过程，只要确保他们遵守同样的接口约束。
2）冗余
    消息队列把数据进行持久化直到他们已经完全处理，通过这一方式规避了数据丢失的风险，许多消息队列采用的“插入-获取-删除”方式中，在把一个消息从队列汇中删除之前，需要你的处理系统明确的指出该消息已经处理完毕，从而保证你的数据被安全的保存直到你使用完毕。
3）扩展性
    因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率，只要另外增加处理过程即可。
4）灵活性&巅峰处理能力
    在访问量剧增的情况下。应用仍然需要继续发挥作用。但是这样的突发流量并不常见。如果为以能处理这类峰值方位为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住的访问压力。而不会因为突发的超负荷请求而完全奔溃。
    5）可恢复性
    系统的一部分组件失效的时候，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
6）顺序保证
    在大多会用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照具体的顺序来处理。（Kafka保证一个Partition内的消息的有序性）
7)缓冲
    有助于控制和优化数据流经过的速度，解决生产消费消息和消费消息的处理速度不一致的情况。
8）异步通信
    很多时候，用户也不需要立即处理消息，消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列放入多少消息就放多少消息，然后在需要的时间再去处理他们。

1.4 Kafka架构

1）Producer：消息生产者，就是向Kafka broker发送消息的客户端
2）Consumer：消息消费者，向Kafka broker获取消息的客户端
3）Topic：主题，用于存放消息，可以理解为一个队列，
4）Consumer Group（CG）：这是Kafka用来实现一个Topic消息的广播(发送给所有的Consumer) 和单播（发送给任意一个Consumer）的手段。一个topic可以有多个CG。topic的消息会复制给Consumer。如果需要实现广播，只要给每个Consumer有一个独立的CG就可以了。要实现单播只要所有的Consumer在同一个CG。用CG还可以将Consumer进行自由的分组而不需要多次发送消息到不同的topic
5）Broker：一台Kafka服务器就是个Broker。一个集群由多个Broker组成。一个Broker可以容纳多个Topic。
6）Partiton：为了实现扩展性，一个非常大的Topic可以分布到多个Broker（即服务器）上，一个Topic可以分为多个Partition，每个Partition就是一个有序的队列。Partition中的每条消息都会被分配一个有序的id（offset）。Kafka只保证一个Partition中的顺序将消息发给Consumer，不保证一个Topic的整体（多个Partition间）的顺序
7）Offset：Kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想查找位于2049的位置，只要找到2048.kafka的文件即可。当然the first offse就是00000000.kafka

1.5分布式模型

    Kafka每个主题的多个分区日志分布式地存储在Kafka集群上，同时为了故障容错，每个分区都会以副本的方式复制到多个消息代理节点上。其中一个节点会作为主副本（Leader），其他节点作为备份副本（Follower，也叫从副本）。主副本会负责所有的客户端的读写操作，备份副本仅仅从主副本上同步数据。当主副本出现故障时，备份副本中的一个副本会被选举称为新的主副本。因为每个分区的副本中只有主副本接收读写，所以每个服务端都会作为某些分区的主副本，以及另外一些分区的备份副本，这样Kafka集群所有服务端整体上对客户端是负载均衡的。
    Kafka的生产者和消费者相当于服务器端而言都是客户端。
    Kafka生产者客户端发布消息到服务端的指定主题，会指定消息所属的分区。生产者发布消息时根据消息是否有键，采用不同的分区策略。消息如果没有键时，通过轮询的方式进行客户端负载均衡；消息有键时，根据分区语义（例如hash）确保相同键点的消息总是发送到同一个分区。

    Kafka的消费者通过订阅主题来消费消息，并且每个消费者都会设置一个消费组名称。应为生产者发布到每个主题的每一条消息都智慧发送给消费者组的一个消费者。所以，如果要实现传统消息系统的“队列”模型，可以让每一个消费者都拥有相同的消费组名称，这样消息就会负责均衡到所有的消费者；如果要实现“发布-订阅"模式，则每个消费者的消费者组名称都不相同，这样每条消息就会广播给所有的消费者。

    分区是消费者现场模型的最小并行单位。如下图（图一）所示，生产者发布消息到一台服务器的三个分区时，只有一个消费者消费所有的三个分区。在下图（图二）中，三个分区分布在三台服务器上，同时有三个消费者分别消费不同的分区。假设每个服务器的吞吐量是300M，在下图（图一）中分摊到每个分区只有100M而在下图（图二）中，集群的吞吐量有900MB,可以看到，增加服务器的节点会提升集群的性能，增加消费者的数量会提升处理性能。

同一个消费者下多个消费者互相协调消费工作，Kafka会将所有的分区平均地分配给所有的消费者实例，这样每个消费者都可以分配到数量均等的分区。Kafka的消费组管理协议会动态地维护消费组的成员列表，当一个新消费者加入消费者组，或者有消费者离开消费组，都会触发再平衡操作。

Kafka的消费者消费消息时，只保证在一个分区内的消息时完全有序的，并不保证同一个主题中多个分区的消息顺序。而且，消费者读取到一个分区的消息的顺序和生产者写入到这个分区的顺序是一致的。比如，生产者写入“hello”和"Kafka“两条消息到分区P1,则消费者读取到的顺序也一定是”hello“和”Kafka“。如果业务上需要保证所有的su消息一致，只能通过设置一个分区完成。但是这种做法的缺点是最多只能有一个消费者进行消费。一般来说，只需要保证每个分区的有序性，再对消息假设键来保证相同键的所有消息落入到同一分区，就可以满足绝大多数的应用。