kafka概念详述

【一】kafka基本概述

          具有发布和订阅消息流，以容错的方式记录消息流，以文件的方式来存储消息流，可以在消息发布的时候进行处理。简而言之，kafka的功能就是实时流的管道，实时流的处理

【二】kafka基本概念

          1、Producer:消息和数据的生产者，向kafka的一个topic发布消息的进程/代码/服务，在发送消息之前，会对消息进行分类，即Topic

         2、Consumer:消息和数据的消息者，订阅数据(Topic)并且处理kafka集群发布消息的进程/代码/服务

        3、Consumer Group:消费者组，一个consumer group包含多个consumer,用户可以指定consumer的group,各个consumer可以组成一个group,每个消息只能由一个group中的一个consumer消费，如果一个消息想要被多个consumer消费，这些consumer必须在不同的group中

       4、Broker：kafka集群中的每个kafka节点

       5、Topic：kafka的消息类别，对数据进行区分和隔离

       6、Partition:topic物理上的分组，一个topic可以分为多个partition，topic下的数据会被分散存储到多个partition,每个partition是一个有序队列

       7、Replication（副本）:同一个partition可能会有多个Replication，多个副本之间的数据是一样的

       8、Replication Leader:

       9、Segment:partition物理上由多个segment组成，每个segMent存在着message信息

命令创建一个主题：sh kafka-topic.sh --create --zookeeper 192.168.131.166:2181 --replication-factor 1 --partitions 1 --topic test

发送一个消息：sh kafka-console-producer.sh --broker-list 192.168.131.166:9092 --topic test

消费一个消息： sh kafka-console-consumer.sh --bootstrap-server 192.168.131.166:9092 --topic test --from-beginning

【三】kafka特点

      1、分布式：多分区(partition)，多副本(容错扩展性)，多订阅者，基于zookeeper调度

      2、高性能：高吞吐量，低延迟，高并发，时间复杂夫O(1)

      3、持久性与扩展性：数据可持久化，容错性，支持在线水平扩展(broker可以有多个partition)，消息自动平衡(消息均衡，避免单个服务器压力过大)

【四】kafka应用场景

         1、消息系统，kafka具有高吞吐量，内置的分区，备份冗余分布式的特点，为大规模消息处理提供了一种很好的解决方案，kafka每秒可以生产约20万消息，每秒可以处理55万消息

         2、应用监控，利用kafka采集应用程序和服务器健康相关的指标，如CPU占有率，IO,内存，连接数，TPS,QPS等，然后将指标信息进行处理，从而构建一个具有监控仪表盘，曲线图等可视化监控系统。许多公司通过KAFKA+ELK整合构建应用服务系统。

        3、持久性日志，

        4、用户行为追踪：为了更好的了解用户行为，操作习惯。将用户的操作轨迹，内容等信息发送到kafka集群上，再通过大数据进行数据分析处理，生成相应的统计报告

        5、流处理。需要将已收集的流数据提供给其他计算框架进行处理，可以理解为应用解耦

【六】kafka常见问题

1、kafka消息重复消费原因

根本原因：消费者已经消费完了数据，但是因为种种原因导致offset没有提交

原因1：强行结束消费者服务，导致消费后的数据，offset没有及时提交，从而下次重启，会导致消息重复消费

原因2：设置offset自动提交，关闭kafka之前，如果在close之前，调用consumer.unsubscribe()可能会使部分offset没有提交

原因3：消费后的数据，当offset还没有提交，partition就断开连接，比如通常会遇到消费的数据，处理很耗时，导致超过了kafka的session timeout时间，那么就可能会冲新平衡，此时一定有机率offset没有提交，导致重新平衡后重复消费消息

原因4：当消费者重新分配partition的时候，可能会出现从头开始消费的情况，导致重发问题

2、kafka消费者消费数据，数据丢失原因

设置offset自动提交，数据还在内存中未处理完成，因为各种原因导致服务宕掉，但offset已经提交过去了，从而导致kafka以为这部分的数据已经正常消费完，消费者重启会丢失这部分数据；如果kafka发送数据过快，导致服务器网卡爆满，可能也会出现丢包现象。总而言之就是来的快，去的慢，然后offset又提交了。

一次拉取了十条消息，第一次commit就将最大的offset提交，这样在消费到第二条消息如果遇到报错关闭消费者后，下次重启也会从第十一条开始消费，所以丢掉了未消费的九条消息，该问题只会出现在一次拉取多条的情况下。可以将commit放置到循环内，自行控制offset，每次+1，可以保证消息的不丢失，但是会造成多次请求。

如何保证消费者消费数据不重复，不丢失？

 无论是数据丢失还是重新消费数据，其实本质还是因为offset的问题，所以如果想要解决这些问题，则需要从这里下手，当时遇到这个问题，我是自己手动维护offset。

1、每次消费一条数据，我就更新每一个topic+partition位置的offset在内存中

Map      key=topic+partition ,value=offset

当调用关闭consumer线程的时候，把上面的Map记录到文件中，下一次启动consumer，从这里面读取offset，然后使用consumer.seek()方法指定到上次的offset位置

集群情况下，最好存储在redis中

3、kafka消费者指定分区的策略

假设topic有10个分区，3个消费者(0,1,2,3,4,5,6,7,8,9)

Range范围策略

n=分区数量/消费者数量  10/3=3

m=分区数量%消费者数量 10%3=1

前m个消费者会消费n+1个分区，后面的消费n个分区

即c1消费0，1，2，3；c2消费4，5，6 ；c3消费7，8，9

RoundRobin轮询策略

先根据hashcode将10个分区进行排序，可能最终会是0，3，4，2，1，5，7，8，6，9

c1:0,2,7,9

c2:3,1,8

c3:4,5,6

 Stricky均匀分配，分区的分配和上次分配保持一致

c1:0,2,7,9                                                 c1:0,2,7,9,3

c2:3,1,8 （c2消费者挂掉）-->reblance  

c3:4,5,6                                                    c3:4,5,6,1,8

谁负责运行这些算法，并通知消费者指定消费具体的分区

角色：Coordinator

(1)kafka集群如何确定谁才是Coordinator?

a、同一个group中的消费者会发送一个请求(GroupCoordinatorRequest)给kafak集群

b、集群会返回一个最小负载的broker节点的id，担任Coordinator角色

reblance具体操作

a、JoinGroup,所有消费者会向该节点发送请求(group_id,member_id),该节点会选举一个消费者leader,并返回给所有消费者

b、synchronized group state,同步阶段，leader消费者根据具体的分配策略进行指定分区，然后将这些消息同步给其他消费者

4、副本机制(副本数量不能超过节点的数量)

查看副本信息：sh kafka-topics.sh --zookeeper 192.168.131.166:2181 --describe --topic replica_topic

问题一：leader副本选举

leader副本会维护一个同步副本列表，当 producer 往 broker 发送消息，消息先写入到对应 leader 分区上，然后复制到这个分区的所有副本中。只有将消息成功复制到所有同步副本（ISR）后，这条消息才算被提交。由于消息复制延迟受到最慢同步副本的限制，因此快速检测慢副本并将其从 ISR 中删除非常重要

i