一、顺序写磁盘Kafka的producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。 kafka的整个设计中，Partition相当于一个非常长的数组，而Broker接收到的所有消息顺序写入这个大数组中。同时
原创
2022-10-12 18:18:53
447阅读
一、顺序写磁盘Kafka的producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。 kafka的整个设计中，Partition相当于一个非常长的数组，而Broker接收到的所有消息顺序写入这个大数组中。同时
原创
2022-10-12 18:18:52
278阅读
传统IO单机读磁盘 1.传统单机IO读取 2.DMA单机读磁盘 1.原来IO读取的时候当磁盘控制缓冲区满的时候会中断CPU改成中断DMA,只有内核空间的内容满的时候才会中断CPU。由原来多次中断cpu变成只中断一次CPU,提高了计算能力 3.网络IO读取 数据从单机IO读取到内核缓冲空间后会继续把数
原创
2023-08-18 11:36:15
100阅读
zookeeper作为去中心化的集群模式，消费者需要知道现在那些生产者(对于消费者而言，kafka就是生产者)是可用的。 如果没有zookeeper每次消费者在消费之前都去尝试连接生产者测试下是否连接成功，这样无法保证效率Replication & Leader election
转载
2024-03-15 21:09:57
40阅读
文章目录3.5、Kafka 高效读写数据3.5、Kafka 高效读写数据Kafka集群是分布式的，可以分区，并行能力
原创
2022-07-11 17:20:49
62阅读
如果请求的内存大于BufferPool中总共可用的内存，就需要额外增加内存，通过Deque的方法传入内存。free list的内存= free.size() * poolableSize， free list 的内存 + nonPooledAvailableMemory = 总共可用的内存。 先来看下它的属性：static final String WAIT_TIME_SENS
转载
2024-02-26 22:02:03
27阅读
kafka2.4之后,kafka提供了有限的读写分离,也就是说follower副本能够提供读服务 之前没有,因为读写分离适用于读负载很大,而写操作相对不频繁的场景.可kafka不属于这样的场景 同步机制:kafka采用pull 方式实现follwer的同步,因此Follwer与leader存在不一致性窗口,如果允许读follwer副本,就势必要处理消息滞后的问题生产者发送到broker里面的策略和
转载
2024-03-05 12:42:10
49阅读
一、MQ遵循投递消息先进先出原则
1.为什么MQ会产生消息顺序的问题?1.消费者集群;。 2. MQ服务端如果是集群; 单个消费者： 单个消费者情况下，MQ的队列会根据先进先出的原则，消费的顺序是不会打乱的、。I 当消费者集群： mq消费者订阅到同一个队列情况时，消费者会做均摊消费或者是公平消费。 有可能出现一下情况：单个消费者情况下，MQ的队列会根据先进先出的原则，消费的顺序是不会打乱的。2.队
转载
2024-02-20 11:44:01
1016阅读
在每个公司都会有大大小小的会议，不论什么岗位的员工都不可避免的需要参加会议，随着管理层级越高，参加的会议可能越多，今天说说提高会议效率的几个基本规则。。。
原创
2021-07-09 09:31:37
418阅读
kafka是一款高吞吐量的发布、订阅消息系统，在发送消息时，消息会被发送到对应的分区中，然后通过有序队列（ArrayDeque）来存储，所以如果要保证消息的顺序性，理论上只需要保证消息被发送到同一个分区即可。简单画一下，帮助理解，正常情况下，假如我们有两个消费者客户端，订阅了某一个topic，这个topic有两个分区，那么kafka分配时就会让一个消费端对应一个分区，发送消息时，消息也会被均匀的发
转载
2024-02-16 11:04:56
143阅读
顺序写磁盘Kafka 的消息是保存或缓存在磁盘上的，一般认为在磁盘上读写数据是会降低性能的，因为寻址会比较消耗时间，但是实际上，Kafka 的特性之一就是高吞吐率。 即使是普通的服务器，Kafka 也可以轻松支持每秒百万级的写入请求，超过了大部分的消息中间件，这种特性也使得 Kafka 在日志处理等海量数据场景广泛应用。 针对 Kafka 的基准测试可以参考，Apache Kafka 基准测试：每
原创
2022-07-22 21:16:28
340阅读
精确一次消息语义（Exactly-once semantics）是可以实现的：让我们看看Kafka是怎么实现的。 我很兴奋，我们到达了Kafka社区一直以来期待的令人激动的里程碑：我们在Apache Kafka 0.11 releas
kafka如何保证不丢消息ps:这篇文章自我感觉说的很大白话了！希望你们看过了之后能有收获。生产者丢失消息的情况生产者(Producer) 调用send方法发送消息之后，消息可能因为网络问题并没有发送过去。所以，我们不能默认在调用send方法发送消息之后消息消息发送成功了。为了确定消息是发送成功，我们要判断消息发送的结果。但是要注意的是 Kafka 生产者(Producer) 使用 send 方法
转载
2024-06-25 17:17:37
164阅读
对于一个复杂的分布式系统，如果没有丰富的经验和牛逼的架构能力，很难把系统做得简单易维护，我们都知道，一个软件的生命周期中，后期维护占了70%，所以系统的可维护性是极其重要的， kafka 能成为大数据领域的事实标准，很大原因是因为运维起来很方便简单，今天我们来看下 kafka 是怎么来简化运维操作的。kafka 使用多副本来保证消息不丢失，多副本就涉及到kafka的复制机制，在一个超大规模的集群中
转载
2024-04-01 16:06:05
24阅读
消息可靠保证1.消费端的保证消息可靠唯一可能导致消息丢失的情况，在消费端获取到了消息，自动提交了offset，让borker以为已经消费好了这个消息，实际上才开始准备消费这条消息，可能存在消费过程中消费者挂了，这条消息就会丢掉。这和Rabbit差不多，Kafak会自动提交offset，那么只要关闭自动提交offset，处理完成之后手动提交ack。就可以保证消息不丢失。可能消费完了，提交ack过程发
转载
2024-03-28 13:43:37
139阅读
1.消费端弄丢了数据唯一可能导致消费者弄丢数据的情况，就是说，你消费到了这个消息，然后消费者那边自动提交了 offset，让 Kafka 以为你已经消费好了这个消息，但其实你才刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢咯。这不是跟 RabbitMQ 差不多吗，大家都知道 Kafka 会自动提交 offset，那么只要关闭自动提交 offset，在处理完之后自己手动提交
转载
2024-03-26 09:36:25
50阅读
这个是MQ领域的基本问题，很多面试官也会问这样的问题，其实本质上还是问你使用消息队列如何保证幂等性的问题。比如RabbitMQ、RocketMQ、Kafka都有可能出现消息重复消费的问题，因为者问题通常不是MQ自己保证的，是由我们开发人员来保证的。举个Kafka怎样重复消费的例子： Kafka实际有个offset的概念，就是每个消息写进去，都有一个offset，代表消息的序号，然后consumer
转载
2024-03-28 13:10:08
50阅读
类型消息是否会重复消息是否会丢失优势劣势使用场景最多一次否是生产端发送消息后不用等待和处理服务端响应，消息发送速度会很快网络或服务端有问题会造成消息的丢失消息系统吞吐量大且对消息的丢失不敏感。例如，日志收集、用户行为收集等场景最少一次是否生产端发送消息后需要等待和处理服务端响应，如果失败会重试吞吐量较低，有重复发送的消息消息系统吞吐量一般，但是绝不能丢消息，对于重复消息不敏感有且仅有一次否否消息不
转载
2024-04-02 15:13:06
27阅读
首先我们知道在Kafka中一台kafka服务器就是一个broker。一个broker可以容纳多个topic。一个topic可以分为多个partition。一个partition有若干个副本（一个leader和若干个follower）。生产者发送数据的对象，以及消费者消费数据的对象都是leader。follower实时从leader中同步数据，保持和leader数据的同步。 leader发生故障时，
转载
2024-03-22 10:25:12
59阅读
Producer根据指定的partition方法（默认round-robin(轮询)、hash等），将消息发布到指定topic的partition里面；kafka集群接收到Producer发过来的消息后，将其持久化到硬盘，并保留消息指定时长（可配置），而不关注消息是否被消费；Consumer从kafka集群pull数据，并控制获取消息的offset。producer 的deliver guaran
转载
2024-02-16 17:57:40
73阅读
