简简单单kafka（一）

第一章：Kafka概述

1.1基础概念

（1）定义：Kafka是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。
（2）消息队列之发布、订阅模式：
消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅
者消费。

1.2Kafka的基础架构

1）Producer ：消息生产者，就是向kafka broker发消息的客户端；
2）Consumer ：消息消费者，向kafka broker取消息的客户端；
3）Consumer Group （CG）：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
4）Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
5）Topic ：可以理解为一个队列，生产者和消费者面向的都是一个topic；
把相同的数据放到同一个topic主题里面，主要是进行分类的
6）Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列；
可以提高生产者往里面写的速率，是分区为单位写副本的。
7）Replica：副本，为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作，kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower。
8）leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader。
9）follower：每个分区多个副本中的“从”，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个follower会成为新的leader。

第二章：Kafka配置

2.1 kafka群起脚本

#!/bin/bash
case $1 in
"start")
   for i in hadoop102 hadoop103 hadoop104
   do
   echo "============== $i kafka小可爱已上线============== "
   ssh $i /opt/module/kafka/bin/kafka-server-start.sh -daemon /opt/module/kafka/config/server.properties
   done
;;
"stop")
   for i in hadoop102 hadoop103 hadoop104
   do
   echo "============== $i kafka小可爱已下线============== "
   ssh $i /opt/module/kafka/bin/kafka-server-stop.sh
   done
esac

2.2 kafka命令行操作

第三章：Kafka架构深入(重难点)

3.1 Kafka工作流程和文件存储机制

      Kafka中的消息是以topic进行分类的。生产者生产消息和消费者消费消息都是
  面向topic的。
    topic是逻辑层面的，而partition是物理层面的。每个partition有多个log文件
 这个log文件就是生产者生产的数据，数据是不断追加到log文件的末端，并且
 每条数据都有自己的偏移量offset，为了方便消费者消费数据进行记录，以便于
 在进行数据回复是，从上次的位置继续进行消费。

文件存储机制

由于生产者生产的消息会不断追加到log文件末尾，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个partition分为多个segment。每个segment对应两个文件——“.index”文件和“.log”文件。这些文件位于一个文件夹下，该文件夹的命名规则为：topic名称+分区序号。例如，first这个topic有三个分区，则其对应的文件夹为first-0,first-1,first-2。
1个segment的大小是1G，大于1G之后就会在新建segment。

3. 2 Kafka生产者

3.2.1分区策略

（1）方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；
（2）可以提高并发，因为可以以Partition为单位读写了。

3.2.2数据可靠性的保证

1）生产者发送数据到topic partition的可靠性保证
为保证producer发送的数据，能可靠的发送到指定的topic，topic的每个partition收到producer发送的数据后，都需要向producer发送ack（acknowledgement确认收到），如果producer收到ack，就会进行下一轮的发送，否则重新发送数据。

2）Topic partition存储数据的可靠性保证

Kafka选择了第二种方案，原因如下：

1. 同样为了容忍n台节点的故障，第一种方案需要2n+1个副本，而第二种方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。
2. 虽然第二种方案的网络延迟会比较高，但网络延迟对Kafka的影响较小。
   （2）ISR
   Leader维护了一个动态的in-sync replica set (ISR)同步副本队列，意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后，leader就会给producer发送ack。如果follower长时间（2.4版本10s，2.5版本是30s）未向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag.time.max.ms参数设定。Leader发生故障之后，就会从ISR中选举新的leader。
   （3）ack应答级别
   对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等ISR中的follower全部接收成功。
   所以Kafka为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置。
   0：这一操作提供了一个最低的延迟，partition的leader接收到消息还没有写入磁盘就已经返回ack，当leader故障时有可能丢失数据；
   1： partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据；
   -1（all）： partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。

3.2.3 幂等性

所谓的幂等性就是指Producer不论向Server发送多少次重复数据，Server端都只会持久化一条，根据<PID, Partition, SeqNumber>。幂等性结合At Least Once语义，就构成了Kafka的Exactly Once语义。即：At Least Once + 幂等性 = Exactly Once  

3.3 Kafka消费者

consumer采用pull（拉）模式从broker中读取数据。
pull模式不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一直返回空数据。针对这一点，Kafka的消费者在消费数据时会传入一个时长参数timeout，如果当前没有数据可供消费，consumer会等待一段时间之后再返回，这段时长即为timeout。

3.2.3 分区分配策略

一个consumer group中有多个consumer，一个 topic有多个partition，所以必然会涉及到partition的分配问题，即确定那个partition由哪个consumer来消费。
Kafka有两种分配策略，一是RoundRobin，一是Range。

round_robin：轮循的方式，以消费者组为单位，将消费者里订阅的所有的主题全部取出来，将主题里的每个分区排序，再对每个消费者进行轮循,有可能导致消费者消费到不是自己订阅的主题里的数据，但是完全可以避免。
range： 范围分配，以主题为单位，如果消费者没有订阅此主题，就不会收到此主题里的数据，不会导致消费错数据的情况，但是有可能导致消费者组里面的每个消费者消费分区数不均等。

3.2.3 offset的维护

由于consumer在消费过程中可能会出现断电宕机等故障，consumer恢复后，需要从故障前的位置的继续消费，所以consumer需要实时记录自己消费到了哪个offset，以便故障恢复后继续消费。
Kafka 0.9版本之前，consumer默认将offset保存在Zookeeper中，从0.9版本开始，consumer默认将offset保存在Kafka一个内置的topic中，该topic为__consumer_offsets。