简介
Kafka作为一种消息中间件，它是一种分布式的，基于发布/订阅的消息系统。 Kafka最初是由LinkedIn开发，用它来跟踪活动数据和运营指标。Twitter把它作为Storm的一部分来作为流处理的基础。Square把Kafka当作总线，将所有系统事件（日志，自定义事件，指标等）传输到各个Square数据中心，或者输出到Splunk，或者应用于Graphite（仪表板），或者实现Esper-like/ CEP警报系统。Spotify，Uber，Tumbler，Goldman Sachs，PayPal，Box，Cisco，CloudFlare和Netflix等公司也都在使用它。 许多需要快速处理大量数据的大公司都在使用Kafka。据统计，有三分之一的世界财富500强企业正在使用Kafka，包括所有TOP10旅游公司，7家TOP10银行，8家TOP10保险公司，9家TOP10电信公司等等。LinkedIn,Microsoft和Netflix每天都用Kafka处理万亿级的信息。 主要设计目标如下： 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输 同时支持离线数据处理和实时数据处理
由于Kafka是一种快速、可扩展、可持久和高容错的发布-订阅消息系统（publish-subscribe messaging system），它常用于实时流数据结构的实时分析。Kafka对于一些有大数据量和高响应需求的Use Case的支持远好于JMS、RabbitMQ和AMQP。相比于那些工具，Kafka支持更高的吞吐量，更高的稳定性和副本（replication）特性。这使得它比传统的MOM更加适合跟踪服务调用（可以跟踪每次调用）或跟踪IoT传感器数据。 Kafka可以与Flume/Flafka、Spark Streaming、Storm、HBase、Flink以及Spark配合使用，用于实时获取、分析和处理流数据。Kafka可以为Hadoop大数据湖（Hadoop BigData lake）提供数据流。Kafka Broker支持在Hadoop或Spark中低延时地处理和分析海量信息流。此外，Kafka子项目KafkaStreaming可用于实时分析。 Kafka可以用于流处理、网站活动跟踪、度量收集和监视、日志聚合、实时分析、CEP、将数据注入Spark和Hadoop、CQRS、重放消息、错误恢复以及分布式提交内存计算（微服务）的日志等应用场合。
Kafka最常用于将数据实时传输到其他系统。Kafka作为一个中间层来解耦不同的实时数据管道。Kafka核心并不适合入数据聚合（data aggregation）或CEP等的直接计算。Kafka Streaming作为Kafka生态系统的一部分，提供了进行实时分析的能力。Kafka可以为Storm、Flink、Spark Streaming以及你的服务和CEP系统提供快速通道系统（实时操作数据系统）。Kafka也用于流数据批量数据分析，它将数据传输到大数据平台或RDBMS，Cassandra，Spark甚至S3中用于未来的数据分析。这些数据存储通常支持数据分析，报告，数据科学分析，合规性审计和备份。
Kafka基于zero copy原则，深度依靠操作系统内核实现快速移动数据。Kafka能将数据记录分批处理。这些批次数据可以通过端到端的方式从生产者到文件系统（Kafka主题日志）再到消费者。批处理能实现更高效的数据压缩并减少I / O延迟。Kafka将不可变的提交日志写入连续磁盘，从而避免了随机磁盘访问和磁盘寻道速度慢的问题。Kafka支持增加分区进行横向扩展。它将主题日志分成几百个（可能有数千个）分区分布到数千个服务器。这种方式可以让Kafka承载海量负载。
Kafka之所以这么流行，首先最主要的原因是Kafka具有极佳的性能表现。它非常稳定，能提供稳定的持久化，具有灵活的订阅-发布消息队列，可与N个消费者群组进行良好扩展，具有强大的复制功能，为生产者提供可调整的一致性保证，并在碎片级别提供保留排序（即Kafka主题分区）。其次，Kafka可以很好地兼容需要数据流处理的系统，并将这些系统融合、转换并加载到其他存储。另外，Kafka操作（配置和使用）都非常简单，而且Kafka的工作原理也很好理解。当然了，如果Kafka处理数据很慢，有再多其他优点都是没有意义的，所以，“多快好省”就是Kafka的最大优势。
架构
Kafka详细架构图：
说明：
- Kafka Cluster（Kafka集群）：Kafka网络如果存在多个代理，则该Kafka网络被称为Kafka集群。可以扩展Kafka集群，无需停机。这些集群用于管理消息数据的持久性和复制。
- Producer（消息生产者）：生产者就是向kafka broker发消息的客户端，生产者是发送给一个或多个Kafka topic的消息的发布者。生产者向Kafka消费者发送数据。每当生产者将消息发布给代理时，代理只需将消息附加到最后一个段文件。实际上，该消息将被附加到分区。生产者还可以向他们选择的分区发送消息。
- Consumer（消费者）：消息消费者是从kafka broker取消息的客户端。消费者订阅一个或多个topic，并通过从代理中提取数据来使用已发布的消息。
- Topic（topic）：可以理解为一个队列，属于特定类别的消息流称为topic。数据存储在topic中。一般一个Topic会被多个Consumer订阅。
- Consumer Group （CG）：这是kafka用来实现一个topic消息广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个topic可以对应多个CG。topic的消息会复制（不是真的复制，是概念上的）到所有的CG，但每个partition只会把消息发给该CG中的一个consumer。 如果需要实现广播，只要每个consumer有一个独立的CG就可以了；要实现单播只要所有的consumer在同一个CG中。用CG还可以将consumer进行自由分组而不需要多次发送消息到不同的topic；同一个组里面的不同消费者不能够同时消费同一个分区里面的数据。
- Broker（缓存代理）：负责维护发布数据。实际使用中，一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。 a) 假设在一个topic和N个代理中有N个分区，每个代理将有一个分区。 b) 假设在一个topic中有N个分区并且有N+M个代理（M,N>0），则第一个N代理将具有一个分区，并且下一个M代理将不具有用于该特定topic的任何分区。 c) 假设在一个topic中有N个分区并且有N-M个代理（M,N>0），每个代理将在它们之间具有一个或多个分区共享。由于代理之间的负载分布不相等，不推荐使用此方案。
- Partition（分区）：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上。一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）号。kafka只保证在一个partition中顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序；
- Partition Offset（分区偏移）：每个分区消息都具有称为 offset 的唯一序列标识。kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如想找位于2049的位置，只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka。
- Replicas of Partition（分区备份）：副本只是一个分区的备份。副本从不读取或写入数据。它们用于防止数据丢失。partition<=broker
- Segment（分区）：Segment对应于2个文件（1个索引文件，1个数据文件）。一个Partition对应于一个文件夹。逻辑上一个Partition可以包含无穷多个Segment。数据清理时，旧的Segment将直接被删除。 可以这样认为，Partition是物理的概念，每个Partition相当于一个文件夹（和hive类似）；而Topic是逻辑的概念，Producer和Consumer只关心各自推送和订阅的Topic，无需关心整条存于集群的那个Broker。
- Leader（领导者）：Leader是负责给定分区的所有读取和写入的节点。每个分区都有一个服务器充当Leader。
- Follower（追随者）：跟随领导者指令的节点被称为Follower。如果领导失败，一个追随者将自动成为新的领导者。追随者作为正常消费者，拉取消息并更新其自己的数据存储。
注意： 同一个组里面的不同消费者可以消费同一个topic不同分区的数据。为提高并发一个topic有多少partition就应该启动多少线程。
