- 实现数据生产者与消费者解耦，方便扩展数据流水线；
- 承载大规模数据请求（发送与处理速率不匹配、大量并发）；
- 可作为发布订阅系统或数据总线；
- 分布式架构：性能和吞吐量高、容错性强、扩展性好；
- 数据持久性：数据都会（顺序I/O、批量、压缩）持久化到磁盘上，结合多副本策略与应答响应模式避免丢失。
基本架构
- 由Producer、Broker、Consumer组成；
- Broker作为缓冲区，连接Producer和Consumer，通过ZooKeeper做协调和服务发现；
- 采用push-pull架构，Consumer可以结合实际情况（负载）获取数据，并自行维护读取数据的offset；
工作流程：
- Producer产生消息，根据路由规则把消息发送到指定Partition的Broker上；
- Broker接收到消息后，将消息追加到Log中保存（持久化）；
- Follower Replica会与Leader Replica同步，当ISR集合中所有Replica完成同步之后，Leader HW会增加，并向Producer发送应答；
- Consumer加入Consumer Group后，会触发Rebalance将Partition分配给不同的Consumer消费；
- Consumer会恢复Offset位置，向Broker发送拉取消息的请求；
- Leader Replica验证请求Offset及其他信息，最终返回消息。
Producer
- Topic：消息主题，划分消息归属；
- Key：消息主键，根据主键取hash划分Partition编号，由Broker写到对应Partition；
- Message：JSON或Avro、Thrift、Protobuf等序列化对象。
Broker
- 扩展：多个Broker可自动实现负载均衡与高可用；根据Topic可把消息分成不同Partition、分配到不同的Broker（类似数据库水平切分的概念，提高读写能力）；
- 容错：每个Partition可有多个副本（Leader-follower同步），且Broker接收Producer请求会把消息持久化到本地，实现数据冗余容错（结合按时间/空间的保留策略周期性删除旧消息）；
- 相同Topic相同Partition內部的数据是有序的（offset顺序性不跨分区），不保证Partition之间数据全局有序；
- 日志（消息写入分区，即写入对应的日志中）分段并按索引存储，支持压缩（按key合并，保留最新value）。
Consumer
- 主动从Broker拉取数据，并维护数据offset（自行决定消息读取进度）；
- Consumer扩展：Consumer可分组，同组Consumer实现负载均衡（每个Partition只分配给一个COnsumer消费）。
ZooKeeper
- 注册Broker并记录位置、状态、维护的Topic和Partition等信息，以便Consumer获取；
- Consumer故障时其他Consumer通过ZK获取以上信息实现错误恢复。
Controller
- 多个Broker可组成一个Cluster对外提供服务，选举出一个Controller负责管理分区状态、副本状态，监听数据变化等工作；
- Controller通过一主多从实现，也是通过Leader-Follower机制选举。
关键技术点
对比Flume
应用定位上，Kafka是通过多副本和持久化（暂存一段时间）确保数据不丢失，Flume只是确保在传输过程中出错可以恢复（Sink发送成功后数据从Channel删除）。
可靠性级别可控
Producer向Broker发送消息可设置确认应答方式控制可靠性级别。
数据多副本
- 每个Topic的数据存放到多个Partition，每个Partition可以有多个Replica，由Leader Replica（负责处理读写）同步给Follower Replica（仅负责同步），Leader故障时可重新选举；
- ISR：可用的Follower集合，要求副本所在节点与ZK相连、且offset与Leader的Offset差值在一定范围内；延迟过高的副本会被移出ISR，直到从异常恢复、同步完成到一定程度后才被加入ISR；
- HW（HighWatermark）：标记一个特殊的Offset，Consumer只会拉取HW之前的消息，之后的消息不可见；每次所有的Follower Replica都拉取HW指定的消息同步后Leader Replica会递增HW；
- LEO：所有的Replica都有的Offset标记，指向最后一条消息的Offset，Producer向Leader Replica追加消息时，Leader Replica的LEO会递增，Follower成功同步后也会递增LEO
- HW与LEO的关系：消息追加到Leader/同步到Follower时，递增LEO；所有Replica都完成同步，则递增HW。
复制方式
- 同步复制：所有工作的Follower都复制完，消息才被认为提交成功（故障的Follower副本会拖慢整个系统的性能）；
- 异步复制：Leader收到消息后，即认为提交成功，而不管Follower与Leader之间的同步过程（存在消息同步完成前Leader宕机的风险，重新选举Leader会丢失未同步的消息）；
- ISR策略：只关注ISR，Follower延迟过高时被踢出ISR，此时消息依然可以快速提交，避免高延时拖慢系统性能；Leader宕机时，优先将ISR中的Follower选举为Leader（包含HW前的全部消息）。
高效的持久化机制
由Broker基于offset顺序写入到磁盘
数据传输优化
- 批处理
- zero-copy技术
可控的消息传递语义
控制消息可重复接收的次数（at most once，at least once，exactly once）
