[聚合文章] kafka 迈进了光荣的 1.0

首发个人公众号  spark技术分享 ,  同步个人网站  coolplayer.net ，未经本人同意，禁止一切转载

kafka 已经走了7个年头，最初就是个消息系统，现在已经演化为了一个分布式流式平台，你可以使用kafka 干一系列的事情，比如发布订阅消息，数据仓库，流失处理，离线大规模数据处理，我之前也很奇怪， 中国那么多大的公司都在使用 kafka，那么成熟的一个大数据组件，为啥还没有发布1.0正式版本， 现在终于姗姗来迟，在官方发布1.0之际，我们来看下kafka的整个roadmap。kafka 一路走来，不断的给我们带来惊喜，支持存储无限的key-vlue 数据，极其易用的连接 api https://www.confluent.io/blog/announcing-kafka-connect-building-large-scale-low-latency-data-pipelines/, 很方便地连接外部存储（mysql，es等）， 实时处理框架 Stream API https://kafka.apache.org/documentation/streams/ ，现在也支持了exact once 语义。

1.0 发布的一些新特性

• 0.10.0 版本里开始引入的 Streams API 在 1.0.0 版本里继续演进，改进了 builder API（KIP-120），新增了用于查看运行时活跃任务的 API（KIP-130）和用于聚合分区的 cogroup API（KIP-150）。增强的 print() 和 writeAsText() 方法让调试变得更容易（KIP-160）。其他更多信息可以参考 Streams 文档。

• 改进了 Connect 的度量指标（KIP-196），新增了大量用于健康监测的度量指标（KIP-188），并提供了集群的 GloabalTopicCount 和 GlobalPartitionCount 度量指标（KIP-168）。

• 支持 Java 9，实现更快的 TLS 和 CRC32C，加快了加密速度，降低了计算开销。

• 调整了 SASL 认证模块的错误处理逻辑（KIP-152），原先的认证错误信息现在被清晰地记录到日志当中。

• 更好地支持磁盘容错（KIP-112），更优雅地处理磁盘错误，单个 JBOD 上的磁盘错误不会导致整个集群崩溃。

• 0.11.0 版本中引入的幂等性生产者需要将 max.in.flight.requests.per.connection 参数设置为 1，这对吞吐量造成了一定的限制。而在 1.0.0 版本里，这个参数最大可以被设置为 5（KAFKA-5949），极大提升了吞吐量范围。

kafka 最初的设计思想

有人肯定有疑问，为啥1.0版本等了那么长时间，并没有一个规范来规定1.0长什么样子， 其实之所以现在才到 1.0 版本，不是因为kafka还不够稳定，kafka 之所以那么牛逼闪闪就是因为稳定性， kafka 没有到1.0版本的主要原因是因为还不够完整。

2009 kafka 刚面世的时候，是考虑设计成为一个 完整的实时数据平台，但是并没有一开始就搞一个很大很全的东西，而是找一个突破口，一个用户确实存在的痛点，这个痛点就是，如果你需要实时性，就只能是一个小数据量的队列，如果你需要处理大规模数据量，就只能是批处理，而不是实时的。实时性和数据规模二者只能选其一，kafka 最初就是要解决这个问题，kafka 要建造一个一统江湖的 实时数据平台，可以让你所有的app都跑在上面。

kafka 的转变之路

kafka 开始大踏步的往前走，开始构建整个实时数据平台，一个流式的大数据平台，既要实时性，也要大规模数据， 一步一步的转变开发者的思想，原来还可以这样设计流式系统， 一个流式的数据中心，也可以叫做数据仓库，连接各种不同的外部数据源，实时流入数据到这个数据中心，刚开始这种想法有点不可思议。但是kafka用实际行动证明是可行的，大家慢慢开始用 kafka 来建设一个流式数据中心。

开始的时候kafka想着可以一步到位，实现流式存储，流式处理，但是发现这个目标有点太大，还是先解决存的问题吧，先会爬，才能跑。

第一步：  持续的日志流

要想实现伟大的目标，要先有一个持续的日志流，然后可以在全公司推广 pub-sub APIs。  虽然有一些反对，但是后面看来这个抽象对设计大规模pub-sub消息系统是极其正确的。这种API 的正确使用姿势就是， 发布者append到日志流上，整个日志流是有序的，订阅者持续地进行消费，每次记录一个消费的位置 offset，下次接着这个位置继续消费

第二步，一个多副本，高容错的数据流

下面，就要打造一个高容错的kafka， 使用者一般都是把消息队列当成一个临时存储，消费完了就可以丢弃，而没有考虑长时间的持久存储，kafka的高明之处就是很重视长时间存储，其实流式数据的存储是很关键的，你想想，如果某个时间点你的app挂掉了，你还需要对以往数据从新消费，如果之前流式数据被你丢弃了，是不是就完蛋了。

慢慢的，大家都接受了一个关键的概念，区分清楚了什么是流，什么是表，其实很好理解，流动的数据就代表着这个世界的变化，是变化的。而一个表，代表这个世界在某个时间点的一个状态，是确定的。你可以订阅消费这些动态变化的表，你得到结果也是动态变化的。

第三步: 连接和流式处理 API

到这里，就需要一些方便易用的 连接api， 可以把数据轻松的流入到kafka，发布者把事件流打入kafka， 就不用关心是谁在消费它了， 实现了解耦，订阅者可以从kafka里面轻松的消费事件。kafka提供了一系列的插件用来把外部数据导入kafka， 和把kafka中的数据sink到外部系统。这里你可以看到所有可用的连接器，https://www.confluent.io/product/connectors/ ， 后面kafka 提供了 Stream API 可以让你轻松的消费流式数据，你可以把这个库嵌入到你的 app中，就不用关心流式系统底层的一些问题，直接消费就好了。

第四步，多样性的使用姿势  和exact-once语义

到了这里就可以做一些高级的事情了，首先是提供了 exact-once语义， 这样你就可以放心的使用kafka 而不用担心丢失数据的问题，因为对于一些关键系统，丢数据就意味着挨骂，exact-once 可以保证你得到一个完全准确的结果，

之前kafka的api实现库是java版本的，就限制了使用范围，后面kafka提供了协议级别的能力，让你不再局限于某种语言， 另外今年8月还推出了KSQL，一个Kafka上的streaming SQL语言   https://www.confluent.io/blog/ksql-open-source-streaming-sql-for-apache-kafka/， function-as-a-service  或者 其他 collection-like DSL 来消费kafka，

kafka 的生态系统

kafka 已经具备了一个生态系统的雏形， 发布订阅消息，数据仓库，流失处理，离线大规模数据处理。 kafka 花费了数十年才实现了这一目标。

欢迎关注  spark技术分享