目录
高吞吐量保证机制
1. 高性能
单节点支持上千个客户端,百MB/s吞吐,接近网卡的极限
2.持久性,顺序读写
a.消息直接持久化在普通磁盘上,就是直接append到磁盘里去,这样的好处是直接持久化,数据不会丢失,
b.顺序写入:避免磁盘频繁的寻址,导致写入速度下降,读速度下降。
c.过期清理:基于时间删除默认7天和基于partition文件的大小删除。
d.Memory Mapped Files:mmf直接利用操作系统的Page来实现文件到物理内存的映射,完成之后对物理内存的操作会直接同步到硬盘,大大提高了IO速率,省去了用户空间到内核空间的复制。它的缺点显而易见--不可靠,当发生宕机而数据未同步到硬盘时,数据会丢失,Kafka提供了produce.type参数来控制是否主动的进行刷新(默认为sync,同步模式),如果kafka写入到mmp后立即flush再返回给生产者则为同步模式,反之为异步模式。
3.零拷贝
减少一次内核态用户态切换,这个和nginx 中的零拷贝是一样的: nginx 安装配置_yang_zzu的博客-CSDN博客
4.存在多个partition分区
一个topic被划分为多个分区,partition之间相互不影响,提高并行处理消息的能力。
5.生产者缓冲区
可以进行批量提交,减少io次数,提高吞吐量
6.生产者数据压缩,节省网络带宽和Kafka存储成本
producer启用数据压缩,Kafka 会将启用了哪种压缩算法封装进消息集合中,当 Consumer 读取到消息集合时,它自然就知道了这些消息使用的是哪种压缩算法
Producer 端压缩、Broker 端保持、Consumer端解压缩
#生产者生成的所有数据的压缩类型,此配置接受标准压缩编解码器('gzip','snappy','lz4'),
#默认值为producer,推荐使用 lz4
#默认情况下消息是不压缩的,此参数可指定采用何种算法压缩消息,可取值:none,snappy,gzip,lz4。
# snappy压缩算法由Google研发,这种算法在性能和压缩比取得比较好的平衡;
# 相比之下,gzip消耗更多的CPU资源,但是压缩效果也是最好的。通过使用压缩,我们可以节省网络带宽和Kafka存储成本。
spring.kafka.producer.compression-type=lz4
7.分布式
a. 数据副本冗余: 对 partition 分区进行数据备份,添加副本
b. 流量负载,只有主 partion 对外提供读写的能力,主partition 分布在不同的节点上面,实现对流量负载
c. 可扩展,在线扩展,不需要停服务
相比其他消息中间件的优势
1. 消息的存储文件是 “序列文件”,(序列文件的特征是按顺序写,按顺序读)
2. 使用offset 标记消息的消费位置,不需要保存消息的状态,可以被多个 consumer 进行多次消费
3. 支持点对点的消息传递
4. kafka 页缓存,page cache 的大小通常为4K,,用于缓存文件的逻辑内容,从而加快对磁盘上映像和数据的访问
文章链接
docker kafka集群搭建 docker kafka集群搭建_yang_zzu的博客-CSDN博客_docker kafka集群搭建
kafka springboot 集成配置+测试 kafka springboot 集成配置+测试_yang_zzu的博客-CSDN博客
kafkatool 工具的使用 kafkatool 工具的使用_yang_zzu的博客-CSDN博客_kafka tool的使用
kafka增加副本+增加partition+加速消费 kafka增加副本+增加partition+加速消费_yang_zzu的博客-CSDN博客
kafka _ spring.kafka.listener.concurrency 的使用 kafka _ spring.kafka.listener.concurrency 的使用_yang_zzu的博客-CSDN博客_spring.kafka.listener.concurrency
总结,简要回答
1. 顺序读写,磁盘顺序读写的速率和内存随机读写的速率差不多
2. 使用page缓存,避免了jvm gc 带来的性能损耗
3. 零拷贝(去掉了用户态内核态数据的拷贝处理)
4. 批处理(生产者,消费者都能够进行批处理操作)
5. 数据压缩,生产者压缩数据,消费者解压缩,减少网络i/o的开销 和 磁盘数据加载的开销