Kafka浅谈与小结

回归到Kafka的本质，作为一个消息引擎，可以说的太多，本人文笔和姿势有限，所以，

以下只想说一说：

1.Kafka的典型应用场景

2.玩转Kafka绕不开的几个名词

3.我在摆弄Kafka的过程中，走过的坑

序言：

2016年7月的一天，面对蜂拥而至的数据对接需求以及日益上涨至海量级的数据，多少有些焦头烂额，忽然听见旁边的哥们随口说了一句，要不你试试卡夫卡？我随口回答：“《变形记》么”，不过随即反应过来便问这是什么，听他支支吾吾，看来也并非了解，便不再理会。随手翻阅一下便开始臆想：目前的数据架构在束手无策之前，总是可以修修补补的。只是大概仅仅两周过去，业务数据的飞速增长很快就让现有的架构迅速崩溃，在急速膨胀的海量数据面前，两个传统的软件技术人对新兴开源技术的嗅觉都变得迫切而敏感起来......

以上背景故事以《数据架构设计浅谈》一文为支撑。

No.1 应用场景

解耦，既为生产者作为上游只需要依赖MQ，逻辑上和物理上都不依赖其他服务。

Kafka的应用场景，本质上就是MQ（消息队列）的应用场景。

但与传统MQ相比，如RabbitMQ、ActiveMQ等（RocketMQ应该不再此列），其最大优势便是海量级的吞吐量，在互联网大数据盛行的当下，当海量级数据砸到你头上，架构中便无法不考虑Kafka。

所以，大体上说，MQ的应用场景，就是Kafka的应用场景，只不过在其诞生的背景下，可以充分利用Kafka自身的特性解决互联网背景下的各种问题。

那么，什么场景下应该使用MQ，可以总结为一下几点：

1.对于不关心下游结果的业务，可以使用MQ来解耦

2.对于关心下游结果的业务，但异步返回执行时间足够长久，依然可以使用MQ来解耦

3.定时任务的队列执行

综上，我总结为相互解耦，解放上游，削峰填谷。

No.2 绕不开的几个名词

Topic、Partition、Offset、Consumer、Producer、Replication、Leader、Broker

这8个名词，相信使用过Kafka的人会经常与之打交道。下面是具体释义：

Topic：用于划分Message的逻辑概念，一个Topic可以分布在多个Broker上。

Partition：是Kafka中横向扩展和一切并行化的基础，每个Topic都至少被切分为1个Partition。

Offset：消息在Partition中的编号，编号顺序不跨Partition。

Consumer：用于从Broker中取出/消费Message。

Producer：用于往Broker中发送/生产Message。

Replication：Kafka支持以Partition为单位对Message进行冗余备份，每个Partition都可以配置至少1个Replication(当仅1个Replication时即仅该Partition本身)。

Leader：每个Replication集合中的Partition都会选出一个唯一的Leader，所有的读写请求都由Leader处理。其他Replicas从Leader处把数据更新同步到本地，过程类似大家熟悉的MySQL中的Binlog同步。

Broker：Kafka中使用Broker来接受Producer和Consumer的请求，并把Message持久化到本地磁盘。每个Cluster当中会选举出一个Broker来担任Controller，负责处理Partition的Leader选举，协调Partition迁移等工作。

事实上要真正的理解这8个名词，还需在实验环境反复阅读文档进行测试。

如果真的要讲一讲上面的这些，光搜索出来的内容去重后就可以钉成一本书的内容，这里只说说Kafka的版本发展和Kafka的partition。

Kafka有三个比较出名的版本系列，分别是0.8x、0.9x、0.10，从诞生起，Kafka就一直依赖zookeeper，并且自身携带了一套zookeeper，zookeeper作为Kafka分布式一致性以及高可用的解决方案。这三个版本系列前后对比变化之大，不得不让人联想到互联网发展之迅速。

这其中又属0.8x与0.9x两个版本系列变化最大，可以说甚至产生了生殖隔离。

从Kafka自身结构说起，在早期0.8x版本，旧的Consumer依赖于ZooKeeper管理Consumer Group信息，并且Consumer Group消费的每个Partition的Offset信息都存放在zookeeper里，但是在0.9x版本开始，zookeeper不再作为offset的存储介质，官方默认将消费的offset存储在 Kafka 名为__consumer_offsets的Topic中。这种降低与zookeeper依赖关系的做法，我是举双手赞同的，频繁利用ZKClient的API操作Zookeeper本身效率就相对低下。

从Kafka提供的开发API说起，在0.8x版本时，Kafka提供了一套Scala的Producer和Consumer API，就不要提多难用了，high-level与low-level的两套API使用极为不爽。在0.9x版本之后，新Consumer结合了旧的low-leve和high-level API，并且新Consumer用纯Java重写，不再依赖与Scala和ZooKeeper，异常清爽。

版本变化说完，谈谈Partition：

说起partition，不得不说说consumer group，传统消息系统提供两种使用方式，分别是队列和发布-订阅，利用consumer group就可以做到这两种使用模式：

1.如果所有的Consumer都在同一个Consumer Group中，那么就实现了队列模式了；

2.如果每一个Consumer都在一个不同的Consumer Group中，那么就实现了发布-订阅模式。

由上图与上面两条可以得出以下结论：

1.同组的consumer则起到均衡效果。

2.若只定义为1个partition，只能被同组的1个consumer消费，无法并发处理。

3.当同组消费者数量多于partition的数量时，多余的消费者空闲。

上面需要注意的是，Kafka无法保证consumer从多个partition读数据的顺序性，只能保证在一个partition上数据是有序的；同组的consumer数量多于partition数量时，多余的consumer会空闲没有数据进行消费，会造成资源浪费，所以，在进行Topic设计的时候，要充分考虑后续的具体实施情况、拓展性。

No.3 走过的坑

为什么我要讲Kafka0.8x版本与0.9x版本巨大的差异甚至产生了生殖隔离，事情的起因如下，2017年初，突然接到了内部的数据对接需求，得知隔壁部门的数据接口也是Kafka，不过是两年前搭建的0.82版本，两年来各种原因疏于维护，一直无人对其升级，遂在自己的生产环境先用consumer shell命令跑一下看看数据形式，结果产生了以下问题：

1. 0.82版本与zookeeper高度依赖，无法用bootstrap-server代替，并且对方的低版本Kafka所依赖的zookeeper已经与各项业务紧密结合，很难轻易变动。

2. 新旧api功能上的缺失。

基于以上两点，在查阅相关资料后，发觉直接对接的成本风险，方方面面都有些大，遂决定采用成熟的flume进行对接，理论上只需配置好Kafka Source即可。但是，又出现了新问题：

flume1.7只支持0.9x以上版本的Kafka对接

在天真地尝试替换flume1.6的Kafka souce、channel、sink一套jar包之后，没有任何效果，最终，只有重新部署1.6版本的flume才顺利接收（这点在前文谈一谈Flume日志采集系统中有提及）。

No.4 写在最后

由于继承了磁盘顺序读写的高性能特性，Kafka天然的成为一款高吞吐量高性能的消息引擎，但在看到它突出的优势之后，不要被Kafka的在应用领域的突出优势迷惑了双眼，作为学习者、使用者，我想Kafka带来的最大作用，依然是MQ的本质：相互解耦，解放上游，削峰填谷。在当下互联网高速发展所催生的大量新技术新思想浪潮下，也要看清本质，不忘初心。