目录
kafka简介
诞生背景
Kafka 是 LinkedIn 公司内部孵化的项目。LinkedIn 最开始有强烈的数据强实时处理方面的需求，其内部的诸多子系统要执行多种类型的数据处理与分析，主要包括业务系统和应用程序性能监控，以及用户行为数据处理等。
kafka的语言,kafka原来由scala语言编写,后来社区来了一批javaer,就改java重写了客户端.
kafka与流
Kafka 在承接上下游、串联数据流管道方面发挥了重要的作用：所有的数据几乎都要从一个系统流入 Kafka 然后再流向下游的另一个系统中。这样的使用方式屡见不鲜以至于引发了 Kafka 社区的思考：与其我把数据从一个系统传递到下一个系统中做处理，我为何不自己实现一套流处理框架呢？基于这个考量，Kafka 社区于 0.10.0.0 版本正式推出了流处理组件 Kafka Streams，也正是从这个版本开始，Kafka 正式“变身”为分布式的流处理平台，而不仅仅是消息引擎系统了。今天 Apache Kafka 是和 Apache Storm、Apache Spark 和 Apache Flink 同等级的实时流处理平台。
流平台的优势：
- 更容易实现端到端的正确性（Correctness）要实现正确性和提供能够推导时间的工具。实现正确性是流处理能够匹敌批处理的基石。
- 它自己对于流式计算的定位。官网上明确标识 Kafka Streams 是一个用于搭建实时流处理的客户端库而非是一个完整的功能系统。这就是说，你不能期望着 Kafka 提供类似于集群调度、弹性部署等开箱即用的运维特性，你需要自己选择适合的工具或系统来帮助 Kafka 流处理应用实现这些功能。
kafka特性
Kafka 在设计之初就旨在提供三个方面的特性：
- 提供一套 API 实现生产者和消费者；
- 降低网络传输和磁盘存储开销；
- 实现高伸缩性架构。
kafka术语
- topic:发布订阅的主题
- producer:向主题发布消息的客户端应用程序
- consumer:订阅主题消息的客户端
- clients: producer与consumer
- broker: kafka的服务器,一个kafka集群由多个broker组成.每个broker负责接收和处理客户端的请求,以及对消息进行持久化.
- partitioning:领导者副本分片
- offset: 表示分区中每条消息的位置信息，是一个单调递增且不变的值
- consumer offset: 表征消费者消费进度，每个消费者都有自己的消费者位移。
- consumer group: 多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。
- rebalance: 消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。
kafka高可用
- 集群化
- 备份机制(replication)
kafka中的副本
kafka中,将备份的副本定义为两类:
- 领导者副本(leader replica),对外提供服务(与客户端交互)
- 追随者副本(follower replica),追随领导者副本(不与客户端交互)
副本的工作机制
生产者向领导者副本写数据,消费者从领导者副本读数据.
追随者副本只向领导者发送同步数据请求.保持数据同步.
kafka伸缩性
partitioning
- Kafka 中的分区机制指的是将每个主题划分成多个分区（Partition），每个分区是一组有序的消息日志。
- 每个分区的N个副本只有一个能充当领导者,对外提供服务;其他n-1是追随者副本
- 分区中包含若干消息,每条消息从0开始,依次递增.
- 客户端只能与分区的领导者进行交互.
broker持久化
kafka使用消息日志(log)来保存数据.
一个日志就是磁盘上一个只能追加写(append-only)消息的物理文件.
(因为只能追加写入，故避免了缓慢的随机 I/O 操作，改为性能较好的顺序 I/O 写操作，这也是实现 Kafka 高吞吐量特性的一个重要手段。)
kafka底层将日志分段,进行磁盘回收.
kafka的分类
apache kafka
如果你仅仅需要一个消息引擎系统亦或是简单的流处理应用场景，
需要对系统有较大把控度
confluent kafka
免费版:http方式调用kafka功能,消息格式向前/后兼容.
企业版:跨数据中心备份,集群监控
未在国内开展业务.文档少
cdh/hdp kafka
大数据云公司包装的kafka,集成监控,运维,管理.
集群掌控度低,版本滞后