Kafka是linkedin使用Scala编写具有高水平扩展和高吞吐量的分布式消息系统。

Kafka对消息保存时根据Topic进行归类，发送消息者成为Producer，消息接受者成为Consumer，此外kafka集群有多个kafka实例组成，每个实例(server)称为broker。

无论是Kafka集群,还是producer和consumer都依赖于zookeeper来保证系统可用性，为集群保存一些meta信息。

• 主流MQ对比

Apache Kafka是消息引擎系统，也是一个分布式流处理平台（Distributed Streaming Platform）

Kafka是LinkedIn公司内部孵化的项目。LinkedIn最开始有强烈的数据强实时处理方面的需求，其内部的诸多子系统要执行多种类型的数据处理与分析，主要包括业务系统和应用程序性能监控，以及用户行为数据处理等。

1 Kafka主要特性

1.1 Kafka是一个流处理平台，流平台需如下特性:

• 可发布和订阅流数据，类似于消息队列或者企业级消息系统
• 以容错的方式储存流数据
• 可以在流数据产生时就进行处理(Kafka Stream)

1.2 Kafka适合什么样的场景?

● 基于Kafka ,构造实时流数据管道,让系统或应用之间可靠地获取数据。
● 构建实时流式应用程序，处理流数据或基于数据做出反应。

2 相关概念 – AMQP协议

AMQP (Advanced Message Queuing Protocol)，是一个提供统一消息服务的标准高级消息队列协议,是应用层协议的一个开放标准，为面向消息的中间件而设计。

• Server

AMQP服务端，接受客户端连接，实现AMQP消息队列和路由功能的进程。

• Producer

生产者，向broker发布消息的客户端应用程序。

• Consumer

消费者，向消息队列请求消息的客户端应用程序

遇到的主要问题：

• 数据正确性不足

数据的收集主要采用轮询（Polling），确定轮询间隔时间就成了高度经验化的难题。虽然可以采用一些启发式算法（Heuristic）来帮助评估，但一旦指定不当，还是会造成较大的数据偏差。

• 系统高度定制化，维护成本高

各子系统都需要对接数据收集模块，引入了大量的定制开销和人工成本

LinkedIn工程师尝试过使用ActiveMQ解决这些问题，但并不理想
显然需要有一个“大一统”的系统来取代现有的工作方式，而这个系统就是Kafka。

Kafka自诞生伊始是以消息引擎系统的面目出现在大众视野中的
如果翻看0.10.0.0之前的官网说明

Kafka社区将其清晰地定位为一个分布式、分区化且带备份功能的日志提交（Commit Log）服务。

Kafka作者之一Jay Kreps曾经谈及过命名的原因。
因为Kafka系统的写性能很强，所以找了个作家的名字来命名似乎是一个好主意。大学期间我上了很多文学课，非常喜欢Franz Kafka这个作家，另外为开源软件起这个名字听上去很酷。

Kafka旨在提供三个方面的特性：

• 提供一套API实现生产者和消费者
• 降低网络传输和磁盘存储开销
• 实现高伸缩性架构。

随着Kafka的不断完善，Jay等大神们终于意识到将其开源惠及更多的人是一个非常棒的主意，因此在2011年Kafka正式进入到Apache基金会孵化并于次年10月顺利毕业成为Apache顶级项目。

特别在大数据领域，Kafka在承接上下游、串联数据流管道方面发挥了重要的作用：
所有的数据几乎都要从一个系统流入Kafka然后再流向下游的另一个系统中
这引发了Kafka社区的思考：与其我把数据从一个系统传递到下一个系统中做处理，何不自己实现一套流处理框架？
Kafka社区于0.10.0.0版本正式推出了流处理组件Kafka Streams，也正是从这个版本开始，Kafka正式“变身”为分布式的流处理平台，而不仅仅是消息引擎系统了
今天Apache Kafka是和Storm/Spark/Flink同等级的实时流处理平台。

国内对Kafka是流处理平台的认知还尚不普及，其核心的流处理组件Kafka Streams更是少有大厂在使用
随着在Kafka峰会上各路大神们的鼎力宣传，如今利用Kafka构建流处理平台的案例层出不穷，而了解并有意愿使用Kafka Streams的厂商也是越来越多

优势

更易实现端到端的正确性（Correctness）

Google大神Tyler曾经说过，流处理要最终替代它的“兄弟”批处理需要具备两点核心优势

• 实现正确性
• 提供能够推导时间的工具

实现正确性是流处理能够匹敌批处理的基石
正确性一直是批处理的强项，而实现正确性的基石则是要求框架能提供精确一次处理语义，即处理一条消息有且只有一次机会能够影响系统状态
目前主流的大数据流处理框架都宣称实现了精确一次处理语义，但这是有限定条件的，即它们只能实现框架内的精确一次处理语义，无法实现端到端
因为当这些框架与外部消息引擎系统结合时，无法影响到外部系统的处理语义，所以Spark/Flink从Kafka读取消息之后进行有状态的数据计算，最后再写回Kafka，只能保证在Spark/Flink内部，这条消息对于状态的影响只有一次
但是计算结果有可能多次写入到Kafka，因为它们不能控制Kafka的语义处理
相反地，Kafka则不是这样，因为所有的数据流转和计算都在Kafka内部完成，故Kafka可以实现端到端的精确一次处理语义

举个例子，使用Kafka计算某网页的PV——我们将每次网页访问都作为一个消息发送的Kafka
PV的计算就是我们统计Kafka总共接收了多少条这样的消息即可
精确一次处理语义表示每次网页访问都会产生且只会产生一条消息，否则有可能产生多条消息或压根不产生消息。

流式计算的定位

官网上明确Kafka Streams是一个用于搭建实时流处理的客户端库而非是一个完整的功能系统
不能期望着Kafka提供类似于集群调度、弹性部署等开箱即用的运维特性，需要自己选择适合的工具或系统来帮助Kafka流处理应用实现这些功能。
这的确是一个“双刃剑”的设计，也是Kafka社区“剑走偏锋”不正面PK其他流计算框架的特意考量
大型公司的流处理平台一定是大规模部署的，因此具备集群调度功能以及灵活的部署方案是不可或缺的要素
但毕竟这世界上还存在着很多中小企业，它们的流处理数据量并不巨大，逻辑也并不复杂，部署几台或十几台机器足以应付。在这样的需求之下，搭建重量级的完整性平台实在是“杀鸡焉用牛刀”，而这正是Kafka流处理组件的用武之地
因此从这个角度来说，未来在流处理框架中，Kafka应该是有一席之地的。

Kafka能够被用作分布式存储系统
Kafka作者之一Jay Kreps曾经专门写过一篇文章阐述为什么能把Kafka用作分布式存储。不过我觉得你姑且了解下就好了，我从没有见过在实际生产环境中，有人把Kafka当作持久化存储来用 。

参考

• Apache Kafka实战