138 Matching Annotations
  1. May 2025
  2. Apr 2025
    1. 可见,副本读取状态有截断中和获取中两个:当副本执行截断操作时,副本状态被设置成 Truncating;当副本被读取时,副本状态被设置成 Fetching。

      就是当前副本的状态,是否可以去Fetch,如果当前在截断中,就不能Fetch,而如果被delay了同理

    2. highWatermark

      各副本已经同步的消息offset, HW leader节点从所有的副本中获取LEO,取最小的LEO做HW,HW为所有已经成功写入全部副本的消息的最新位置。Follower的HW则是他的LEO和leader的HW的较小值

    1. 这是社区为了规避因多线程访问产生锁争用导致线程阻塞,从而引发请求超时问题而做的努力

      解决的问题

      当多线程同时执行该方法进行检查的时候,拿到锁的线程complete失败,而没拿到锁的线程直接跳过,那么如果没有其他线程再去处理的话,就永远也不会complete。

      如何解决?

      如果第一个线程成功将retry设置为false,那么第二个线程就会进行重试,而如果本身retry就是true,那么说明被其他线程先一步设置了,该线程不重试。但是如果多个线程顺序执行,都完成不了,那不是一样?

    2. bucket.flush(reinsert)

      相当于重新添加进时间轮,但是如果已经到了时间,那么就会执行。而且由于时间轮向后滚动,如果是最下面一级的bucket则所有元素都会过期,而上一级的bucket则会往下一级插入.

      由于DelayQueue的存在,时间复杂度和直接使用DelayQueue有什么不同?

      首先是以bucket为单位写入DelayQueue,bucket通过分层,使得每一层只有20个bucket,那么n层就只有n*20个bucket,大大减少了DelayQueue元素的数量,减小时间复杂度。

    1. 选择存活副本列表的第一个副本作为 Leader;选择存活副本列表作为 ISR

      NewPartition状态的分区,进行初始化(因为是初始化,所以数据都为空),会将存活副本设置为ISR,而将ISR第一个设置为Leader

    2. 实际上消息队列都是以分区为单位组织的。而一个topic拥有多个分区,客户端可以根据一定的规则(Partitioner)往这多个分区中写入数据,而消费者则通过一定规则或者随机分配到部分partition,从partition中顺序进行消费

    1. 代码会给所有符合状态转换的副本所在的 Broker,发送 StopReplicaRequest 请求,显式地告诉这些 Broker 停掉其上的对应副本。Kafka 的副本管理器组件(ReplicaManager)负责处理这个逻辑。后面我们会用两节课的时间专门讨论 ReplicaManager 的实现,这里你只需要了解,StopReplica 请求被发送出去之后,这些 Broker 上对应的副本就停止工作了。

      Kafka如何保证请求发送后能够按预期执行?

      通过重试兜底保证最终一致性?同时如果主从切换的话,会进行检查然后重新进行状态同步

    2. Controller给Broker发送请求是否需要保证Broker变更成功

      不需要,Controller发送请求后会异步的等待broker心跳中包含的响应。同时由于MQ本身的设计能够进行容错,即旧的状态如果不对,那么会进行重试,或者刷新缓存元数据

    3. 源码会获取对应分区的详细数据,然后向该副本对象所在的 Broker 发送 LeaderAndIsrRequest 请求,令其同步获知,并保存该分区数据。

      为什么不是NewReplica状态就可以直接让其他broker同步?

      因为最前面判定了validReplicas,所以这些状态的变更都是允许的

    1. 日志是如何清理的呢?

      1. deletion策略,正常情况下,根据日志的配置,自动进行最大留存时间、最大留存大小的清理,以segment为单位,具体看kafka-log-retention任务
      2. compaction策略,topic可以设置compaction策略为compaction、delete + compaction,这样的话LogCleaner会定时进行compaction。优化策略,segments氛围cleaned和uncleaned,从uncleaned中遍历消息(在逻辑中可以根据需求读取需要的大小以节省内存)构建offsetMap来存储这一段中最新的key的offset,而从头遍历segments,清理掉offsetMap中已有的已有的消息(也就是最新消息)
    2. (validBytes - lastIndexEntry > indexIntervalBytes)

      recover过程中会重置索引,然后遍历每个batch来添加索引项,这样就能避免掉原本写入消息时,一次性写入的多batch的消息最多只写入一次索引导致查询效率低的问题

    3. 因为目前 Broker 端日志段新增倒计时是全局设置,这就是说,在未来的某个时刻可能同时创建多个日志段对象,这将极大地增加物理磁盘 I/O 压力。有了 rollJitterMs 值的干扰,每个新增日志段在创建时会彼此岔开一小段时间,这样可以缓解物理磁盘的 I/O 负载瓶颈。

      配置topic的segment.jitter.ms或者segment.ms让segment根据时间自动滚动时错峰,避免io压力过大

      即使segment的数据量不大,超过固定时间(默认一周)没写入数据,也会滚动segment,那如果很多segment都没写入的话,那么就会同时创建segment导致大量的io占用 rollJitterMs则是一个随机的扰动值,来源于{@link LogConfig#randomSegmentJitter()}, 通过这个值可以将segment滚动的时间错开,缓解物理磁盘的 I/O 负载瓶颈

  3. Mar 2025
    1. 但是为什么 AbstractFetcherThread 线程总要不断尝试去做截断呢?这是因为,分区的 Leader 可能会随时发生变化。每当有新 Leader 产生时,Follower 副本就必须主动执行截断操作,将自己的本地日志裁剪成与 Leader 一模一样的消息序列,甚至,Leader 副本本身也需要执行截断操作,将 LEO 调整到分区高水位处。

      当leader变更时,follower需要truncate自己的日志来保证与leader一致,而leader切换的时候,自身也需要truncate到HW来保持数据的一致性,但是这样会丢消息,当然如果没有到HW,那么需要所有节点同步的消息应该收不到回复

  4. Jan 2025
    1. How Tesla is using Kubernetes and Kafka to handle trillions of events per day
      • Overview of Tesla's Data Infrastructure Challenges:

        • Modern Tesla vehicles generate an enormous volume of telemetry data related to sensor readings, driver behavior, energy consumption, and more.
        • The primary challenge is ingesting, processing, and analyzing this data at scale while maintaining real-time capabilities.
      • Kubernetes for Orchestration:

        • Tesla uses Kubernetes to manage containerized microservices across a distributed cloud environment.
        • Kubernetes ensures dynamic scaling to handle fluctuating workloads, providing high availability for critical services.
        • Each microservice is encapsulated in its own container, improving isolation and deployability.
      • Kafka for Real-Time Event Streaming:

        • Apache Kafka is the backbone of Tesla’s data pipeline, managing trillions of events daily from globally distributed vehicles.
        • Kafka topics are structured to partition and replicate data efficiently, ensuring fault tolerance and high throughput.
        • Producers (vehicles) send data to Kafka brokers, while consumers (analytics systems, data lakes) process these streams in real-time.
      • Data Processing Pipelines:

        • Data from Kafka is ingested into processing systems for real-time analytics, anomaly detection, and predictive maintenance.
        • Stream processing frameworks (e.g., Apache Flink or Kafka Streams) analyze data for immediate feedback.
        • Batch systems handle aggregation and storage in Tesla’s data lake for long-term insights.
      • Key Technical Advantages:

        • Scalability: Kubernetes dynamically allocates resources based on the volume of incoming data and computational requirements.
        • Resilience: Kafka’s replication factor ensures that no single broker failure impacts the system.
        • Low Latency: Data streams from Kafka enable Tesla to act on insights in milliseconds, critical for safety and performance monitoring.
      • Simplified Management:

        • The platform supports multi-cluster Kubernetes configurations for geographic data segregation.
        • A central control plane monitors system health, manages deployments, and ensures compliance with data regulations.
      • Future Goals and Improvements:

        • Enhancing AI-driven analytics to derive deeper insights from vehicle data.
        • Further optimizing Kafka’s cluster topology to improve fault tolerance and reduce operational costs.
        • Expanding edge processing capabilities in vehicles to pre-filter data, reducing bandwidth requirements to the cloud.
  5. Aug 2023
    1. Replication

      leaders&followers leader commits log with an epoch(indicates generation of lifetime of a log) follower fetch with offset no to sync with leader leader reponds with new record logs with epoch in the next fetch request, leader moves high watermark based on offset in request (n-1) in that response it passes the high watermark to the follower

    1. course

      how data is received client -> socket -> n/w thread(lightweight) -> req queue -> i/o thread(crc check & append to commit log[.index and .log file]) -> resp queue -> n/w-> socket

      purgatory map -> used for req until data is replicated

      how data is fetched client -> socket -> n/w -> req queue -> i/o thread (fetch ranges are calcualted with .index) -> res queue -> n/w -> socket

      purgatory map -> waits until is arrived based on consumer config

      also follows zero copy - meaning data fetched from file directly to n/w thread - mostly page cached

      if not cached -> may need to use tiered storage

  6. May 2023
    1. Today is 9th Feb. The oldest segment – segment 100 – still can’t be deleted by the 7-day topic retention policy, because the most recent message in that segment is only 5 days old. The result is that they can see messages dating back to 28th January on this topic, even though the 28th Jan is now 12 days ago. In a couple of days, all the messages in segment 100 will be old enough to exceed the retention threshold so that segment file will be deleted.

      retention.ms set to 7 days doesn't guarantee that you will only see topic messages from the last 7 days. Think of it as a threshold that the Kafka broker can use to decide when messages are eligible for being automatically deleted.

  7. Mar 2023
  8. Feb 2023
    1. The Bitnami Apache Kafka docker image disables the PLAINTEXT listener for security reasons. You can enable the PLAINTEXT listener by adding the next environment variable, but remember that this configuration is not recommended for production.

      production note

  9. Dec 2022
  10. Aug 2022
  11. Mar 2022
  12. Sep 2021
    1. Kafka consumer — A program you write to get data out of Kafka. Sometimes a consumer is also a producer, as it puts data elsewhere in Kafka.

      Simple Kafka consumer terminology

    2. Kafka topic — A category to which records are published. Imagine you had a large news site — each news category could be a single Kafka topic.

      Simple Kafka topic terminology

    3. Kafka broker — A single Kafka Cluster is made of Brokers. They handle producers and consumers and keeps data replicated in the cluster.

      Simple Kafka broker terminology

    4. Kafka — Basically an event streaming platform. It enables users to collect, store, and process data to build real-time event-driven applications. It’s written in Java and Scala, but you don’t have to know these to work with Kafka. There’s also a Python API.

      Simple Kafka terminology

  13. Oct 2020
    1. User topics must be created and manually managed ahead of time

      Javadoc says: "should be created".

      The reason is: Auto-creation of topics may be disabled in your Kafka cluster. Auto-creation automatically applies the default topic settings such as the replicaton factor. These default settings might not be what you want for certain output topics (e.g., auto.create.topics.enable=true in the Kafka broker configuration).

  14. Jun 2020
  15. Apr 2020
  16. Feb 2020
  17. Jul 2019
    1. Macksey is also responsible for one of his first short films. “When I was at Hopkins, there was no film program. We talked to Dick [about making a short film] and he said ‘let’s do it,’ and we ended up doing a movie in which he has a small part.”

      The short black and white film of just a few minutes was called Fratricide and is based on the Franz Kafka story A Fratricide.

      <small>Caleb Deschanel on the set of Fratricide. This may likely have been his first DP job circa ’66 while a student at Johns Hopkins. Photo courtesy of classmate Henry James Korn.</small>

  18. Feb 2018
  19. Jan 2018
    1. “It would be useless to give him that information. He experiences it on his own body.

      But hasn't the Condemned Man already experienced this subjection and degradation in his body? (like a vandalized house) The inscription of it on his body simply embodies what has already been true.

    2. “That’s cotton wool?” asked the Traveler and bent down. “Yes, it is,” said the Officer smiling, “feel it for yourself.”

      Kafka keeps bringing our attention to the cotton, perhaps to ensure we recognize the historical implications?

    3. the administration of the colony was so self-contained that even if his successor had a thousand new plans in mind, he would not be able to alter anything of the old plan, at least not for several years.

      Horrifying.

    4. vacant-looking man with a broad mouth and dilapidated hair and face

      The descriptors "Vacant-looking" and "dilapidated" summon up imagery of haunted houses and manors left in ruin rather than people. These terms are primarily used to describe things, not people.

      Why then is our "Condemned" an empty house? What has pushed him from subject to object in this way?

    5. Then the Traveler heard a cry of rage from the Officer.

      How does affect work in this tale? What kinds of feelings are evoked in whom by what kinds of stimuli? What do these eruptions of feeling tell us about the unspoken value system that undergirds this society?

    6. That gave rise to certain technical difficulties with fastening the needles securely, but after several attempts we were successful. We didn’t spare any efforts. And now, as the inscription is made on the body, everyone can see through the glass. Don’t you want to come closer and see the needles for yourself.”

      Why glass? Given that the Apparatus is a mere tool, an agent of "justice," why such pains to make its workings visible? Why talk about it so much?

    7. The Traveler wanted to raise various questions, but after looking at the Condemned Man he merely asked, “Does he know his sentence?” “No,” said the Officer. He wished to get on with his explanation right away, but the Traveler interrupted him: “He doesn’t know his own sentence?” “No,” said the Officer once more. He then paused for a moment, as if he was asking the Traveler for a more detailed reason for his question, and said, “It would be useless to give him that information. He experiences it on his own body.”

      How you you read this crucial moment? Who knows what in this story, and how does Kafka exploit the lack of symmetry between Commandant, Officer, Traveler, Condemned, and so on?

    8. “He was indeed,” said the Officer, nodding his head with a fixed and thoughtful expression. Then he looked at his hands, examining them. They didn’t seem to him clean enough to handle the diagrams. So he went to the bucket and washed them again. Then he pulled out a small leather folder and said, “Our sentence does not sound severe. The law which a condemned man has violated is inscribed on his body with the harrow. This Condemned Man, for example,” and the Officer pointed to the man, “will have inscribed on his body, ‘Honour your superiors.’”

      Alas, the double entendre of "sentence" as a grammatical and legal entity at once is not active in German, but the slippage certainly fits here!

    9. “However,” the Officer said, interrupting himself, “I’m chattering, and his apparatus stands here in front of us. As you see, it consists of three parts. With the passage of time certain popular names have been developed for each of these parts. The one underneath is called the bed, the upper one is called the inscriber, and here in the middle, this moving part is called the harrow.” “The harrow?” the Traveler asked. He had not been listening with full attention. The sun was excessively strong, trapped in the shadowless valley, and one could hardly collect one’s thoughts. So the Officer appeared to him all the more admirable in his tight tunic weighed down with epaulettes and festooned with braid, ready to go on parade, as he explained the matter so eagerly and, while he was talking, adjusted screws here and there with a screwdriver.

      What's the effect of Kafka's use of abstraction here? Those who know his other works are perhaps used to this stylistic feature, but why the abstract titles/names, from Commandant to Traveler to apparatus?

  20. Nov 2017
  21. Jul 2017
    1. up vote 7 down vote accepted When you are starting your kafka broker you can define set of properties in conf/server.properties file. This file is just key value property file. One of the property is auto.create.topics.enable if it set tot true(by default) kafka will create topic automatically when you send message to non existing topic. All config options you can find here Imho Simple rule for creating topics is the following: number of replicas must be not less than number of nodes that you have. Number of topics must be the multiplier of number of node in your cluster for example: You have 9 node cluster your topic must have 9 partitions and 9 replicas or 18 partitions and 9 replicas or 36 partitions and 9 replicas and so on

      Number of replicas = #replicas Number of nodes = #nodes Number of topics = #topic

      replicas >= #nodes

      k x (#topics) = #nodes

  22. Jun 2017
    1. A better alternative is at least once message delivery. For at least once delivery, the consumer reads data from a partition, processes the message, and then commits the offset of the message it has processed. In this case, the consumer could crash between processing the message and committing the offset and when the consumer restarts it will process the message again. This leads to duplicate messages in downstream systems but no data loss.

      This is what SECOR does.

    2. By electing a new leader as soon as possible messages may be dropped but we will minimized downtime as any new machine can be leader.

      two scenarios to get the leader back: 1.) Wait to bring the master back online. 2.) Or elect the first node that comes back up. But in this scenario if that replica partition was a bit behind the master then the time from when this replica went down to when the master went down. All that data is Lost.

      SO there is a trade off between availability and consistency. (Durability)

    1. On every received heartbeat, the coordinator starts (or resets) a timer. If no heartbeat is received when the timer expires, the coordinator marks the member dead and signals the rest of the group that they should rejoin so that partitions can be reassigned. The duration of the timer is known as the session timeout and is configured on the client with the setting session.timeout.ms. 

      Time to live for the consumers. If the heartbeat doesn't reach the co-ordindator in this duration then the co-ordinator redistributes the partitions to the remaining consumers in the consumer group.

    1. An index can potentially store a large amount of data that can exceed the hardware limits of a single node. For example, a single index of a billion documents taking up 1TB of disk space may not fit on the disk of a single node or may be too slow to serve search requests from a single node alone.

      Indexes may overflow the disk space. Hence you want to get the most out of your instances by indexing the nodes.

  23. May 2017
    1. The Kafka cluster retains all published records—whether or not they have been consumed—using a configurable retention period. For example, if the retention policy is set to two days, then for the two days after a record is published, it is available for consumption, after which it will be discarded to free up space. Kafka's performance is effectively constant with respect to data size so storing data for a long time is not a problem.

      irrespective of the fact that the consumer has consumed the message that message is kept in kafka for the entire retention policy duration.

      You can have two or more consumer groups: 1 -> real time 2 -> back up consumer group

    2. replication factor N, we will tolerate up to N-1 server failures without losing any records

      Replication Factor means number of nodes/brokers which could go down before we start losing data.

      So if you have a replication factor of 6 for a 11 node cluster, then you will be fault tolerant till 5 nodes go down. After that point you are going to loose data for a particular partition.

    3. Messages sent by a producer to a particular topic partition will be appended in the order they are sent. That is, if a record M1 is sent by the same producer as a record M2, and M1 is sent first, then M1 will have a lower offset than M2 and appear earlier in the log.

      ordering is guaranteed.

    4. Consumers label themselves with a consumer group name, and each record published to a topic is delivered to one consumer instance within each subscribing consumer group. Consumer instances can be in separate processes or on separate machines.

      kafka takes care of the consumer groups. Just create one Consumer Group for each topic.

    1. The first limitation is that each partition is physically represented as a directory of one or more segment files. So you will have at least one directory and several files per partition. Depending on your operating system and filesystem this will eventually become painful. However this is a per-node limit and is easily avoided by just adding more total nodes in the cluster.

      total number of topics supported depends on the total number of partitions per topic.

      partition = directory of 1 or more segment files This is a per node limit

    1. For a topic with replication factor N, we will tolerate up to N-1 server failures without losing any records committed to the log.

      for Eg for a given topic there are 11 brokers/servers and for each topic the replication factor is 6. That means the topic will start loosing data if more than 5 brokers go down.

    2. The way consumption is implemented in Kafka is by dividing up the partitions in the log over the consumer instances so that each instance is the exclusive consumer of a "fair share" of partitions at any point in time. This process of maintaining membership in the group is handled by the Kafka protocol dynamically. If new instances join the group they will take over some partitions from other members of the group; if an instance dies, its partitions will be distributed to the remaining instances.

      The coolest feature: this way all you need to do is add new consumers in a consumer group to auto scale per topic

    3. the only metadata retained on a per-consumer basis is the offset or position of that consumer in the log. This offset is controlled by the consumer: normally a consumer will advance its offset linearly as it reads records, but, in fact, since the position is controlled by the consumer it can consume records in any order it likes.

      partition offset maintained by kafka. Offset number is maintained so that if the consumer goes down nothing breaks.