高性能：单节点支持上千个客户端，并保证零停机和零数据丢失。
- 利用Linux的页缓存
- 顺序读，顺序写
- 零拷贝
持久化数据存储：将消息持久化到磁盘。通过将数据持久化到硬盘以及replication防止数据丢失。
分布式系统: 易于向外扩展。所有的Producer、Broker和Consumer都会有多个，均为分布式的。无需停机即可扩展机器。多个Producer、Consumer可能是不同的应用。
可靠性: Kafka是分布式，分区，复制和容错的。
客户端状态维护：消息被处理的状态是在Consumer端维护，而不是由server端维护。当失败时能自动平衡。
支持online和offline的场景。
支持多种客户端语言。Kafka支持Java、.NET、PHP、Python等多种语言。
2. Kafka应用场景
2.1. 消息队列
Kafka 最常见的应用场景就是作为消息队列。 Kafka 提供了一个可靠且可扩展的消息队列，可以处理大量数据。
Kafka 可以实现不同系统间的解耦和异步通信，如订单系统、支付系统、库存系统等。在这个基础上 Kafka 还可以缓存消息，提高系统的可靠性和可用性，并且可以支持多种消费模式，如点对点或发布订阅。
2.2. 日志处理与分析(最常用的场景)
公司可以用Kafka可以收集各种服务的Log，典型就是 ELK（Elastic-Logstash-Kibana）。Kafka 有效地从每个实例收集日志流。
图片
2.3. 推荐数据流
流式处理是 Kafka 在大数据领域的重要应用场景之一，其与流处理框架（如Spark Streaming、Storm、Flink等）框架进行集成。主要内容包括：
Kafka作为流式处理平台的数据源或数据输出：Kafka可以作为流数据的中介，将实时数据发送到Kafka中，同时也可以从Kafka中读取数据进行处理和分析。 推荐系统的工作流程：以淘宝、京东等线上商城网站的推荐系统为例，描述了推荐系统的工作流程。主要包括：
- 将用户的点击流数据发送到Kafka中。
- 使用Flink等流处理框架读取Kafka中的流数据，进行实时聚合处理。
- 机器学习算法使用来自数据湖的聚合数据进行训练，同时算法工程师也会对推荐模型进行调整。
- 推荐系统持续改进对每个用户的推荐相关性。
图片
2.4. 系统监控与报警
与日志分析系统类似，我们需要收集系统指标以进行监控和故障排除。不同之处在于，指标是结构化数据，而日志是非结构化文本。指标数据被发送到 Kafka 中，并在 Flink 中进行聚合。下图展示了常见监控报警系统的工作流程：
- 采集器读取购物车指标发送到 Kafka 中
- Flink 读取 Kafka 中的指标数据进行聚合处理
- 实时监控系统和报警系统读取聚合数据作展示以及报警处理
图片
2.5. CDC（数据变更捕获）
CDC(Change data capture) 将数据库更改流式传输到其他系统，以便进行复制或缓存/索引更新。例如，在下图中，事务日志被发送到 Kafka，并由 ElasticSearch、Redis 和辅助数据库引入。
图片
2.6. 系统迁移
Kafka 可以用来作为老系统升级到新系统过程中的消息传递中间件（Kafka），以此来降低迁移风险。 在下图中，为了升级下图中的订单服务，我们更新了旧版订单服务，以使用 Kafka 的输入并将结果写入 ORDER 主题。新的订单服务使用相同的输入，并将结果写入 ORDERNEW 主题，对帐服务比较 ORDER 和 ORDERNEW。如果它们相同，则新服务通过测试。
图片
3. Kafka核心概念
3.1. 生产者(Producer)
生产者: 创建消息,将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的 segment 文件中 一般情况下，一个消息会被发布到一个特定的主题上。
- 默认情况下通过轮询把消息均衡地分布到主题的所有分区上。
- 在某些情况下，生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的，分区器为键生成一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。
- 生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区。
3.2. 消费者（Consumer）
消费者读取消息。
- 消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。
- 消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka 会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在Zookeeper 或Kafka上，如果消费者关闭或重启，它的读取状态不会丢失。
- 消费者是消费组的一部分。群组保证每个分区只能被一个消费者使用。
- 如果一个消费者失效，消费组里的其他消费者可以接管失效消费者的工作，再平衡，分区重新分配。
3.3. Broker
一个独立的Kafka 服务器被称为broker。
broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。
- 如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。
- 如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。
- 如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。
broker 是集群的组成部分。每个集群都有一个broker 同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）控制器负责管理工作，包括将分区分配给broker 和监控broker 在集群中，一个分区从属于一个broker，该broker 被称为分区的首领。
图片
3.4. Topic
每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。
物理上不同Topic的消息分开存储。
Topic就好比数据库的表，尤其是分库分表之后的逻辑表。
3.5. 分区(Partition)
- Topic可以被分为若干个分区，一个分区就是一个提交日志
- 消息以追加方式写入分区，然后以先入先出的顺序读取
- 无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序
- Kafka 通过分区来实现数据冗余和伸缩性
- 在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1
图片
