大数据组件知识点总结(5) - Kafka
2018-08-22 本文已影响59人
千反田爱瑠爱好者
- 实现数据生产者与消费者解耦,方便扩展数据流水线;
- 承载大规模数据请求(发送与处理速率不匹配、大量并发);
- 可作为发布订阅系统或数据总线;
- 分布式架构:性能和吞吐量高、容错性强、扩展性好;
- 数据持久性:数据都会(顺序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)