Kafka 学习笔记（一） ：为何须要 Kafka？

本文由 GodPan 发表在 ScalaCool 团队博客。

咱们在学习一个东西的时候，每每只有真正了解它背后的含义，才能一步一步的掌握它，直到指挥若定。对于Kafka来讲，我也是一个小白，本篇文章我就以一个小白的角度来初探一下Kafka，本篇文章基于官方文档，顺便说一句官方文档真的很重要，且读且珍惜。

背景

Kafka最先是由LinkedIn公司开发的，做为其自身业务消息处理的基础，后LinkedIn公司将Kafka捐赠给Apache，如今已经成为Apache的一个顶级项目了，Kafka做为一个高吞吐的分布式的消息系统，目前已经被不少公司应用在实际的业务中了，而且与许多数据处理框架相结合，好比Hadoop，Spark等。

消息系统

在实际的业务需求中，咱们须要处理各类各样的消息，好比Page View,日志，请求等，那么一个好的消息系统应该拥有哪些功能呢？

• 拥有消息发布和订阅的功能，相似于消息队列或者企业消息传送系统；
• 能存储消息流，并具有容错性；
• 可以实时的处理消息；

以上3点是做为一个好的消息系统的最基本的能力。

那么Kafka为何会诞生呢？

其实在咱们工做中，相信有不少也接触过消息队列，甚至本身也写过简单的消息系统，它最基本应该拥有发布/订阅的功能，以下图所示：

其中消费者A与消费者B都订阅了消息源A和消息源B，这种模式很简单，可是相对来讲也有弊端，好比如下两点：

• 该模式下消费者须要实时去处理消息，由于这里消息源和消费者都不会维护一个消息队列（维护代价太大），这将会致使消费者如果暂时没有能力消费，则消息会丢失，固然也就不能得到历史的消息；
• 消息源须要维护本来不属于它的工做，好比维护订阅者（消费者）的信息，向多个消费者发送消息，亦或者有些还须要处理消息反馈，这是本来纯粹的消息源就会变得愈来愈复杂；

固然这些问题都是能够改进的，好比咱们能够在消息源和消费者中间增长一个消息队列，以下图所示：

从图中咱们能够看出，如今消息源只须要将消息发送到消息队列中就行，至于其余就将给消息队列去完成，咱们能够在消息队列持久化消息，主动推消息给已经订阅了该消息队列的消费者，那么这种模式还有什么缺点吗？

答案是有，上图只是两个消息队列，咱们维护起来并不困难，可是若是有成百上千个呢？那不得gg，其实咱们能够发现，消息队列的功能都很相似，无非就是持久化消息，推送消息，给出反馈等功能，结构也很是相似，主要是消息内容，固然若是要通用化，消息结构也要尽量通用化，与具体平台具体语言无关，好比用JSON格式等，全部咱们能够演变出如下的消息系统：

这个方式看起来只是把上面的队列合并到了一块儿，其实并不那么简单，由于这个消息队列集合要具有如下几个功能：

• 能统一管理全部的消息队列，不是特殊需求不须要开发者本身去维护；
• 高效率的存储消息；
• 消费者能快速的找到想要消费的消息；

固然这些只是最基本的功能，还有好比多节点容错，数据备份等，一个好的消息系统须要处理的东西很是多，很庆幸，Kafka帮咱们作到了。

Kafka

在具体了解Kafka的细节前，咱们先来看一下它的一些基本概念：

• Kafka是运行在一个集群上，因此它能够拥有一个或多个服务节点；
• Kafka集群将消息存储在特定的文件中，对外表现为Topics；
• 每条消息记录都包含一个key,消息内容以及时间戳；

从上面几点咱们大体能够推测Kafka是一个分布式的消息存储系统，那么它就仅仅这么点功能吗，咱们继续看下面。

Kafka为了拥有更强大的功能，提供了四大核心接口：

• Producer API容许了应用能够向Kafka中的topics发布消息；
• Consumer API容许了应用能够订阅Kafka中的topics,并消费消息；
• Streams API容许应用能够做为消息流的处理者，好比能够从topicA中消费消息，处理的结果发布到topicB中；
• Connector API提供Kafka与现有的应用或系统适配功能，好比与数据库链接器能够捕获表结构的变化；

它们与Kafka集群的关系能够用下图表示：

在了解了Kafka的一些基本概念后，咱们具体来看看它的一些组成部分。

Topics

顾名思义Topics是一些主题的集合，更通俗的说Topic就像一个消息队列，生产者能够向其写入消息，消费者能够从中读取消息，一个Topic支持多个生产者或消费者同时订阅它，因此其扩展性很好。Topic又能够由一个或多个partition（分区）组成，好比下图：

其中每一个partition中的消息是有序的，但相互之间的顺序就不能保证了，若Topic有多个partition，生产者的消息能够指定或者由系统根据算法分配到指定分区，若你须要全部消息都是有序的，那么你最好只用一个分区。另外partition支持消息位移读取，消息位移有消费者自身管理，好比下图：

由上图能够看出，不一样消费者对同一分区的消息读取互不干扰，消费者能够经过设置消息位移（offset）来控制本身想要获取的数据，好比能够从头读取，最新数据读取，重读读取等功能。

关于Topic的分区策略以及与消费者间平衡后续文章会继续深刻讲解。

Distribution

上文说到过，Kafka是一个分布式的消息系统，因此当咱们配置了多个Kafka Server节点后，它就拥有分布式的能力，好比容错等，partition会被分布在各个Server节点上，同时它们中间又有一个leader，它会处理全部的读写请求，其余followers会复制leader上的数据信息，一旦当leader由于某些故障而没法提供服务后，就会有一个follower被推举出来成为新的leader来处理这些请求。

Geo-Replication

异地备份是做为主流分布式系统的基础功能，用于集群中数据的备份和恢复，Kafka利用MirrorMaker来实现这个功能，用户只需简单的进行相应配置便可。

Producers

Producers做为消息的生产者，能够本身指定将消息发布到订阅Topic中的指定分区，策略能够本身指定，好比语义或者结构相似的消息发布在同一分区，固然也能够由系统循环发布在每个分区上。

Consumers

Consumers是一群消费者的集合，能够称之为消费者组，是一种更高层次的的抽象，向Topic订阅消费消息的单位是Consumers，固然它其中也能够只有一个消费者（consumer）。下面是关于consumer的两条原则：

• 假如全部消费者都在同一个消费者组中，那么它们将协同消费订阅Topic的部分消息（根据分区与消费者的数量分配），保存负载平衡；
• 假如全部消费者都在不一样的消费者组中，而且订阅了同个Topic，那么它们将能够消费Topic的全部消息；

下面是一个简单的例子，帮助你们理解：

上图中有两个Server节点，有一个Topic被分为四个分区（P0-P4)分别被分配在两个节点上，另外还有两个消费者组（GA，GB），其中GA有两个消费者实例，GB有四个消费者实例。

从图中咱们能够看出，首先订阅Topic的单位是消费者组，另外咱们发现Topic中的消息根据必定规则将消息推送给具体消费者，主要原则以下：

• 若消费者数小于partition数，且消费者数为一个，那么它就消费全部消息；
• 若消费者数小于partition数，假设消费者数为N，partition数为M，那么每一个消费者能消费的分区数为M/N或M/N+1；
• 若消费者数等于partition数，那么每一个消费者都会均等分配到一个分区的消息；
• 若消费者数大于partition数，则将会出现部分消费者得不到消息分区，出现空闲的状况；

总的来讲，Kafka会根据消费者组的状况均衡分配消息，好比有消息着实例宕机，亦或者有新的消费者加入等状况。

Guarantees

kafka做为一个高水准的系统，提供了如下的保证：

• 消息的添加是有序的，生产者越早向订阅的Topic发送的消息，会更早的被添加到Topic中，固然它们可能被分配到不一样的分区；
• 消费者在消费Topic分区中的消息时是有序的；
• 对于有N个复制节点的Topic，系统能够最多容忍N-1个节点发生故障，而不丢失任何提交给该Topic的消息丢失；

相关这些点的细节，我准备再后续文章中再慢慢深刻。

Kafka as a Messaging System

说了这么多，前面也讲了消息系统的演变过程，那么Kafka相比其余的消息系统优点具体在哪里？ 传统的消息系统模型主要有两种：消息队列和发布/订阅。

1.消息队列

特性	描述
表现形式	一组消费者从消息队列中获取消息，消息会被推送给组中的某一个消费者
优点	水平扩展，能够将消息数据分开处理
劣势	消息队列不是多用户的，当一条消息记录被一个进程读取后，消息便会丢失

2.发布/订阅

特性	描述
表现形式	消息会广播发送给全部消费者
优点	能够多进程共享消息
劣势	每一个消费者都会得到全部消息，没法经过添加消费进程提升处理效率

从上面两个表中能够看出两种传统的消息系统模型的优缺点，因此Kafka在前人的肩膀上进行了优化，吸取他们的优势，主要体如今如下两方面：

• 经过Topic方式来达到消息队列的功能
• 经过消费者组这种方式来达到发布/订阅的功能

Kafka经过结合这两点（这两点的具体描述查看上面章节），完美的解决了它们二者模式的缺点。

Kafka as a Storage System

存储消息也是消息系统的一大功能，Kafka相对普通的消息队列存储来讲，它的表现实在好的太多，首先Kafka支持写入确认，保证消息写入的正确性和连续性，同时Kafka还会对写入磁盘的数据进行复制备份，来实现容错，另外Kafka对磁盘的使用结构是一致的，就说说无论你的服务器目前磁盘存储的消息数据有多少，它添加消息数据的效率是相同的。

Kafka的存储机制很好的支持消费者能够随意控制自身所须要读取的数据，在不少时候你也能够将Kafka做为一个高性能，低延迟的分布式文件系统。

Kafka for Stream Processing

Kafka做为一个完美主义表明者，光有普通的读写，存储等功能是不够的，它还提供了实时处理消息流的接口。

不少时候原始的数据并非咱们想要的，咱们想要的是通过处理后的数据结果，好比经过一天的搜索数据得出当天的搜索热点等，你能够利用Streams API来实现本身想要的功能，好比从输入Topic中获取数据，而后再发布到具体的输出Topic中。

Kafka的流处理能够解决诸如处理无序数据、数据的复杂转换等问题。

总结

消息传递、存储、流处理这么功能单一来看确实很普通，但如何把它们完美的结合到一块儿，就是一种优雅的体现，Kafka作到了这一点。

相比HDFS分布式文件存储系统，虽然它能支持高效存储而且批处理数据，可是它只支持处理过去的历史数据。

相比普通的消息系统来讲，虽然能处理如今至将来的数据，可是它并不没有存储历史的数据。

Kafka集众家之所长，使整个系统能兼顾各方面的需求，能够用一个词来讲： “完美”！

本文从消息系统的演变讲起，到Kafka的具体组成，最后到Kafka的三大特性，旨在帮助你们可以大概的了解Kafka是什么的，到底有什么做用，固然这只是一个小白的简单理解，若有写得不对的地方，但愿你们可以指出，不胜感激。