深入理解Kafka数据高并发写入、可靠性以及EOS语义_不清不慎的博客-CSDN博客_kafka并发写入
深入理解Kafka数据高并发写入、可靠性以及EOS语义
置顶
不清不慎
于 2019-03-17 00:59:16 发布
1161
收藏
分类专栏：
Kafka
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_37142346/article/details/88610034
版权
Kafka
专栏收录该内容
6 篇文章
3 订阅
订阅专栏
Kafka作为一个优秀的高性能消息中间件，广泛用于各种大数据高并发场景下，常常听一些技术大牛讲起kafka滔滔不绝，赞不绝口，但是它是如何保证数据的高并发写入，可靠性以及流数据处理中常见的EOS语义的呢？本篇文章让我们来一起深入探究其内部原理。
一、 高并发写入
作为一个消息队列，我们首先需要考虑消息如何传递，如何存储。在高并发场景下，我们常常会想到如何提高系统的吞吐量，Kafka在生产者写入消息的时候会将数据最终写入磁盘，既然它是基于磁盘读写，那么频繁的IO操作肯定会影响读写的性能，为何会有高性能呢？
1. 系统缓存+顺序写
在这里，Kafka生产者将消息写入各个broker中的时候，并不会直接写入磁盘，在这中间有一些缓存，被称为Page Cache，它是基于操作系统的缓存，因为也被称为OS Cache，数据写入的时候，会将数据写入缓存，然后由操作系统决定什么时候写入磁盘，可以看到，写入数据时是直接和内存交互，因此其写入性能很高，当然不仅仅如此，在从缓存写入磁盘的时候，它会将随机写优化为顺序写，我们都知道，磁盘的写入是基于磁道寻址的，随机写会引发大量的磁盘寻址，浪费大量的时间，而顺序写避免了频繁的寻址操作，写入性能提高了数倍。（画外音：很多优秀的开源框架都采用了顺序来优化写入，比如HBase memestore） 以上是我们从生产者的角度来分析其高并发写入，下面我们从消费者的角度来分析。
2.零拷贝技术
上面提到数据会写入磁盘，那么读取数据时需要直接和磁盘交互，也会影响其读取的性能，传统的从磁盘读取数据需要进行系统间内核的切换，操作系统需要读写磁盘数据到本地缓存中，然后系统切换到用户态将数据拷贝到应用缓存中，此时应用程序才会读取缓存中的数据进行操作。可以看出这种方式严重影响了读取的性能。
那么Kafka是怎么读取数据的呢？这里采用了零拷贝技术（画外音：JDK文件的拷贝也应用到了这种技术，比如transferTo API，可以参考我的笔记 文件拷贝的几种方式以及对比）。所谓零拷贝技术就是避免操作系统内核态到用户态的切换，直接基于内核，避免了不必要的上下文切换与拷贝，大大的提高了性能。
二、可靠性
同样，我们从生产者和消费者的角度来分析其可靠性。 试想，生产者在向broker中发送数据的时候，如何知道Broker是否收到消息了呢？万一网络断开怎么办？（画外音：想想TCP是如何实现可靠传输的？）。
在这里，我们需要知道kafka在向broker写入数据的时候是分为partition进行写入的，并且在不同的broker保存了相同的副本，并且这些副本之间会有一个主副本。具体在broker中是如何分配的呢？本篇文章不进行讨论，后续文章中会进行介绍。
在kafka中，有一个acks参数可以来设置，这个参数表示必须有多少个分区副本收到消息，Kafka才会认为写入成功。可以有三个选项来进行设置：
acks=0，这种方式表示生产者不会等待服务器是否收到消息的答复，也就是说即使由于网络问题服务器没有收到消息，生产者也不会知道，这种方式适合用于数据要求不高的场合，其性能很高。acks=1，这种方式表示生产者需要等待接收主节点的应答消息才会知道数据写入成功，如果没有收到应答信息或者当前集群因为选举没有主节点，此时会抛出异常。但是如果一台节点没有收到消息成为了主节点，此时会数据还是会丢失。acks=all，这种方式表示生产者需要收到所有服务器的应答信息，才会知道消息发送成功，这种方式最为安全，但是其吞吐量低。
那么，kafka又是如何保证消息的顺序性呢？（画外音：想想TCP如何实现数据的有序性的？）
kafka可以保证分区消息的有序性，即如果有一个分区被多个生产者写入，如果A比B先写入，那么会保证B的偏移量大于A的偏移量，而且保证A比B先消费。
ISR机制
大部分环境下，我们设置acks=1，如果设置为all那么其性能严重下降，在大数据场景下根本不适用。那么，我们来考虑一个问题，如果生产者在向leader节点写入数据，然后同步给每个follower，但是如果此时follower宕机了怎么办？有人说搭建高可用集群，那我们再来分析一下，如果leader节点还没来得及同步给其他节点就宕机了，那么follower选举出一个新的leader对外提供服务，但是上一条数据已经丢失了，还是没有达到数据的可靠性。
在这里，我们就介绍到了kafka的ISR机制，什么是ISR机制呢？
简单地说就是在每个partition中会维护着一个ISR列表，这个列表中一定会包含leader，还有与它同步的follower，只要某个follower会同步leader的数据，那么肯定会在该列表中。如果某个follower因为自身发生问题，不能同步数据，那么会被认为“out of sync”，从ISR列表中删除。
Kafka的ISR机制保证了ISR列表中至少leader写入数据成功并且至少有一个follower同步完成leader的数据，才会认为消息发送成功，否则会认为发送失败，一直重试。
三、EOS语义
所谓EOS语义指 Exactly Once语义，表示数据有且仅被处理一次，在常见的流数据处理场景中，都存在着这种问题（画外音：在spark的低版本中并不能保证这种语义，Flink中可以保证该语义）。
在kafka的老版本中，并不能保证EOS语义。 例如。broker可能在提交消息和返回ack给生产者中间宕机，在这种情况下，生产者会由于没有收到响应而重试，从而导致消息流的重复。因此，生产者请求的幂等性是非常重要的，这能够保证即便出现重试或者broker故障，每条消息也只会出现一次。 不过让人庆幸的是，在2018年发布的kafka 0.11版本中，保证了该语义。 在生产者初始化消息的时候，会生成一个唯一ID。PID和一个序列号会包含在消息中，一起被发送到broker。序列号从0开始单调递增，对于每一个PID/TopicPartition对来说，当且仅当消息的序列号比上一次提交消息的序列号刚好大1，broker才会接收这个消息。如果不是消息重复的话，生产者会重发消息。 以上就是今天的全部内容，我们深入分析了Kafka是如何保证高并发写入，可靠性以及EOS语义，如有任何问题，欢迎各位大佬指出。谢谢！
参考资料 《Kafka权威指南》 掘金-架构师笔记
不清不慎
关注
关注
点赞
收藏
打赏
评论
深入理解Kafka数据高并发写入、可靠性以及EOS语义
Kafka作为一个优秀的高性能消息队列，广泛用于各种大数据高并发场景下，常常听一些技术大牛讲起kafka滔滔不绝，赞不绝口，但是它是如何保证数据的高并发写入，可靠性以及流数据处理中常见的EOS语义的呢？本篇文章让我们来一起深入探究其内部原理。一、 高并发写入作为一个消息队列，我们首先需要考虑消息如何传递，如何存储。在高并发场景下，我们常常会想到如何提高系统的吞吐量，Kafka在生产者写入消...
复制链接
扫一扫
专栏目录
Kafka是如何实现几十万的高并发写入
专注于后端开发，时常接触大数据 、人工智能等
09-29
307
开篇
在初识kafka 一文中讲了使用MQ(消息队列)来设计系统带来的好处：业务解耦、流量削峰、灵活扩展
当下流行的MQ有很多，因为我们公司在技术选型上选择了使用Kafka，所以我就整理了一篇关于Kafka的入门知识。通过技术选型 我们对业界主流的MQ进行了对比，Kakfa最大的优点就是吞吐量高 。
Kafka是高吞吐低延迟的高并发、高性能的消息中间件，在大数据领域有极为广泛的...
Kafka如何实现每秒上百万的超高并发写入？
u011277123的博客
03-11
4398
51CTO传媒2019-03-06 16:50:35
这篇文章来聊一下 Kafka 的一些架构设计原理，这也是互联网公司面试时非常高频的技术考点。
Kafka 是高吞吐低延迟的高并发、高性能的消息中间件，在大数据领域有极为广泛的运用。配置良好的 Kafka 集群甚至可以做到每秒几十万、上百万的超高并发写入。
那么 K...
参与评论
您还未登录，请先
登录
后发表或查看评论
Kafka RecordAccumulator 三 高并发写入数据
最新发布
zhangkai1992的专栏
12-04
275
kafaka 高并发写入数据
canal 投递 数据 只进kafka 0分区
weixin_43564627的博客
07-21
228
canal 投递 数据 只进kafka 0分区
首先要确保其余kafka 有多个分区
在 instance.properties 加入以下配置即可 二者缺一不可
下面一段摘至官网：
mq顺序性问题
1.canal目前选择支持的kafka/rocketmq，本质上都是基于本地文件的方式来支持了分区级的顺序消息的能力，也就是binlog写入mq是可以有一些顺序性保障，这个取决于用户的一些参数选择
2.canal支持MQ数据的几种路由方式：单topic单分区，单topic多分区、多topic单分区、多topi
Kafka高性能读写原理
fangmeng1997的博客
09-11
467
Kafka是高吞吐低延迟的高并发、高性能的消息中间件，在大数据领域有极为广泛的运用。配置良好的Kafka集群甚至可以做到每秒几十万、上百万的超高并发写入。那么Kafka到底是如何做到这么高的吞吐量和性能的呢？
一、页缓存技术 + 磁盘顺序写
首先Kafka每次接收到数据都会往磁盘上去写，如下图所示。
那么在这里我们不禁有一个疑问了，如果把数据基于磁盘来存储，频繁的往磁盘文件里写数据，这个性能会不会很差？大家肯定都觉得磁盘写性能是极差的。
没错，要是真的跟上面那个图那么简单的话，那确实这个性能是比较差的。.
kafka系列-kafka调优篇-高并发高吞吐架构设计
weixin_41279060的博客
12-15
7658
kafka的PageCache读写
不同于Redis和MemcacheQ等内存消息队列，Kafka的设计是把所有的Message都要写入速度低容量大的硬盘，以此来换取更强的存储能力。实际上，Kafka使用硬盘并没有带来过多的性能损失（这一点是有条件限制的，这个条件是，消费者的消费速度要高于或等于生产者的速度）。
kafka重度依赖底层操作系统提供的PageCache功能。（文件缓存，速
深入理解kafka_深入理解Kafka数据高并发写入、可靠性以及EOS语义
weixin_39838028的博客
12-06
49
来源公众号：架构师社区Kafka作为一个优秀的高性能消息中间件，广泛用于各种大数据高并发场景下，常常听一些技术大牛讲起kafka滔滔不绝，赞不绝口，但是它是如何保证数据的高并发写入，可靠性以及流数据处理中常见的EOS语义的呢？本篇文章让我们来一起深入探究其内部原理。一、 高并发写入作为一个消息队列，我们首先需要考虑消息如何传递，如何存储。在高并发场景下，我们常常会想到如何提高系统的吞吐量，Kafk...
面试官：消息中间件如何实现每秒几十万的高并发写入？【石杉的架构笔记】...
石杉的架构笔记
03-04
3184
点击上方"蓝字",右上角选择“设为星标”周一至周五早8点半！精品技术文章准时送上！公众号后台回复 “学习” ，获取作者独家秘制学习套餐 目录1、页缓存技术 +...
高并发高可用之Kafka
Ycy的博客
07-23
410
消息的消费者的消费速度，远赶不上生产者的生产消息的速度，导致kafka中有大量的数据没有被消费。随着没有被消费的数据堆积越多，消费者寻址的性能会越来越差，最后导致整个kafka对外提供的服务的性能很差，从而造成其他服务也访问速度变慢，造成服务雪崩。HW是已完成同步的位置。但是有个问题，如果说这个topic中的消息非常多，多到需要几个T来存，因为消息是保存在log日志文件中的，为了解决这个问题，kafka给出分区解决。–创建多个消费组，多个消费者，部署到其他机器上，一起消费，提高消费者的消费速度。...
kafka EOS
qermeng的博客
03-30
655
Kafka 0.11.0.0引入了EOS（exactly once semantics，精确一次处理语义）的特性，这个特性包括kafka幂等性和kafka事务两个属性。
1）幂等producer 保证单个分区的只会发送一次，不会出现重复消息
2）事务(transation)：保证原子性的写入多个分区，即写入到多个分区的消息要么全部成功，要么全部回滚
启用方法：
1）启用幂等producer:在pr...
什么是并发、并行、高并发？到底多大才算高并发？
weixin_37519463的博客
04-02
9769
并发是指在一个时间段内有多个进程在执行。
并行指的是在同一时刻有多个进程在同时执行。
如果是在只有一个CPU的情况下，是无法实现并行的，因为同一时刻只能有一个进程被调度执行，如果此时同时要执行其他进程则必须上下文切换，这种只能称之为并发，而如果是多个CPU的情况下，就可以同时调度多个进程，这种就可以称之为并行。
什么是高并发
定义：
...
Kafka在高并发的情况下，如何避免消息丢失和消息重复？kafka消费怎么保证数据消费一次？数据的一致性和统一性？数据的完整性？...
weixin_30722589的博客
01-24
957
1、kafka在高并发的情况下,如何避免消息丢失和消息重复?
消息丢失解决方案:
首先对kafka进行限速， 其次启用重试机制，重试间隔时间设置长一些，最后Kafka设置acks=all，即需要相应的所有处于ISR的分区都确认收到该消息后，才算发送成功
消息重复解决方案:
消息可以使用唯一id标识
生产者（ack=all 代表至少成功发送一次)
消费者 （offset手动提交，业务...
Kafka实现高并发的原理（消息中间件如何实现每秒几十万的高并发写入）
小凯的博客
08-07
2535
Kafka: 是一个高吞吐低延迟的高并发，高性能消息中间件。配置良好的Kafka集群能够做到每秒几十万或者上百万的超高并发写入。
Produce
页缓存技术＋磁盘顺序写
Kafka接收到数据的时候，都会往磁盘上去写
Page Cache
内存里面的缓存，是操作系统自己管理的缓存。
在写入磁盘文件的时候，可以直接写入到OS cache里。接下来由操作系统自己决定何时把cache里面的数据刷写到磁盘...
kafka性能参数和压力测试揭秘
热门推荐
stark_summer的专栏
12-07
6万+
上一篇文章介绍了Kafka在设计上是如何来保证高时效、大吞吐量的，主要的内容集中在底层原理和架构上，属于理论知识范畴。这次我们站在应用和运维的角度，聊一聊集群到位后要怎么才能最好的配置参数和进行测试性能。Kafka的配置详尽且复杂，想要进行全面的性能调优需要掌握大量信息，我也只是通过工作中的一些实战经验来筛选出对集群性能影响最大的几个要点，接下来要阐述的观点也仅限于我所描述的环境下，请大家根据自己
Kafka 如何保证消息的高并发写入和读取
weixin_45691780的博客
07-05
618
kafka消息中间件如何实现每秒几十万的高并发写入？
1、页缓存技术 + 磁盘顺序写
首先Kafka每次接收到数据都会往磁盘上去写，如下图所示。
那么在这里我们不禁有一个疑问了，如果把数据基于磁盘来存储，频繁的往磁盘文件里写数据，这个性能会不会很差？大家肯定都觉得磁盘写性能是极差的。
没错，要是真的跟上面那个图那么简单的话，那确实这个性能是比较差的。
但是实际上Kafka在这里有极为优秀和出色的设计，就是为了保证数据写入性能，首先Kafka是基于操作系统的页缓存来实现文件写入的。
操作系统本身有一层缓存，
使用Kafka处理高并发数据流
飞鸟Blog
11-26
8099
如果我们需要持续地处理大约20万条/秒的消息量，同时还需要保证数据的可用性和冗余，我们应该怎么做呢？最近Tadas Vilkeliskis在自己的博客上发表了一篇题为《数据流基础设施》的文章，分享了他们是如何应对这种场景的。
Tadas Vilkeliskis在文章中提到，他们每秒钟大约会收到来自于世界各地的20万次HTTP请求，这些请求包含了用户的行为信息，平均每一条消息的大小约为0.8K
深度解析kafka broker处理发送消息请求并写入磁盘
猿上生活
01-10
970
原创不易，转载请注明出处
文章目录前言1.requstHandler拿到请求找到对应处理方法2.ReplicaManager是怎样appendMessages的总结
前言
在《深度解析kafka broker从连接建立到接收请求发送响应》或者更往前介绍kafka broker 网络组件的文章中，我们介绍了broker处理与消息生产者（客户端）建立连接，processor接收请求，写回响应，requestHandler处理请求信息等流程，我们已经知道了一个请求过来是怎样运转的了，本文接着消息生产者发送消.
kafka多线程写入数据案例
小小鱼
03-30
661
文章目录1、主要思路：2、实现步骤2.1、消息接口 Dbinfo2.2、KafkaConnector2.3、CustomkafkaProducer2.4、测试类App
1、主要思路：
把producer配置信息进行封装
使用LineNumberReader获取文件总行数和对应行的起始字节位置，并存入map里，方便不同线程从不同行读取和写入kafka
继承Thread类，重写run方法并执行
2、实现步骤
2.1、消息接口 Dbinfo
kafka消息对象 KafkaConfiguration
kafka数据 落盘_揭秘kafka为什么每秒几十万的并发写入
weixin_28730549的博客
01-05
285
Kafka是高吞吐低延迟的高并发，高性能的消息中间件，好的Kafka集群可以做到每秒几十万的并发写入操作。那kafka到底用了什么黑科技，这里就把其使用的黑科技一一揭秘。黑科技一：页面缓存磁盘顺序写 当应用发送数据写入kafka请求时，kafka将收到的数据首先写入到操作系统的page cache中，为什么是先写page cache呢，而不是直接写入磁盘呢，这是因为page...
kafka精确一次语义EOS的原理深入剖析-kafka 商业环境实战
weixin_33878457的博客
12-01
154
本套技术专栏是作者（秦凯新）平时工作的总结和升华，通过从真实商业环境抽取案例进行总结和分享，并给出商业应用的调优建议和集群环境容量规划等内容，请持续关注本套博客。期待加入IOT时代最具战斗力的团队。QQ邮箱地址：1120746959@qq.com，如有任何学术交流，可随时联系。
1 Kafka 0.11.0.0版本的逆天之作
0.11.0.0版本之前默认提供at least once语义，想象...
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
©️2022 CSDN
皮肤主题：技术黑板
设计师：CSDN官方博客
返回首页
不清不慎
CSDN认证博客专家
CSDN认证企业博客
码龄6年
暂无认证
174
原创
1万+
周排名
120万+
总排名
67万+
访问
等级
7782
积分
557
粉丝
403
获赞
142
评论
1792
收藏
私信
关注
热门文章
利用nginx搭建简单图片服务器实现负载均衡
30171
SpringBoot错误处理机制以及自定义异常处理
24969
Flume+Kafka+Spark Streaming实现大数据实时流式数据采集
20859
浅谈Kafka选举机制
19537
MongoDB主从集群、副本集与分片
19519
分类专栏
大数据
32篇
ClickHouse
1篇
ElasticSearch
1篇
区块链
1篇
truffle
1篇
SpringCloud
1篇
Lua
1篇
Go
Spark源码剖析与调优
16篇
Flink入门到精通
12篇
Java
30篇
Python
2篇
Scala
3篇
Java多线程
8篇
JavaScript
1篇
JVM
7篇
Linux
3篇
MySql
3篇
设计模式
2篇
Spark
35篇
Hadoop
7篇
Redis
5篇
ActiveMQ
2篇
Nginx
2篇
MongoDB
4篇
SpringBoot
6篇
Spring Web Flow
1篇
Netty
1篇
Servlet
2篇
算法
2篇
Dubbo
3篇
HDFS
3篇
Yarn
1篇
Mybatis
1篇
Hive
4篇
SpringMvc
5篇
SpringSecurity
2篇
Flume
4篇
HBase
2篇
机器学习
5篇
Kafka
6篇
Docker
4篇
Oozie
1篇
小项目
3篇
Storm
4篇
Flink
14篇
Zookeeper
3篇
分布式系统
10篇
面试总结
2篇
最新评论
Flink启动报错could not be determined automatically
陈淀薄发:
可以解决问题，但是应该还有更好的方案
ehcache缓存技术讲解
yirandand:
我将缓存手动clear之后再次带有@Cacheable的方法 会报错[code=java]
java.lang.IllegalStateException: The XXX Cache is not alive (STATUS_SHUTDOWN)
at net.sf.ehcache.Cache$CacheStatus.checkAlive(Cache.java:4097)
at net.sf.ehcache.Cache.checkStatus(Cache.java:2788)
at net.sf.ehcache.Cache.get(Cache.java:1744)
at org.springframework.cache.ehcache.EhCacheCache.lookup(EhCacheCache.java:163)
at org.springframework.cache.ehcache.EhCacheCache.get(EhCacheCache.java:72)
[/code]
找不到缓存
为什么找不到缓存他不会进入方法再执行一次，而是直接报错呢？
Spring Security实现RememberMe功能以及原理探究
不搞数学的汤老师:
”通过前几篇文章“ 前几篇文章呢。。。
Spring Security实现RememberMe功能以及原理探究
不搞数学的汤老师:
”通过前几篇文章“ 前几篇文章呢。。。
Redis主从集群切换数据丢失问题
帝国守夜者-施瑙菲尔:
说的很明白！
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
ClickHouse创建mysql数据库引擎报错【Code: 501】
ElasticSearch使用Java API进行索引文档的操作
美团，滴滴，蘑菇街Java大数据面经分享
2020年7篇
2019年46篇
2018年98篇
2017年24篇
目录
目录
分类专栏
大数据
32篇
ClickHouse
1篇
ElasticSearch
1篇
区块链
1篇
truffle
1篇
SpringCloud
1篇
Lua
1篇
Go
Spark源码剖析与调优
16篇
Flink入门到精通
12篇
Java
30篇
Python
2篇
Scala
3篇
Java多线程
8篇
JavaScript
1篇
JVM
7篇
Linux
3篇
MySql
3篇
设计模式
2篇
Spark
35篇
Hadoop
7篇
Redis
5篇
ActiveMQ
2篇
Nginx
2篇
MongoDB
4篇
SpringBoot
6篇
Spring Web Flow
1篇
Netty
1篇
Servlet
2篇
算法
2篇
Dubbo
3篇
HDFS
3篇
Yarn
1篇
Mybatis
1篇
Hive
4篇
SpringMvc
5篇
SpringSecurity
2篇
Flume
4篇
HBase
2篇
机器学习
5篇
Kafka
6篇
Docker
4篇
Oozie
1篇
小项目
3篇
Storm
4篇
Flink
14篇
Zookeeper
3篇
分布式系统
10篇
面试总结
2篇
目录
评论
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
打赏作者
不清不慎
你的鼓励将是我创作的最大动力
¥2
¥4
¥6
¥10
¥20
输入1-500的整数
余额支付
(余额：-- )
扫码支付
扫码支付：¥2
获取中
扫码支付
您的余额不足，请更换扫码支付或充值
打赏作者
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。
余额充值