<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kafka on Zhuifeng Notes</title><link>https://4f0a9a3b.wangpeng.pages.dev/en/tech/kafka/</link><description>Recent content in Kafka on Zhuifeng Notes</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 25 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://4f0a9a3b.wangpeng.pages.dev/en/tech/kafka/index.xml" rel="self" type="application/rss+xml"/><item><title>Kafka Storage and Consumption Model</title><link>https://4f0a9a3b.wangpeng.pages.dev/en/tech/kafka/storage-consumer/</link><pubDate>Tue, 25 Aug 2026 00:00:00 +0000</pubDate><guid>https://4f0a9a3b.wangpeng.pages.dev/en/tech/kafka/storage-consumer/</guid><description>&lt;p&gt;Kafka&amp;rsquo;s high performance relies on &amp;ldquo;partitioned log + sequential writes + batched pulls&amp;rdquo;. Understanding the storage and consumption model is essential to configure parallelism correctly and avoid duplicate consumption.&lt;/p&gt;&#10;&lt;h2 id="topics-and-partitions"&gt;Topics and Partitions&#10;&lt;/h2&gt;&#10;&lt;ul&gt;&#10;&lt;li&gt;A &lt;strong&gt;topic&lt;/strong&gt; is a logical subject; a &lt;strong&gt;partition&lt;/strong&gt; is the physical unit of parallelism, and messages are only appended to the end of a partition.&lt;/li&gt;&#10;&lt;li&gt;Each partition is an ordered, immutable log composed of multiple segment files, maintaining an offset (unique and monotonically increasing within the partition).&lt;/li&gt;&#10;&lt;li&gt;The partition count determines the upper bound of consumption parallelism: at any moment a partition is consumed by exactly one consumer within a group.&lt;/li&gt;&#10;&lt;/ul&gt;&#10;&lt;h2 id="offset-and-consumption-position"&gt;Offset and Consumption Position&#10;&lt;/h2&gt;&#10;&lt;p&gt;The position a consumer commits after processing messages is the &lt;strong&gt;offset&lt;/strong&gt;, which Kafka stores in the internal topic &lt;code&gt;__consumer_offsets&lt;/code&gt;:&lt;/p&gt;</description></item><item><title>Kafka Reliability and Exactly-Once</title><link>https://4f0a9a3b.wangpeng.pages.dev/en/tech/kafka/reliability/</link><pubDate>Tue, 25 Aug 2026 00:00:00 +0000</pubDate><guid>https://4f0a9a3b.wangpeng.pages.dev/en/tech/kafka/reliability/</guid><description>&lt;p&gt;Kafka&amp;rsquo;s reliability requires coordinated configuration across the producer, broker and consumer. We cover it through three goals: no loss, no duplication, ordered.&lt;/p&gt;&#10;&lt;h2 id="producer-side-reliability"&gt;Producer-Side Reliability&#10;&lt;/h2&gt;&#10;&lt;p&gt;Control write durability level via &lt;code&gt;acks&lt;/code&gt;:&lt;/p&gt;&#10;&lt;ul&gt;&#10;&lt;li&gt;&lt;code&gt;acks=0&lt;/code&gt;: considered successful as soon as sent; may lose messages; highest throughput.&lt;/li&gt;&#10;&lt;li&gt;&lt;code&gt;acks=1&lt;/code&gt;: success once the leader writes; may lose if the leader crashes.&lt;/li&gt;&#10;&lt;li&gt;&lt;code&gt;acks=all&lt;/code&gt;: success only after all ISR replicas sync; safest, combined with &lt;code&gt;min.insync.replicas&lt;/code&gt; to avoid single points.&lt;/li&gt;&#10;&lt;/ul&gt;&#10;&lt;p&gt;Enabling retries (&lt;code&gt;retries&lt;/code&gt;) handles transient failures but introduces &lt;strong&gt;duplicates&lt;/strong&gt;: network jitter causes the producer to retry without receiving the ack, writing the same message twice.&lt;/p&gt;</description></item></channel></rss>