卡夫卡长大了--写在Kafka1.0.0发布之际

在第七个年头，Kafka正式迎来了1.0.0的版本。这是Kafka作为一个开源软件成熟的标志性时刻。本文就聊一聊Kafka这个开源软件。

Kafka于2011年底被LinkedIn开源，之后经过大约一年的时间在Apache的孵化器里孵化，在2012年底正式成为了Apache的顶级项目。Kafka在整个Apache的开源生态系统里面有着举足轻重的作用。主要原因是这个产品的独特性和不可替代性。

2014年的时候，Kafka团队的主创人员 Jay Kreps， Neha Narkhede和Jun Rao决定离开LinkedIn，创办Confluent公司。Confluent是为Kafka的商业化而创立的公司。

以上就是一些比较简单的历史了。

要理解Kafka是做什么的，我们要先从数据库系统的Log讲起。Jay Kreps作为Kafka的主创人员，曾经在不同的场合多次阐述他对Log的理解。这里我用最简单的方式结合我个人在这个领域的理解陈述一下他的观点。

Log诞生于数据库系统。最初的主要目的是为了故障恢复。通常来说，在对数据库进行任何的数据操作之前，系统会先在磁盘上写下log。一条log记录包含时间戳和这个log做了什么。当故障发生的时候，这个log就可以用来进行回放，从而进行故障恢复。

数据库系统的开发厂商很快的就发现了log的一个特性：如果我们从同样的基准开始，在两个不同的数据库上以同样的顺序回放log，那么最终的状态也是一样的。当分布式数据库出现，需要主从备份数据实时复制的时候，这个特性就被充分的利用了。现在市面上几乎所有的数据库的数据复制，其基本原来就是从主到从传递log，而后从数据库按顺序回放log。

Jay很快的预见到了Log的作用，可以用来扩展到数据交换。简单来说，Kafka可以认为是一个消息队列。这里有消息的发布者和订阅者。发布的消息是log。这样一来Kafka就可以很顺利的实现在不同数据源之间进行数据复制。

如果我们再推广一点，接到log以后也不一定非要写数据，而是可以直接对这些数据进行处理，这就是流处理引擎的由来。

Kafka的最初想法就是使用log通过一个消息队列来进行数据复制。这在LinkedIn里面被广泛使用，然后又开源出来了。Kafka这些年的发展，使得它从一个简单的数据复制的消息队列到了一个非常复杂的分布式流处理平台。

在Kafka发展过程中，有一些非常重要的功能，跨数据中心的复制功能，无限量的消息存储，方便连接各个数据源和外部存储系统的Connect API，以及流处理能力的Streams API。此外今年8月还推出了KSQL，一个Kafka上的streaming SQL语言。

我们可以看到的是Kafka越来的越像是一个功能齐全的数据处理系统。那么随着Kafka的发展，迟早会从和其他的数据处理引擎互补上升到互相竞争的关系。接下来到底会怎么样我也不好说了。

严格意义上来讲，在云上，Kafka比较大的竞争对手应该是亚马逊AWS的Kinesis服务。在云下，目前应该还没有比Kafka更好的在不同数据源之间进行数据复制的系统。

Confluent为了Kafka的发展做了很多工作。他们增加了对不同语言的支持，对不同数据源的支持，以及在Kafka在企业级应用的稳定性等方面的特性开发。Confluent最大的附加价值是它们开发的一个非开源的Kafka控制中心，用于对Kafka集群的管理和性能监控。具体效果怎么样我也不知道，毕竟我没有花钱买过这个服务。

总体来说，我觉得Kafka这个产品是Apache的生态圈里非常有特色的产品。它已经很成功，并且还会更加的成功。值此Kafka1.0之际，我也写篇文章表达一下对这个开源产品的敬意。

飞总聊IT

IT八卦，大数据风云，职场风波

长按二维码订阅

合作垂询：feizongitworld@gmail.com