Kafka学习之旅(一):初识Kafka

一. 概述

作为大数据从业的程序猿GG, 相信许多人和我一样都接触,使用过Kafka. 之前由于个人原因仅仅只是使用了一些API, 并没有深入了解。 现在刚好有机会正好想系统的学习一下。于是开一个主题来记录自己的学习历程。
首先Kafka是什么呢，我看到许多国内的资料将它解释为消息队列或者是消息中间件。不过个人觉得消息引擎系统更加的适合它一些。因为消息队列给出了一个很不明确的暗示，仿佛Kafka是利用队列的方式构建的；而消息中间件的提法有些有些太笼统了不容易明白这个这个中间件是干什么。
那为什么要加引擎两个字呢，因为Kafka 不仅可以做为消息系统还可以还具备能量转换传输能力就像引擎一样。
那这类系统主要是做什么的呢，根据维基百科定义，消息引擎系统是一组规范，企业利用这组规范在不同的系统之间传递语义准确的消息，实现松耦合异步式数据传递。这个好像有点飘飘的不知道在说什么。
下面给个通俗易懂的好了
系统A发送消息给消息引擎系统，系统B从消息引擎系统中读取数据（这个数据可以是A直接生产的或者是在消息引擎系统转化过的）。

二：Kafka术语

(1)消息：Record。Kafka 是消息引擎嘛，这里的消息就是指 Kafka 处理的主要对象。
(2)主题：Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。
(3)分区：Partition。一个有序不变的消息序列。每个主题下可以有多个分区。
(4)消息位移：Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值。
(5)副本：Replica。Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和追随者副本，各自有不同的角色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。
(6)生产者：Producer。向主题发布新消息的应用程序。
(7)消费者：Consumer。从主题订阅新消息的应用程序。
(8)消费者位移：Consumer Offset。表征消费者消费进度，每个消费者都有自己的消费者位移。
(9)消费者组：Consumer Group。多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。
(10)重平衡：Rebalance。消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。

三. Kafka 传输设计

既然消息引擎系统用于不同系统直接的数据传递，那么如何设计待传输的格式从来都是一等一的大事，试问一条消息如何做到信息表达业务语义而无歧义，同事还要最大限度提供重用性和通用性？那么如何来设计传输格式呢一种比较容易想到的办法就是一些现成的格式如CSV,json,parquet 等等。那么Kafka 是怎么做的呢。他其实使用的是纯二级制的字节序列。当然消息还是结构化的，只是在使用之前都要将它转换成二进制的字节序列。
对于消息引擎系统还要设计具体的传输协议。
常用的有如下：

  点对点传输：也叫消息队列模型，系统A发布的消息之只能系统B接收 其他的系统都不能接收 ， 
  例如日常生活中电话客服就是这种模型同一个客户呼入的电话只能同事被一个客服处理，
  第二个客服不能为他服务。
  消息发布/订阅：于上面不一样的是，他有一个topic 的概念。 该模型也有发送方和接收方。
  和点对点不同的是这个模型可能存在多个发布者向相同的主题发布消息而订阅者也可能存在多个，
  他们都能接收相同的主题的消息。例如报纸等等

比较酷的是Kafka 同时支持这两种后面会分享。

四：作用

那为什么要花这么大的精力去设计这样一个消息引擎系统，干嘛不系统A直接发送给B 呢中间数据还要走消息引擎转一圈。
答案是削峰填谷。看起来逼格很高的样子的。所谓的削峰填谷其实指的是缓冲上下游瞬时突发流量使其更加平滑。特别是一些上游发送能力很强的系统（例如秒杀系统）或者是一些特殊的时刻（例如双十一）如果没有很好的保护，一些下游系统可能会发生全链路雪崩。但是有了消息引擎做中转就能对上游的流量冲击有了一定的抵抗能力。能做到将上游的峰填到谷中。避免流量的震荡。另一大好处就是在于发送方和接收方的松耦合，也一定程度的较少了应用的开发。减少系统不必要的交互。

五：Kafka 不仅仅是消息引擎系统

Kafka 在设计之初就旨在提供三个方面的特性:
(1)提供一套 API 实现生产者和消费者；
(2)降低网络传输和磁盘存储开销；
(3)实现高伸缩性架构。

开源之后的 Kafka 被越来越多的公司应用到它们企业内部的数据管道中，特别是在大数据工程领域，Kafka 在承接上下游、串联数据流管道方面发挥了重要的作用：所有的数据几乎都要从一个系统流入 Kafka 然后再流向下游的另一个系统中。这样的使用方式屡见不鲜以至于引发了 Kafka 社区的思考：与其我把数据从一个系统传递到下一个系统中做处理，我为何不自己实现一套流处理框架呢？基于这个考量，Kafka 社区于 0.10.0.0 版本正式推出了流处理组件 Kafka Streams，也正是从这个版本开始，Kafka 正式“变身”为分布式的流处理平台，而不仅仅是消息引擎系统了。今天 Apache Kafka 是和 Apache Storm、Apache Spark 和 Apache Flink 同等级的实时流处理平台。
但是基于我的了解,目前真正使用Kafka stream 构建流处理平台的公司并不多,是否能取代Spark,flink,Storm…去架构流处理计算平台还有待考究。不过Kafka好像也没有打算这样去做。官网上明确标识 Kafka Streams 是一个用于搭建实时流处理的客户端库而非是一个完整的功能系统。这就是说，你不能期望着 Kafka 提供类似于集群调度、弹性部署等开箱即用的运维特性，你需要自己选择适合的工具或系统来帮助 Kafka 流处理应用实现这些功能。
但我们也欣喜地看到，随着在 Kafka 峰会上各路大神们的鼎力宣传，如今利用 Kafka 构建流处理平台的案例层出不穷，而了解并有意愿使用 Kafka Streams 的厂商也是越来越多，因此我个人对于 Kafka 流处理平台的前景也是非常乐观的。