漫游Kafka设计篇之数据持久化

简介:

转载注明出处:http://blog.csdn.net/honglei915/article/details/37564595

不要畏惧文件系统!

Kafka大量依赖文件系统去存储和缓存消息。对于硬盘有个传统的观念是硬盘总是非常慢,这使非常多人怀疑基于文件系统的架构是否能提供优异的性能。实际上硬盘的快慢全然取决于使用它的方式。设计良好的硬盘架构能够和内存一样快。


在6块7200转的SATA RAID-5磁盘阵列的线性写速度差点儿相同是600MB/s,可是随即写的速度却是100k/s,差了差点儿相同6000倍。现代的操作系统都对次做了大量的优化,使用了 read-ahead 和 write-behind的技巧,读取的时候成块的预读取数据。写的时候将各种微小琐碎的逻辑写入组织合并成一次较大的物理写入。对此的深入讨论能够查看这里,它们发现线性的訪问磁盘,非常多时候比随机的内存訪问快得多。


为了提高性能。现代操作系统往往使用内存作为磁盘的缓存。现代操作系统乐于把全部空暇内存用作磁盘缓存。尽管这可能在缓存回收和又一次分配时牺牲一些性能。全部的磁盘读写操作都会经过这个缓存,这不太可能被绕开除非直接使用I/O。所以尽管每一个程序都在自己的线程里仅仅缓存了一份数据。但在操作系统的缓存里另一份。这等于存了两份数据。
另外再来讨论一下JVM,下面两个事实是众所周知的:

  • Java对象占用空间是很大的,差点儿相同是要存储的数据的两倍甚至更高。
  • 随着堆中数据量的添加,垃圾回收回变的越来越困难。

基于以上分析。假设把数据缓存在内存里,由于须要存储两份,不得不使用两倍的内存空间,Kafka基于JVM。又不得不将空间再次加倍,再加上要避免GC带来的性能影响,在一个32G内存的机器上,不得不使用到28-30G的内存空间。而且当系统重新启动的时候,又必须要将数据刷到内存中( 10GB 内存差点儿相同要用10分钟),就算使用冷刷新(不是一次性刷进内存。而是在使用数据的时候没有就刷到内存)也会导致最初的时候新能很慢。可是使用文件系统,即使系统重新启动了,也不须要刷新数据。使用文件系统也简化了维护数据一致性的逻辑。


所以与传统的将数据缓存在内存中然后刷到硬盘的设计不同。Kafka直接将数据写到了文件系统的日志中。

常量时间的操作效率

在大多数的消息系统中,数据持久化的机制往往是为每一个cosumer提供一个B树或者其它的随机读写的数据结构。B树当然是非常棒的,可是也带了一些代价:比方B树的复杂度是O(log N),O(log N)通常被觉得就是常量复杂度了。但对于硬盘操作来说并不是如此。磁盘进行一次搜索须要10ms,每一个硬盘在同一时间仅仅能进行一次搜索。这样并发处理就成了问题。尽管存储系统使用缓存进行了大量优化。可是对于树结构的性能的观察结果却表明,它的性能往往随着数据的增长而线性下降,数据增长一倍,速度就会减少一倍。


直观的讲,对于主要用于日志处理的消息系统。数据的持久化能够简单的通过将数据追加到文件里实现,读的时候从文件里读就好了。这样做的优点是读和写都是 O(1) 的,而且读操作不会堵塞写操作和其它操作。这样带来的性能优势是非常明显的。由于性能和数据的大小没有关系了。


既然能够使用差点儿没有容量限制(相对于内存来说)的硬盘空间建立消息系统,就能够在没有性能损失的情况下提供一些一般消息系统不具备的特性。比方。一般的消息系统都是在消息被消费后马上删除,Kafka却能够将消息保存一段时间(比方一星期),这给consumer提供了非常好的机动性和灵活性,这点在今后的文章中会有详述。




本文转自mfrbuaa博客园博客,原文链接:http://www.cnblogs.com/mfrbuaa/p/5180320.html,如需转载请自行联系原作者

相关文章
|
2月前
|
消息中间件 存储 运维
为什么说Kafka还不是完美的实时数据通道
【10月更文挑战第19天】Kafka 虽然作为数据通道被广泛应用,但在实时性、数据一致性、性能及管理方面存在局限。数据延迟受消息堆积和分区再平衡影响;数据一致性难以达到恰好一次;性能瓶颈在于网络和磁盘I/O;管理复杂性涉及集群配置与版本升级。
103 1
|
2月前
|
消息中间件 Java Kafka
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
61 1
|
4月前
|
消息中间件 Java Kafka
Kafka不重复消费的终极秘籍!解锁幂等性、偏移量、去重神器,让你的数据流稳如老狗,告别数据混乱时代!
【8月更文挑战第24天】Apache Kafka作为一款领先的分布式流处理平台,凭借其卓越的高吞吐量与低延迟特性,在大数据处理领域中占据重要地位。然而,在利用Kafka进行数据处理时,如何有效避免重复消费成为众多开发者关注的焦点。本文深入探讨了Kafka中可能出现重复消费的原因,并提出了四种实用的解决方案:利用消息偏移量手动控制消费进度;启用幂等性生产者确保消息不被重复发送;在消费者端实施去重机制;以及借助Kafka的事务支持实现精确的一次性处理。通过这些方法,开发者可根据不同的应用场景灵活选择最适合的策略,从而保障数据处理的准确性和一致性。
354 9
|
4月前
|
vr&ar 图形学 开发者
步入未来科技前沿:全方位解读Unity在VR/AR开发中的应用技巧,带你轻松打造震撼人心的沉浸式虚拟现实与增强现实体验——附详细示例代码与实战指南
【8月更文挑战第31天】虚拟现实(VR)和增强现实(AR)技术正深刻改变生活,从教育、娱乐到医疗、工业,应用广泛。Unity作为强大的游戏开发引擎,适用于构建高质量的VR/AR应用,支持Oculus Rift、HTC Vive、Microsoft HoloLens、ARKit和ARCore等平台。本文将介绍如何使用Unity创建沉浸式虚拟体验,包括设置项目、添加相机、处理用户输入等,并通过具体示例代码展示实现过程。无论是完全沉浸式的VR体验,还是将数字内容叠加到现实世界的AR应用,Unity均提供了所需的一切工具。
170 0
|
4月前
|
消息中间件 存储 关系型数据库
实时计算 Flink版产品使用问题之如何使用Kafka Connector将数据写入到Kafka
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
4月前
|
消息中间件 监控 Kafka
实时计算 Flink版产品使用问题之处理Kafka数据顺序时,怎么确保事件的顺序性
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
4月前
|
消息中间件 缓存 Kafka
【Azure 事件中心】使用Kafka消费Azure EventHub中数据,遇见消费慢的情况可以如何来调节呢?
【Azure 事件中心】使用Kafka消费Azure EventHub中数据,遇见消费慢的情况可以如何来调节呢?
|
4月前
|
消息中间件 SQL Java
实时数仓 Hologres产品使用合集之如何用python将kafka数据写入
实时数仓Hologres是阿里云推出的一款高性能、实时分析的数据库服务,专为大数据分析和复杂查询场景设计。使用Hologres,企业能够打破传统数据仓库的延迟瓶颈,实现数据到决策的无缝衔接,加速业务创新和响应速度。以下是Hologres产品的一些典型使用场景合集。
|
4月前
|
消息中间件 Kafka Apache
流计算引擎数据问题之Apache Kafka Streams 没有采用低水印方案如何解决
流计算引擎数据问题之Apache Kafka Streams 没有采用低水印方案如何解决
61 0
|
4月前
|
消息中间件 缓存 Kafka
图解Kafka:架构设计、消息可靠、数据持久、高性能背后的底层原理
【8月更文挑战第15天】在构建高吞吐量和高可靠性的消息系统时,Apache Kafka 成为了众多开发者和企业的首选。其独特的架构设计、消息可靠传输机制、数据持久化策略以及高性能实现方式,使得 Kafka 能够在分布式系统中大放异彩。本文将通过图解的方式,深入解析 Kafka 的这些核心特性,帮助读者更好地理解和应用这一强大的消息中间件。
194 0