分布式,大数据
高吞吐量,分布式发布订阅系统,可以收集并处理用户在网站中的所有动作流数据及物联网设备的采样信息
作用:消息的订阅与发布,系统间解耦,异步通信,削峰
Kafka Streaming应用在应用端,部署方便
主要研究:消息队列Message Queue 及Kafka Streaming流处理
消息队列工作模式:
至多一次
没有限制
Kafka集群以Topic形式负责分类集群中的Record,每个Topic底层都会对应一组分区的日志用于持久化的Recordr;
每个分区有一个Leader,其他Broker充当follower,leader负责数据读写,follwer负责同步数据
若机器宕机,其他follower会选举新的Leader负责读写,Leader的监控和Topic的部分元数据存储在ZooKeeper中
Kafka所有消息通过Topic为单位管理,每个Topic会有多个订阅者,Kafka负责管理集群中每个Topic的一组日志分区数据
生产者将数据发布到相应的Topic,之后通过轮询,哈希等负载均衡方式发送到Topic的哪个分区
每组日志分区是有序的不可变的日志序列,分区的每个Record被分配了唯一的序列化编号称为offset,集群会持久化发布到Topic中的Record信息,默认持久化7天
底层会定期检查日志文件,之后将过期的数据从log中移除,使用硬盘存储日志文件
分区之间消息的先后顺序无法保证,可以只采用一个分区,只能保证一个分区内部的消息的先后顺序
为什么设置分区?
分区越大,处理的写入的数据量越大,高并发,快速相应,处理并发能力越强
消费者:
消息者消费Topic中数据的时候,每个消费者会维护本次消费对应的offset,消费者消费完1批消息后会将本次消费的偏移量交给Kafka集群。消费者可以从一个Topic分区中的任意位置读取队列数据,因此多个消费者之间彼此独立
对Topic实现日志分区的目的:
每个服务器可能充当某些分区的Leader,也可能充当其他分区的follwer,负载得到很好的平衡;
运行日志超出单个服务器所能容纳的大小,每个单独的分区必须适合托管它的服务器,可以处理任何的数据
高性能
优化写入速度采用顺序写入和MMFile(内存映射文件)两种技术
不是实时写入磁盘
直接利用操作系统的Page实现文件到物理内存的直接映射,完成MMP映射之后用户对内存的所有操作直接被操作系统自动刷新到磁盘上,降低IO率
服务器相应客户端读取时,底层使用ZeroCopy技术,直接将数据通过内核空间传递输出,数据没有抵达用户空间
ZeroCopy示意图:
标签:分区,Kafka,Topic,日志,数据,Leader From: https://blog.csdn.net/weixin_47559057/article/details/144701251