最近看kafka源码，着实被它的客户端缓冲池技术优雅到了。忍不住要写篇文章赞美一下（哈哈）。注：本文用到的源码来自kafka2.2.2版本。背景当我们应用程序调用kafka客户端 producer发送消息的时候，在kafka客户端内部，会把属于同一个topic分区的消息先汇总起来，形成一个batch。真正发往kafka服务器的消息都是以batch为单位的。如下图所示：这么做的好处显而易见。客户端和
转载
2024-04-03 11:07:49
82阅读
1、Kafka的客户端缓冲机制 首先，先得给大家明确一个事情，那就是在客户端发送消息给kafka服务器的时候，一定是有一个内存缓冲机制的。也就是说，消息会先写入一个内存缓冲中，然后直到多条消息组成了一个Batch，才会一次网络通信把Batch发送过去。整个过程如下图所示： 2、内存缓冲造成的频繁GC问题 那么这种内存缓冲机制的本意，其实就是把多条消息组成一个Batch
转载
2024-02-26 14:36:45
71阅读
目录1、缓存策略2、Kafka特性3、Kafka实时数据缓存4、Kafka的优点5、kafka集群图解6、实时计算架构 1、缓存策略数据分析主要分为离线数据处理和实时数据处理：结构图大致如下： 离线数据处理流程图：一般是对历史数据进行处理 实时数据处理流程图： 由以上两个流程图可以发现，kafka是一种可用于处理实时数据的高吞吐量的分布式发布订阅消息系统：官
转载
2024-02-27 13:48:46
42阅读
页缓存技术 + 磁盘顺序写首先 Kafka 每次接收到数据都会往磁盘上去写，如下图所示： 那么在这里我们不禁有一个疑问了，如果把数据基于磁盘来存储，频繁的往磁盘文件里写数据，这个性能会不会很差?大家肯定都觉得磁盘写性能是极差的。但是实际上 Kafka 在这里有极为优秀和出色的设计，就是为了保证数据写入性能，首先 Kafka 是基于操作系统的页缓存来实现文件写入的。操作系统本身
转载
2024-05-17 15:41:30
41阅读
1.动机设计 kafka 初衷，作为统一平台处理大公司的实时数据。所以 必须具有如下特性：支持海量数据高吞吐量低延迟（实时性）支持分区，分布式容错2.持久化kafka 高度依赖 文件系统 存储和缓存消息。通过对磁盘的顺序读写，并借助 OS 层面的 页缓存（page cache），保证优于缓存在内存中或其他结构中。为何使用磁盘效率仍然很高：利用磁盘的顺序读写，操作一个文件，将数据追加到文件的末尾。相
转载
2024-05-01 20:14:45
82阅读
经常有人问的一个问题就是：Kafka broker到底是不是无状态的？网上有这样的说法：正常情况下consumer会在消费完一条消息后线性增加这个offset。当然，consumer也可将offset设成一个较小的值，重新消费一些消息。因为offet由consumer控制，所以Kafka broker是无状态的。。。。。。 我猜想作者的意思应该是说：broker不保存消费者的状态。如果从这个
转载
2024-03-23 12:56:25
49阅读
1.动机设计 kafka 初衷，作为统一平台处理大公司的实时数据。所以 必须具有如下特性：支持海量数据高吞吐量低延迟（实时性）支持分区，分布式容错 2.持久化kafka 高度依赖 文件系统 存储和缓存消息。通过对磁盘的顺序读写，并借助 OS 层面的 页缓存（page cache），保证优于缓存在内存中或其他结构中。为何使用磁盘效率仍然很高
转载
2024-03-15 12:48:30
17阅读
MetadataCache 是指 Broker 上的元数据缓存，这些数据是 Controller 通过 UpdateMetadataRequest 请求发送给 Broker 的。换句话说，Controller 实现了一个异步更新机制，能够将最新的集群信息广播给所有 Broker，Kafka 通过异步更新机制来保证所有 Broker 上的元数据缓
转载
2024-03-21 10:58:58
46阅读
kafka + sparkStreaming 有什么好处：1、解耦 2、缓冲 （系统之间解耦合、峰值压力缓冲、异步通信） kafka消息队列的特点：可靠性保证： 自己不丢数据，消费者不丢数据 消息系统的特点：生产者消费者模式 ，FIFO --partition内部是FIFO的，pa
转载
2024-04-24 13:01:06
28阅读
闲话Cache：始篇Caching（缓存）在现代的计算机系统中是一项最古老最基本的技术。它存在于计算机各种硬件和软件系统中，比如各种CPU, 存储系统（IBM ESS， EMC Symmetrix…），数据库，Web服务器，中间件等。它的一个重要的作用就是用于弥补不同速度的硬件之间的存取速度的差距，cache可以完全通过硬件实现（算法也是通过硬件实现的），也可以通过在更快硬件上通过软件控制来实现。
转载
2024-04-03 07:24:11
70阅读
kafka的设计从四方面进行了考量：吞吐量/延时 高吞吐量
消息持久化 高可用
负载均衡和故障转移 高可用
伸缩性 高伸缩性
吞吐量和延时写入消息kafka写入磁盘的速度很快，得益于他对磁盘的使用方式不同。虽然Kafka会持久化所有数据到磁盘，但本质上每次写入操作系统的其实只是把数据写入到操作系统的页缓存，然后由操作系统自行决定什么时候把页缓存数据写回磁盘。
转载
2024-08-07 08:05:04
46阅读
首先Kafka每次接收到数据都会往磁盘上去写，如下图所示。 如果把数据基于磁盘来存储，频繁的往磁盘文件里写数据，这个性能会不会很差？答案是肯定的。实际上Kafka在这里有极为优秀和出色的设计，就是为了保证数据写入性能，首先Kafka是基于操作系统的页缓存来实现文件写入的。Ø 操作系统本身有一层缓存，叫做page cache，是在内存里的缓存，我们也可以称之为os cache，意思就是操
转载
2024-03-18 11:34:39
118阅读
页缓存是操作系统实现的一种主要的磁盘缓存，以此用来减少对磁盘I/O的操作。具体来说，就是把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问。为了弥补性能上的差异 ，现代操作系统越来越多地将内存作为磁盘缓存，甚至会将所有可用的内存用途磁盘缓存，这样当内存回收时也几乎没有性能损失，所有对于磁盘的读写也将经由统一的缓存。当一个进程准备读取磁盘上的文件内容时，操作系统会先查看待读取的数据所在的页（
转载
2024-03-17 11:51:07
51阅读
@Cacheable 缓存说明：在支持Spring Cache的环境下，对于使用@Cacheable标注的方法，Spring在每次执行前都会检查Cache中是否存在相同key的缓存元素，如果存在就不再执行该方法，而是直接从缓存中获取结果进行返回，否则才会执行并将返回结果存入指定的缓存中。// @since 3.1 可以标注在方法上、类上 下同
@Target({ElementType.METH
转载
2024-04-15 15:03:53
43阅读
首先是
kafka与zookeeper集群的搭建我们已经完成了在上一节中。这一章我们主要来实现代码整合
Kafka，实现一个业务上的，从
kafka获取监听到数据以后的业务逻辑。 1、将
kafka整合到spring boot中<dependency>
<groupId>org.apache.
kafka</groupId>
<artifactId&
Kafka是高吞吐低延迟的高并发、高性能的消息中间件，在大数据领域有极为广泛的运用。配置良好的Kafka集群甚至可以做到每秒几十万、上百万的超高并发写入。那么Kafka到底是如何做到这么高的吞吐量和性能的呢？一、页缓存技术 + 磁盘顺序写首先Kafka每次接收到数据都会往磁盘上去写，为了保证数据写入性能，Kafka是基于操作系统的页缓存来实现文件写入的。 操作系统本身有一层缓存，叫做page ca
转载
2024-02-23 12:25:05
78阅读
KafkaProducer是多线程并发安全的，多线程环境下也不会导致数据错乱。//将消息添加到内存缓冲里去，RecordAccumulator组件负责的
RecordAccumulator.RecordAppendResult result = accumulator.append(tp, timestamp, serializedKey, serializedValue, interceptCa
转载
2024-03-25 18:25:17
43阅读
看到好些人在写更新缓存数据代码时，先删除缓存，然后再更新数据库，而后续的操作会把数据再装载的缓存中。然而，这个是逻辑是错误的。试想，两个并发操作，一个是更新操作，另一个是查询操作，更新操作删除缓存后，查询操作没有命中缓存，先把老数据读出来后放到缓存中，然后更新操作更新了数据库。于是，在缓存中的数据还是老的数据，导致缓存中的数据是脏的，而且还一直这样脏下去了。视图分析：写流程（更新策略）先淘汰 ca
转载
2023-08-30 12:58:17
104阅读
前言：为什么要有缓存更新策略呢？主要是因为把数据保存在缓存与数据库当中，如果对数据库数据做修改，缓存并不知道。也不会去更新，用户去查询的时候就查到了旧数据，造成数据的不一致。 缓存更新策略则是为了解决上述的问题。 文章目录内存剔除超时剔除主动更新业务场景 内存剔除说明
原本是Redis用来解决内存不足的问题，因为Reids是基于内存存储的，内存不像磁盘，内存是有限的。Redis内存会设置一个
转载
2023-07-08 01:38:11
106阅读
更新缓存的时候涉及两个问题：删除（del）还是 修改（set）？先操作数据库，还是 先操作缓存？组合起来就有四种情况：第一种情况：先删除缓存，后更新数据库如果删除缓存失败，则后面的操作都不会执行，没问题；如果删除缓存成功，更新数据库失败，则缓存与数据库不一致，但这种不一致会马上被修正，因而不影响，因为下一次请求缓存的时候发现缓存中没有，会从数据库重新加载；但是，又有一个问题出现了，在旧的缓存被删除
转载
2024-03-08 18:57:30
70阅读
