Kafka初体验

01、了解Kafka

Kafka是一个流处理平台，实现了AMQP协议，其主要特性：

• 可发布和订阅流数据，类似于消息队列或者企业级消息系统
• 以容错的方式存储流数据
• 可以在流数据产生时就进行处理

Kafka适用于什么场景呢？

• 基于Kafka，构造实时流数据管道，让系统或应用之间可靠地获取数据
• 构建实时流式应用程序，处理流数据或基于数据做出反应

三个很重要的概念，弄清楚Kafka的架构全靠它们：

• Topic：数据主题，是Kafka中用来代表一个数据流的一个抽象。Kafka是一个消息系统，当我们往Kafka中push一条数据的时候，首先要创建一个topic，这个topic才是真正的消息队列，它是Kafka中唯一对数据进行划分的逻辑单元（比如说这个消息是属于哪个系统的）发布消费数据时，需要producer、consumer指定相应的topic。一个topic同时可有多个producer、consumer
• Partition：Kafka在底层把topic做了分片处理，每个分片就叫一个partition，每个partition是一个有序的、不可变的record序列，partition中的record会被分配一个自增长的id，我们称之为offset，注意—>单凭offset不能唯一确定Kafka中的数据，还需要知道是哪个partition
• Record：每一个record都存有key、value、timestamp三个信息，多个record就构成了record序列，partition里面就是record序列。或许你会想，record中的key和map中的key是不是有异曲同工之妙？其实不然，record中的key是控制数据进入到哪一个partition的。Kafka在topic级别数据是没有顺序的，保证数据有序一个方法就是让partition为1，其二就是通过key来控制，比如，我想把交易数据放到同一个topic中，那么我们可以让交易数据拥有相同的key，这时相同key的值会被放到同一个partition中，这样就能保证交易数据的顺序
• Replication：每个partition还会被复制到其他服务器中作为replication，这是一种冗余备份策略，防止出现由于某个服务器宕机造成数据丢失的问题，提高数据的可用性。下面是partition在3台服务器上的分布示意图

  

   

同一个partition的多个replication不允许在同一个broker上；
每个partition的replication中有一个leader，零或多个follower（红框为leader）；
leader处理此分区的所有的读写请求，follower仅仅被动的复制数据；
leader宕机后，会从follower中选举出新的leader。

02、四个核心API

Producer：允许一个应用程序发布一串流式的数据到一个或多个Kafka topic
Consumer：允许一个应用程序订阅一个或多个topic，并对发布给他们的流式数据进行处理
Streams：允许应用程序作为一个流处理器，消费一个或多个topic产生的输入流，然后生产一个输出流到一个或多个topic中去，在输入输出流中进行有效的转换
Connector：允许构建并运行可重用的生产者或消费者，将Kafka topics连接到已存在的应用程序或者数据系统。比如，连接到一个关系型数据库，捕捉表的所有变更记录

Kafka API - Producer：

• Producer会为每个partition维护一个缓冲，用来记录还没有发送的数据，每个缓冲区大小用batch.size指定，默认值为16K
• linger.ms为，buffer中的数据在达到batch.size前，需要等待的时间
• acks用来配置请求成功的标准，有三个配置值0、1、all，0代表客户端push数据到topic即代表成功，1代表push到topic的leader中即代表成功，all代表不仅push到topic的leader中，还要复制到follower中才代表成功。其实acks的三种配置都有可能造成数据的丢失，设置为0时有可能发送完数据服务端挂掉了，设置为1时有可能push到leader后复制到follower失败了，此时若leader挂掉了再选举这个follower为leader就会存在数据的丢失，设置为all时若replication-factor为1并且leader挂掉了，此时也会存在数据丢失，因为没有做备份

流程：当调用producer.send(record)方法时，这个record会先被放到producer中buffer池的某个buffer中，而后send方法马上返回（异步操作保证吞吐量），producer的Back ground I/O thread负责把buffer中的数据发送到topic中去。
Kafka API - Consumer：

Simple Consumer：位于kafka.javaapi.consumer包中，不提供负载均衡、容错的特性，每次获取数据都要指定topic、partition、offset、fetchSize
High-level Consumer：该客户端透明的处理kafka broker异常，透明的切换consumer的partition，通过和broker交互来实现consumer group级别的负载均衡

重点分析下High-level Consumer:

 

• 使用该API直接指定topic即可消费，因为它可以透明的切换consumer的partition，topic中的partition都能够被消费；
• 如果有多个consumer该怎么消费呢？如上图，现在有四个partition，由于C1和C2有相同的group id，所以它们被放在Consumer Group A中，类似的C3、C4、C5、C6被放在了Consumer Group B中，这两个Group会平均的消费这四个partition；
• 切记，一个Group中的进程数不能大于partition，否则就会存在多余的进程被饿死的问题，当然可以少，但这样会不均衡，最好的方式就是partition能够整除一个Group中的进程数；
• 如果Group中的其中一个consumer挂掉了或者又增加了partition，此时partition会重新分配到各个Group中去，也就是说Group中的成员是动态维护的；
• 一般同一个topic会有多个Group，可这有什么好处呢？我们知道传统的MQ有队列和广播两种方式，但会有缺陷，无法同时进行水平拓展和多消费，而Kafka通过Group的方式就可以；
• 一个consumer是如何退出Group的呢？有两个维度可以判断，一是consumer去服务端用poll拉取数据，consumer实例底层会维护一个heartbeat心跳，一旦这个心跳停止，服务端在经过一段时间没有接收到心跳就会认为这个consumer挂掉了；二是去循环调用poll方法，如果这个consumer长期的发送心跳却没有消费数据，就表示有锁的发生（也不一定哦，如果拿到消息后处理的时间比较久呢？我们可以开启一个异步线程对拿到的消息单独处理，记住这里需要把auto commit offset关闭，消息处理完后手动提交），这两种情况最终都会把consumer从这个Group中剔除，然后partition重新进行分配。