KAFKA基础及简单使用

kafuka基础架构

 

 

kafka的定义：kafka是一个分布式的基于发布/订阅模式的消息队列，主要应用于大数据实时处理领域。

 

消息队列（Message Queue）的两种模式：

            （1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）消息生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并消费消息。消息被消费以后，在queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

            （2）发布/订阅模式（一对多，消费者消费数据之后不会清除消息）消息生产者（发布者）将信息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被订阅者消费。

 

kafka基础架构：

            producer产生数据，发送到Kafka集群，供consumer组消费。

            （1）producer：消息生产者 ，就是向kafka broker发送消息的客户端。

            （2）consumer：消息消费者，向kafka broker取消息的客户端。

            （3）consumer group：消费者组，由多个consumer组成，消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

            （4）Broker：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

            （5）topic：可以理解为一个队列，一个主题，生产者和消费者面向的都是一个topic。

            （6）partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。

            （7）replica：副本，为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够保持继续工作，kafka提供了副本机制，一个topic的每个分区都有若然个副本，一个leader和若干个flower。

            （8）leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader。

            （9）flower：每个分区多个副本中的“从”，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个flower会成为新的leader。

 

kafka作用：

        （1）异步处理 （2）消除峰值 （3）解耦

 

kafka组成：

        （1）Topic   主题，可以理解为一个队列；

        （2）Broker  一个kafka的服务称之为Broker，kafka可以集群部署，每一个kafka部署就是一个Broker；

        （3）producer&consumer：生产者和消费者。一般消息系统都有生产者和销售者的概念。生产者产生消息，即把消息放入topic中，而消费者则从topic中获取消息处理。一个生产者可以向多个Topic发送消息，一个消费者也可以同时从几个Topic中接收消息。同样的，一个Topic也可以被多个消费者来接收消息。

        （4）partition：分区，或者说分组，分组的kafka提升吞吐量的一个关键设计，这样可以让消费者多线程并行接收消息，创建Topic时可以指定Partition数量，一个Topic可以为多个Partition，也可以只有一个Partition，每一个Partition是一个有序的，不可变的消息序列。每一个消息在各自的Partition中有唯一的ID。这些ID是有序的，称之为offset，offset在不同的Partition中是可以重复的，但是在一个Partition中是不可以重复的。越大的offset的消息是最新的。kafka只保证在每个Partition中的消息是有序的，就会带来一个问题，即如果一个Consumer在不同的Partition中获取消息，那么消息的顺序也是和Producer发送到kafka中的消息的顺序是不一致的。

        如果是多个Partition，生产者把消息放在Topic中，可以决定放到哪个Partition。这个可以使用简单的轮询方法，也可以使用一些Hash算法。

        一个Topic的多个Partition也可以分布部署在不同的server上，一个kafka集群。配置项为：num。partitions，默认为1.每一个Partition也可以在Broker上复制多份，用来做容错。

 

 

kafka工作流程及文件存储机制：

            kafka中消息是以topic进行分类的，生产者生产消息，消费者消费消息，都是面向topic的。

            topic是逻辑上的概念，而partition是物理上的概念，每个partition对应一个log文件，该log文件中储存的就是producer生产的数据。producer生产的数据会不断追加到该log文件末端，且每条数据都有自己的offset。消费者组中的每个消费者，都会实时记录自己消费到哪个offset，以便出错恢复时，从上次的位置继续消费。

            由于生产者生产的消息会不断追加到log文件末尾，为防止log文件过大导致数据定位效率低下，kafka采取了分片和索引机制，将每个partition分为多个segment。每个segment对应两个文件--".index"文件和".log"文件。这些文件位于一个文件夹下，该文件夹命名规则为：topic名称+分区序号。

 

kafka造成数据重复消费的情况：

    (1)在生产过程中：当ack设置为-1时，leader给flower同步数据，flower同步完成后，leader返回ack，在完成时leader挂掉，producer没有收到ack，新选出的leader会再次接收数据造成数据重复。

  （2）在消费过程中，消费者先得到数据后提交offset，当得到数据后，消费者挂掉，没有记录offset，重启后，会再次读取这段信息，造成数据重复。

 

kafka造成数据漏消费的情况：

    (1)在生产过程中：当ack设置为0或1时，leader给flower同步数据，flower同步完成前，leader返回ack，但在发送完ack后leader挂掉，producer记录这段数据的ack，造成信息漏消费。

  （2）在消费过程中，消费者先提交offset后消费，当消费者提交offset后挂掉，重启后不会消费这一段数据，造成漏消费。

 

kafka生产者消息发送流程：kafka的producer发送信息采用的是异步发送的方式。在消息发送    的过程中，涉及到了两个线程--main线程和sender线程，以及一个线程共享变量-                        -RecordAccumulator。main线程将消息发送给RecordAccumulator，Sender线程不断从RecorAccumulator中拉取消息发送到Kafkabroker。

    （相关参数：barch.size：只有数据累计到batch.size之后，sender才会发送数据。linger.ms：如果数据迟迟未达到batch.size，sender等待linger.time之后就会发送数据。）

      {Producer-->send(ProcucerRecord)-->Interceptors(拦截器)-->Serializer(序列化器)-->Partitioner(分区器)}-->RecordAccumulator

  -->sender发送数据。

kafka消费者消费数据：Consumer消费数据时的可靠性是很难保证的，因为数据在kafka中是持久化的，故不用担心数据丢失问题。

    由于consumer在消费过程中可能会出现宕机等故障，consumer恢复后，需要从故障前的位置继续消费，所以consumer需要实时记录自己消费到哪个offset，以便于故障恢复后继续消费。

   所以offset的维护是consumer消费数据必须考虑的问题。

   两种方式：（1）手动提交：同步提交commitSync和异步提交commitAsync，同步会失败重试，异步不会，但是这两个方法都会产生数据的重复消费。

   2）自动提交

 

kafka是如何保证数据可靠性的：

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

 为了确保flower与leader同步完成，flower在leader挂掉后可以选出新的leader，要在全部flower同步完成后，才发送ack。

  ISR：leader收到数据，所有flower都开始同步数据，但有一个flower，因为某种故障，迟迟不能与leader进行同步，那么leader不能一直等下去，leader维护了一个动态的in-sync replica set（ISR）意为和leader保持同步的flower集合。当ISR中的flower完成数据同步之后，leader就会给flower发送ack，如果flower长时间未向leader同步数据，则该flower将被踢出ISR，该时间阈值由replica.lag.time.max.ms参数设定。leader发生故障后，就会从ISR中选举新的leader。

 

ack参数设置：（1）0：producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能丢失数据。

            （2）1：producer等待brokerbroker的ack，partition的leader落盘成功后返回ack，如果在flower同步成功之前leader故障，那么将会丢失数据。

            （3）-1或all：producer等待broker的ack，partition的leader和flower全部落盘成功后才返回ack。但如果在flower同步完成之后，broker发送ack之前，      leader发生故障，那么会造成数据重复。

 

Zookeeper在kafka中的作用：

                kafka集群中有一个broker会被选举为controller，负责管理集群broker的上下线，所有topic的分区副本分配和leader选举等工作。

                Contraller的管理工作都是依赖于Zookeeper的。

 

Kafka基本命令行操作：

                (0)启动

                    bin/kafka-server-start.sh -daemon    /opt/module/kafka_2.110.11.0.2/config/server.properties

                （1）查看当前服务器中的所有topic

                    bin/kafka-topic.sh --zookeeper hadoop102:2181 --list

                 (2)创建topic

                     bin/kafka-topic.sh --zookeeper hadoop102:2181 --create --topic xx --partitions x --replication-factor x

                 (3)删除topic

                     bin/kafka-topic.sh --zookeeper hadoop102:2181 --delete --topic xx

                     需要server.properties中设置delete.topic.enable=true否则只是标记删除。

                 (4)发送消息

                     bin/kafka-console-producer.sh --broker-list hadoop102:9092 --topic xx

                 (5)消费消息

                     bin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --from-beginning --topic xx

                     --from-beginning：会把主题中以往所有的数据都读取出来。

                 (6)查看某个topic的详情

                     bin/kafka-topic.sh --zookeeper hadoop102:2181 --describe --topic xx