kafka技术分享02--------kafka入门

kafka技术分享02--------kafka入门

1. 消息系统

​ 所谓的Messaging System就是一组规范，企业利用这组规范在不一样的系统之间传递语义准确对的消息，实现松耦合的异步数据传输。简单理解为系统A将消息发送给Messaging System，系统B从Messaging System中获取系统A发送的消息。消息系统主要做用能够归纳为四个字：削峰填谷。经过消息系统能够对抗这种上下游消息系统TPS的错配以及瞬时峰值流量。

补充一点：

一般来讲，两个进程进行数据流交互的方式通常有三种：

1. 经过数据库：进程1写入数据库；进程2读取数据库

2. 经过服务调用：好比REST或RPC，而HTTP协议一般就做为REST方式的底层通信协议

3. 经过消息传递的方式：进程1发送消息给名为broker的中间件，而后进程2从该broker中读取消息。消息传输协议属于这种模式

所以，Messageing System必须保证消息的传输格式的语义正确解析无歧义，另外还要对如何传输消息进行设计。对于第一点Kafka使用的是纯二进制的字节序列，对于第二点消息的传输方式大概有两种：

• 点对点模式：系统A发送的消息只能被系统B所接受，其余任何系统不能读取系统A发送的消息

• 发布（publish）/订阅（suscribe）模式：能够存在多个消息发布者往同一topic中发送数据，同时能够存在多个消费者对统一topic的数据进行消费。

kafka同时支持者两种消息传输模式。

2.kafka是什么

Kafka既是一个开源的分布式消息系统，又是一个分布式流平台。

kafka在设计之初旨在提供三个方面的特性：

• 提供一套API实现生产者消费者；

• 下降网络传输和磁盘存储开销

• 实现高伸缩性架构

从以上三点能够看出，kafka的设计之初的目的实际上是做为一个消息系统，主要做用是承接上下游、串联数据流管道。直到kafka0.10.0.0版本正式推出了流处理组件Kafka Streams，Kafka正式变身为流处理平台。那么kafka streams和其余大数据流处理框架相比的优点主要表如今：

• 更容易实现端到端的正确性。实现正确性的基石是要求框架可以提供精确一次性处理语义，即处理一条消息有且只有一次影响系统的状态。目前主流的大数据流处理框架都宣称实现了精确一次处理语义，可是有条件的，只能实现框架内的精确一次处理语义，没法实现端到端的精确一次处理语义。而kafka streams的数据流转和计算都在kafka内部，所以可以实现端到端的精确一次处理语义。

• 他本身对于流式计算的定位。官网上明确标识Kafka Streams是一个搭建实时流处理的客户端库，而非一个完整的功能系统。所以kafka不提供相似于集群调度和弹性部署等开箱即用的运维特性，须要本身选择合适的工具和系统来帮助kafka流处理应用实现此类功能。kafka Streams的定位是中小型公司，数据量没有那么大，使用大数据流处理框架有点浪费。

3. kafka的种类

• Apache Kafka。

  Apache Kafka是社区版kafka。它的优点在于毫无疑问它是开发人数最多、版本迭代最快的Kafka。他的劣势在于仅仅提供了最基础的组件，对于Kafka Connect，仅仅提供了一种链接器即读写磁盘文件的链接器，而没有于其余系统交互的链接器。另外，Apache Kafka也没有提供任何监控的框架和工具。须要借助于第三方框架（Kafka Manager、kafka eagle、JMXTrans + InfluxDB + Grafana）

• Confluent Kafka

  Confluent公司基于Apache Kafka建立的商业版Kafka

 

         

 

• CDH/HDP Kafka

  Cloudera提供的CDH和HortonWorkers提供的HDP是著名的大数据平台，里边集成了目前主流的大数据处理框架，可以帮助用户实现从分布式存储、集群调度、流处理到机器学习、实时数据库等方面的数据处理。CDH和HDP都集成了Apache Kafka。

 

   

 

     补充kafka的性能监测工具：

     Kafka本身提供了kafka-producer-perf-test和kafka-consumer-perf-test脚本能够作producer和consumer的性能测试。另外LinkedIn开源了一款名为kafka-monitor的端到端系统测试工具，也能够用来测试Kafka集群end-to-end的性能。有些遗憾的是这个工具几乎没什么人维护了。

4. kafka术语

kafka属于分布式消息系统，它的主要功能室提供一套完备的消息发布订阅的解决方案，实现不一样系统之间的消息传递。kafka中发布订阅的对象就是topic，能够将topic理解为某一类消息的一个标识。

客户端：向主题发布消息的客户端应用程序就称为生产者（Producer），订阅主题的客户端应用程序称之为消费者（Consumer）。生产者、主题和消费者的数量关系不固定，一个生产者能够不断的向一个或多个主题发送消息，一个消费者能够订阅一个或多个主题。

服务端：kafka的服务端由被称为Broker的服务进程组成，给一个kafka集群由多个broker进程组成。Broker主要负责接收和处理客户端的请求，以及对消息进行持久化。虽然一台主机能够运行多个Broker进程，但更为常见的作法是将Broker运行在不一样的主机上，实现容灾与高可用。

另一个实现高可用的方式是副本机制（Replication）。副本机制的基本思想就是将相同的数据拷贝到不一样的机器上。kafka定义了两类副本：Leader Replia和Follower Replia。Leader主要是接收处理客户端的请求，Follower主要同步Leader的数据，不能与外界进行交互。

简单一句话就生产者老是想leader发送数据，而消费者老是从leader消费数据。follower就作一件事，请求leader将最新的消息发动给它。Kafka不能推送消息给consumer。Consumer只能不断地轮训去获取消息。从Kafka流向consumer的惟一方式就是经过poll。另外维持一个长链接去轮训的开销一般也没有你想的那么大，特别是Kafka用的是Linux上的epoll，性能还不错，至少比select好。

分区中的全部副本统称为AR（assigned Replica），很所时候follower副本中的消息相对于leader而言会有必定的滞后，这个滞后范围是能够经过参数进行配置的。全部与leader保持必定程度同步（并不必定是彻底同步）的副本组成ISR（In-Sync Replica），剩余部分为OSR。因此AR=ISR+OSR。

leader副本负责维护和跟踪全部follower副本的滞后状态，当follower副本滞后太多或失效时，leader副本会将它从ISR中剔除，若是OSR中有follower副本追上leader副本，leader副本会将它从OSR迁移至ISR。默认状况下（可经过参数进行改变），leader副本发生故障，只有ISR集合中的副本才有资格参与leader的选举。

副本机制保证了数据的不丢失，提高容灾能力，但没法解决伸缩性问题（Scalability）。所谓的额伸缩性能够这样理解。假若一个leader积累了足够多的数据，致使单台Broker没法容纳。Kafka的解决方式就是Partition机制，将一个topic的数据划分为多个分区，分区是有序的，编号从0开始，生产者生产的某一条数据只会发送到某一个分区，每一条消息在分区上的位置成为Offset。其实副本机制是创建在分区机制之上的，一个topic向的全部分区都有一个leader和多个folllower。分区在存储层能够被看作是一个可追加的日志文件，消息在追加到分区日志文件时，会分配一个特定的偏移量。每一条消息发送到broker以前都会根据分区规则选择存储到那个具体分区。分区的数量能够在出题建立的时候指定，也能够在建立主题完以后进行修改实现水平扩展。

消费者组：多个消费者共同组成一个组来消费一组主题。这个主题的某一个分区只会被消费者的某个特定分区所消费，其余消费者实例不能进行消费。之因此引入消费者组，更多的是由于多个消费者同时消费能够提升消费端的TPS。另外这里的消费者实例能够是运行消费者的应用进程，也能够是一个线程。消费者组内的消费者除了瓜分主题消息的功能，还能够互相协做，当某个消费者挂掉，kafka可以自动检测掉，进行分区的重平衡(Rebalance )。另外每个消费者在消费过程当中必然会记录消费到了分区那个位置，成为消费者偏移量（Consumer Offset）

一张图简单归纳一下：

kafka的Broker是如何对消息进行持久化的？

kafka使用消息日志（Log）来保存数据，一个日志就是磁盘上一个只支持追加（Append Only）的物理文件，用顺序IO代替随机IO，是kafka实现高吞吐的一个重要手段。不过若是不停地向统一日志文件追加数据，总会耗尽全部磁盘空间，所以kafka必然会按期的删除消息，回收磁盘。kafka是经过日志段（Log Segment）机制进行磁盘回收的。在kafka的底层一个日志又进一步分红多个日志段，消息被追加到当前最新的日志段中，当写满一个日志段后，kafka会自动切分出一个新的日志段，并将老的日志段封存起来。kafka在后台会有定时认为会按期的检查老的日志段是够可以被删除，从而实现磁盘回收的目的。

 

请思考一下为何 Kafka 不像 MySQL 那样容许Follower对外提供服务，支持主从读写分离？

主从读写分离主要目的就是缓解leader节点的压力，将读请求负载到多个follower上，提高读操做的性能。这种设计只是一种架构，无优劣之说，只是有本身的适用场景而已，一般适用于读多写少的场景。而对于kafka而言，它是一个消息系统而不是以存储的方式对外提供读服务，一般会涉及到频繁的生产数据和消费数据，并不符合读多写少的应用场景。若是Kafka的分区相对均匀地分散到各个broker上，一样能够达到负载均衡的效果，不必刻意实现主写从读增长代码实现的复杂程度。

kafka的副本机制采用的是异步消息拉取，所以存在leader和follower的数据一致性问题，若是要实现读写分离，必需要处理好副本lag致使的数据一致性问题。

 

分布式系统中replica的leader和follower之间如何复制数据保证消息的持久化的问题，我了解的是有3种模式：

1.生产者消息发过来之后，写leader成功后即告知生产者成功，而后异步的将消息同步给其余follower，这种方式效率最高，但可能丢数据；

2.同步等待全部follower都复制成功后通知生产者消息发送成功，这样不会丢数据，但效率不高；

3.折中的办法，同步等待部分follower复制成功，如1个follower复制成功再返回，这样兼顾效率和消息的持久化。

目前Kafka不支持第三种“折中”办法。。。要么只写leader，要么全部follower所有同步。可是，我赞成不少分布式系统是能够配置同步follower和异步follower共存的，好比一个同步follower+N-1个异步follower的伪同步。Facebook的MySQL就是这个原理。

5.Kafka的版本号

从官网下载kafka时，会出现以下两种状况。可是不管是哪一种状况，Kafka-2.11-2.2.1，其中2.11指的是scala编译器的版本。2.2.1才是kafka的版本。Kafka版本经历了由四位表示到三位表示的转变，1.0.0版本以前采起四位，以后采用3位，不管是四位仍是三位，kafka版本构成都是：大版本号（Major version）-小版本号（Minor Version）-修订版本号（Patch）。

Kafka的大版本共经历了从0.七、0.八、0.九、0.十、0.十一、1.0、2.0七个版本的演变。

• 0.7 。这个版本仅仅提供了最基础的消息队列的功能，副本机制都没有。
• 0.8 。0.8正式引入了副本机制，至此kafka成为一个真正意义上完备的分布式高可靠的消息队列解决方案。生产者和消费者使用的仍是老版本的API，即当你开发生产者和消费者时，你须要指定的zookeeper的地址而不是Broker的地址。

 

        

• 0.9版本的主要功能改进包括：增长了基础的安全认证和权限功能；用java重写了新版本消费者API；引入了kafka connect组件用于实现高性能的数据抽取；新版本的producer API算基本稳定。可是0.9版本的新版Consumer APIBug超多。
• 0.10.0.0这个版本是个里程碑式的版本，它引入了Kafka Streams，至此kafka变身为一个分布式流处理平台。

        

• 0.11.0.0提供了两个新的功能：提供了幂等性的Producer API和事务API，另外一个是对kafka的消息格式进行了重构。

       

• 1.0和2.0两个版本的更新主要体如今Kafka Streams上，并且两个版本的API变化挺大。