Site updated: 2024-01-28 15:26:20

2024/01/rocketmq-kafka-sharding-replication/index.html

@@ -34,7 +34,7 @@
 <meta property="og:image" content="https://static.nullwy.me/kafka-architecture.png">
 <meta property="og:image" content="https://static.nullwy.me/kafka-kraft-mode.png">
 <meta property="article:published_time" content="2024-01-18T12:36:00.000Z">
-<meta property="article:modified_time" content="2024-01-28T07:22:30.039Z">
+<meta property="article:modified_time" content="2024-01-28T07:26:13.677Z">
 <meta property="article:author" content="nullwy">
 <meta property="article:tag" content="架构">
 <meta property="article:tag" content="可扩展性">
@@ -456,7 +456,7 @@ <h1 id="Kafka">Kafka</h1>
 </li>
 </ul>
 </li>
-<li><strong>复制策略</strong><sup class="footnote-ref"><a href="#fn14" id="fnref14">[14]</a></sup><sup class="footnote-ref"><a href="#fn15" id="fnref15">[15]</a></sup>：
+<li><strong>复制策略</strong>：
 <ul>
 <li><strong>复制单位</strong>：以分区为单位</li>
 <li><strong>复制系数</strong>：
@@ -467,9 +467,9 @@ <h1 id="Kafka">Kafka</h1>
 <li>推荐的复制系数的配置值是 &gt;= 3，通常配置为 <code>3</code>。复制系数配置为 &gt;= 3 的原因是，允许集群内同时发生一次计划内停机和一次计划外停机，配置为 <code>3</code> 是在避免消息丢失和过度复制之间的常见的权衡选择。HBase（基于 HDFS）和 Cassandra 等分布式存储系统默认的复制系数也是 <code>3</code>。</li>
 </ul>
 </li>
-<li><strong>副本更新传播策略</strong>：副本分为主从（leader-follower）两种角色，由一个 leader 和零到多个 follower 组成复制组，复制组内的分区数据保持同步。复制策略类似于微软的 PacificA 复制协议，Elasticsearch 的<a target="_blank" rel="noopener" href="https://www.elastic.co/guide/en/elasticsearch/reference/8.12/docs-replication.html">分片复制</a>也采用 PacificA 协议。
+<li><strong>副本更新传播策略</strong><sup class="footnote-ref"><a href="#fn14" id="fnref14">[14]</a></sup><sup class="footnote-ref"><a href="#fn15" id="fnref15">[15]</a></sup>：副本分为主从（leader-follower）两种角色，由一个 leader 和零到多个 follower 组成复制组，复制组内的分区数据保持同步。复制策略类似于微软的 PacificA 复制协议，Elasticsearch 的<a target="_blank" rel="noopener" href="https://www.elastic.co/guide/en/elasticsearch/reference/8.12/docs-replication.html">分片复制</a>也采用 PacificA 协议。
 <ul>
-<li>Kafka 动态维护<strong>同步副本集合</strong>（in-sync replica set），简称 <strong>ISR 集合</strong>。如果一个 follower 副本落后 leader 的时间超过 <code>replica.lag.time.max.ms</code> 配置值（Kafka 2.5 开始从默认 10 秒改为 30 秒），那么该 follower 副本会被认为是“不同步副本”（out-of-sync replica，OSR），会被<strong>移除</strong> ISR 集合。当不同步副本重新同步后，会被<strong>加回</strong>到 ISR 集合中。当 leader 所在的节点发生崩溃，ISR 集合中的一个 follower 会被 Controller 选举为新 leader。在消息 commit 之前必须保证 ISR 集合中的全部节点都完成同步复制。这种机制确保了只要 ISR 中有一个或者以上的 follower，一条被 commit 的消息就不会丢失。最小 ISR 集合大小由 Broker 端的配置项 <code>min.insync.replicas</code> 控制，默认值 <code>1</code>，即只需要 leader。如果同步副本小于 <code>min.insync.replicas</code>，尝试向 Broker 发送数据的生产者会收到 <code>NotEnoughReplicasException</code> 或 <code>NotEnoughReplicasAfterAppendException</code> 异常。</li>
+<li>Kafka 动态维护<strong>同步副本集合</strong>（in-sync replica set），简称 <strong>ISR 集合</strong>。如果一个 follower 副本落后 leader 的时间超过 <code>replica.lag.time.max.ms</code> 配置值（Kafka 2.5 开始从默认 10 秒改为 30 秒），那么该 follower 副本会被认为是“不同步副本”（out-of-sync replica，OSR），会被<strong>移出</strong> ISR 集合。当不同步副本重新同步后，会被<strong>加回</strong>到 ISR 集合中。当 leader 所在的节点发生崩溃，ISR 集合中的一个 follower 会被 Controller 选举为新 leader。在消息 commit 之前必须保证 ISR 集合中的全部节点都完成同步复制。这种机制确保了只要 ISR 中有一个或者以上的 follower，一条被 commit 的消息就不会丢失。最小 ISR 集合大小由 Broker 端的配置项 <code>min.insync.replicas</code> 控制，默认值 <code>1</code>，即只需要 leader。如果同步副本小于 <code>min.insync.replicas</code>，尝试向 Broker 发送数据的生产者会收到 <code>NotEnoughReplicasException</code> 或 <code>NotEnoughReplicasAfterAppendException</code> 异常。</li>
 <li>Producer 端的配置项 <code>acks</code>，用于控制在确认一个请求发送完成之前需要收到的反馈信息的数量。<code>min.insync.replicas</code> 配置项只有在 <code>acks=all</code> 时才生效。
 <ul>
 <li><code>acks=0</code>：表示 Producer 不等待 Broker 返回确认消息。</li>
@@ -545,7 +545,7 @@ <h1 id="参考资料">参考资料</h1>
 </li>
 <li id="fn13" class="footnote-item"><p>Kafka 文档 <a target="_blank" rel="noopener" href="https://kafka.apachecn.org/">https://kafka.apachecn.org/</a> <a target="_blank" rel="noopener" href="https://kafka.apache.org/36/documentation.html">https://kafka.apache.org/36/documentation.html</a> <a href="#fnref13" class="footnote-backref">↩︎</a></p>
 </li>
-<li id="fn14" class="footnote-item"><p>Kafka 文档：4. 设计思想：4.7 Replication <a target="_blank" rel="noopener" href="https://kafka1x.apachecn.org/documentation.html#replication">https://kafka1x.apachecn.org/documentation.html#replication</a> <a target="_blank" rel="noopener" href="https://kafka.apache.org/36/documentation.html#replication">https://kafka.apache.org/36/documentation.html#replication</a> <a href="#fnref14" class="footnote-backref">↩︎</a></p>
+<li id="fn14" class="footnote-item"><p>Kafka Documentation: 4.7 Replication <a target="_blank" rel="noopener" href="https://kafka1x.apachecn.org/documentation.html#replication">https://kafka1x.apachecn.org/documentation.html#replication</a> <a target="_blank" rel="noopener" href="https://kafka.apache.org/36/documentation.html#replication">https://kafka.apache.org/36/documentation.html#replication</a> <a href="#fnref14" class="footnote-backref">↩︎</a></p>
 </li>
 <li id="fn15" class="footnote-item"><p>2013-02 Jun Rao: Intra-cluster Replication in Apache Kafka <a target="_blank" rel="noopener" href="https://engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka">https://engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka</a> <a target="_blank" rel="noopener" href="https://www.slideshare.net/junrao/kafka-replication-apachecon2013">https://www.slideshare.net/junrao/kafka-replication-apachecon2013</a> <a href="#fnref15" class="footnote-backref">↩︎</a></p>
 </li>

posts/rocketmq-kafka-sharding-replication.md

@@ -95,15 +95,15 @@ RocketMQ 架构，以及各个 Borker 下的分区和副本分布示例，如下
   - **分片再均衡策略**：手动再均衡
     - 在扩容添加新 Broker 节点后，新的分区和分区副本能自动分配到新的 Broker 节点上，但已有的旧分区和节点的分配关系的固定的。如果要让旧的分区和分区副本能分配新的 Broker 节点，需要手动执行分区重分配命令 `kafka-reassign-partitions.sh`。
       - 相关源码：[ReassignPartitionsCommand](https://github.com/apache/kafka/blob/3.7.0-rc2/tools/src/main/java/org/apache/kafka/tools/reassign/ReassignPartitionsCommand.java)
-- **复制策略**[^14][^15]：
+- **复制策略**：
   - **复制单位**：以分区为单位
   - **复制系数**：
     - 自动创建 Topic 时，由配置项 `default.replication.factor` 全局控制 Topic 的默认副本个数，默认值 `1`。
     - 手动创建 Topic 时，执行 `kafka-topics.sh --create` 命令，由 `--replication-factor` 命令行参数控制该 Topic 的分区副本的复制系数。
     - 复制系数必须等于或小于可用 Broker 节点数，如果大于可用 Broker 节点数，在创建 Topic 时会报异常。
     - 推荐的复制系数的配置值是 >= 3，通常配置为 `3`。复制系数配置为 >= 3 的原因是，允许集群内同时发生一次计划内停机和一次计划外停机，配置为 `3` 是在避免消息丢失和过度复制之间的常见的权衡选择。HBase（基于 HDFS）和 Cassandra 等分布式存储系统默认的复制系数也是 `3`。
-  - **副本更新传播策略**：副本分为主从（leader-follower）两种角色，由一个 leader 和零到多个 follower 组成复制组，复制组内的分区数据保持同步。复制策略类似于微软的 PacificA 复制协议，Elasticsearch 的[分片复制](https://www.elastic.co/guide/en/elasticsearch/reference/8.12/docs-replication.html)也采用 PacificA 协议。
-    - Kafka 动态维护**同步副本集合**（in-sync replica set），简称 **ISR 集合**。如果一个 follower 副本落后 leader 的时间超过 `replica.lag.time.max.ms` 配置值（Kafka 2.5 开始从默认 10 秒改为 30 秒），那么该 follower 副本会被认为是“不同步副本”（out-of-sync replica，OSR），会被**移除** ISR 集合。当不同步副本重新同步后，会被**加回**到 ISR 集合中。当 leader 所在的节点发生崩溃，ISR 集合中的一个 follower 会被 Controller 选举为新 leader。在消息 commit 之前必须保证 ISR 集合中的全部节点都完成同步复制。这种机制确保了只要 ISR 中有一个或者以上的 follower，一条被 commit 的消息就不会丢失。最小 ISR 集合大小由 Broker 端的配置项 `min.insync.replicas` 控制，默认值 `1`，即只需要 leader。如果同步副本小于 `min.insync.replicas`，尝试向 Broker 发送数据的生产者会收到 `NotEnoughReplicasException` 或 `NotEnoughReplicasAfterAppendException` 异常。
+  - **副本更新传播策略**[^14][^15]：副本分为主从（leader-follower）两种角色，由一个 leader 和零到多个 follower 组成复制组，复制组内的分区数据保持同步。复制策略类似于微软的 PacificA 复制协议，Elasticsearch 的[分片复制](https://www.elastic.co/guide/en/elasticsearch/reference/8.12/docs-replication.html)也采用 PacificA 协议。
+    - Kafka 动态维护**同步副本集合**（in-sync replica set），简称 **ISR 集合**。如果一个 follower 副本落后 leader 的时间超过 `replica.lag.time.max.ms` 配置值（Kafka 2.5 开始从默认 10 秒改为 30 秒），那么该 follower 副本会被认为是“不同步副本”（out-of-sync replica，OSR），会被**移出** ISR 集合。当不同步副本重新同步后，会被**加回**到 ISR 集合中。当 leader 所在的节点发生崩溃，ISR 集合中的一个 follower 会被 Controller 选举为新 leader。在消息 commit 之前必须保证 ISR 集合中的全部节点都完成同步复制。这种机制确保了只要 ISR 中有一个或者以上的 follower，一条被 commit 的消息就不会丢失。最小 ISR 集合大小由 Broker 端的配置项 `min.insync.replicas` 控制，默认值 `1`，即只需要 leader。如果同步副本小于 `min.insync.replicas`，尝试向 Broker 发送数据的生产者会收到 `NotEnoughReplicasException` 或 `NotEnoughReplicasAfterAppendException` 异常。
     - Producer 端的配置项 `acks`，用于控制在确认一个请求发送完成之前需要收到的反馈信息的数量。`min.insync.replicas` 配置项只有在 `acks=all` 时才生效。
       - `acks=0`：表示 Producer 不等待 Broker 返回确认消息。
       - `acks=1`（Kafka < v3.0 默认）：表示 leader 节点会将记录写入本地日志，并且在所有 follower 节点反馈之前就先确认成功。
@@ -147,7 +147,7 @@ Kafka 在 KRaft 模式下的架构图，如下图所示[^18]：
 
 [^12]: Kafka 2.8 权威指南，第2版2021，[豆瓣](https://book.douban.com/subject/36161660/)
 [^13]: Kafka 文档 <https://kafka.apachecn.org/> <https://kafka.apache.org/36/documentation.html>
-[^14]: Kafka 文档：4. 设计思想：4.7 Replication <https://kafka1x.apachecn.org/documentation.html#replication> <https://kafka.apache.org/36/documentation.html#replication>
+[^14]: Kafka Documentation: 4.7 Replication <https://kafka1x.apachecn.org/documentation.html#replication> <https://kafka.apache.org/36/documentation.html#replication>
 [^15]: 2013-02 Jun Rao: Intra-cluster Replication in Apache Kafka <https://engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka> <https://www.slideshare.net/junrao/kafka-replication-apachecon2013>
 [^16]: Optimize Confluent Cloud Clients for Durability <https://docs.confluent.io/cloud/current/client-apps/optimizing/durability.html>
 [^17]: 2019-06 胡夕：Kafka 2.3 核心技术与实战：11 | 无消息丢失配置怎么实现？ <https://time.geekbang.org/column/article/102931>

search.xml

@@ -5456,7 +5456,7 @@ Resiliency is the ability of a system to recover from failures and continue to f
 </li>
 </ul>
 </li>
-<li><strong>复制策略</strong><sup class="footnote-ref"><a href="#fn14" id="fnref14">[14]</a></sup><sup class="footnote-ref"><a href="#fn15" id="fnref15">[15]</a></sup>：
+<li><strong>复制策略</strong>：
 <ul>
 <li><strong>复制单位</strong>：以分区为单位</li>
 <li><strong>复制系数</strong>：
@@ -5467,9 +5467,9 @@ Resiliency is the ability of a system to recover from failures and continue to f
 <li>推荐的复制系数的配置值是 &gt;= 3，通常配置为 <code>3</code>。复制系数配置为 &gt;= 3 的原因是，允许集群内同时发生一次计划内停机和一次计划外停机，配置为 <code>3</code> 是在避免消息丢失和过度复制之间的常见的权衡选择。HBase（基于 HDFS）和 Cassandra 等分布式存储系统默认的复制系数也是 <code>3</code>。</li>
 </ul>
 </li>
-<li><strong>副本更新传播策略</strong>：副本分为主从（leader-follower）两种角色，由一个 leader 和零到多个 follower 组成复制组，复制组内的分区数据保持同步。复制策略类似于微软的 PacificA 复制协议，Elasticsearch 的<a href="https://www.elastic.co/guide/en/elasticsearch/reference/8.12/docs-replication.html">分片复制</a>也采用 PacificA 协议。
+<li><strong>副本更新传播策略</strong><sup class="footnote-ref"><a href="#fn14" id="fnref14">[14]</a></sup><sup class="footnote-ref"><a href="#fn15" id="fnref15">[15]</a></sup>：副本分为主从（leader-follower）两种角色，由一个 leader 和零到多个 follower 组成复制组，复制组内的分区数据保持同步。复制策略类似于微软的 PacificA 复制协议，Elasticsearch 的<a href="https://www.elastic.co/guide/en/elasticsearch/reference/8.12/docs-replication.html">分片复制</a>也采用 PacificA 协议。
 <ul>
-<li>Kafka 动态维护<strong>同步副本集合</strong>（in-sync replica set），简称 <strong>ISR 集合</strong>。如果一个 follower 副本落后 leader 的时间超过 <code>replica.lag.time.max.ms</code> 配置值（Kafka 2.5 开始从默认 10 秒改为 30 秒），那么该 follower 副本会被认为是“不同步副本”（out-of-sync replica，OSR），会被<strong>移除</strong> ISR 集合。当不同步副本重新同步后，会被<strong>加回</strong>到 ISR 集合中。当 leader 所在的节点发生崩溃，ISR 集合中的一个 follower 会被 Controller 选举为新 leader。在消息 commit 之前必须保证 ISR 集合中的全部节点都完成同步复制。这种机制确保了只要 ISR 中有一个或者以上的 follower，一条被 commit 的消息就不会丢失。最小 ISR 集合大小由 Broker 端的配置项 <code>min.insync.replicas</code> 控制，默认值 <code>1</code>，即只需要 leader。如果同步副本小于 <code>min.insync.replicas</code>，尝试向 Broker 发送数据的生产者会收到 <code>NotEnoughReplicasException</code> 或 <code>NotEnoughReplicasAfterAppendException</code> 异常。</li>
+<li>Kafka 动态维护<strong>同步副本集合</strong>（in-sync replica set），简称 <strong>ISR 集合</strong>。如果一个 follower 副本落后 leader 的时间超过 <code>replica.lag.time.max.ms</code> 配置值（Kafka 2.5 开始从默认 10 秒改为 30 秒），那么该 follower 副本会被认为是“不同步副本”（out-of-sync replica，OSR），会被<strong>移出</strong> ISR 集合。当不同步副本重新同步后，会被<strong>加回</strong>到 ISR 集合中。当 leader 所在的节点发生崩溃，ISR 集合中的一个 follower 会被 Controller 选举为新 leader。在消息 commit 之前必须保证 ISR 集合中的全部节点都完成同步复制。这种机制确保了只要 ISR 中有一个或者以上的 follower，一条被 commit 的消息就不会丢失。最小 ISR 集合大小由 Broker 端的配置项 <code>min.insync.replicas</code> 控制，默认值 <code>1</code>，即只需要 leader。如果同步副本小于 <code>min.insync.replicas</code>，尝试向 Broker 发送数据的生产者会收到 <code>NotEnoughReplicasException</code> 或 <code>NotEnoughReplicasAfterAppendException</code> 异常。</li>
 <li>Producer 端的配置项 <code>acks</code>，用于控制在确认一个请求发送完成之前需要收到的反馈信息的数量。<code>min.insync.replicas</code> 配置项只有在 <code>acks=all</code> 时才生效。
 <ul>
 <li><code>acks=0</code>：表示 Producer 不等待 Broker 返回确认消息。</li>
@@ -5545,7 +5545,7 @@ Resiliency is the ability of a system to recover from failures and continue to f
 </li>
 <li id="fn13" class="footnote-item"><p>Kafka 文档 <a href="https://kafka.apachecn.org/">https://kafka.apachecn.org/</a> <a href="https://kafka.apache.org/36/documentation.html">https://kafka.apache.org/36/documentation.html</a> <a href="#fnref13" class="footnote-backref">↩︎</a></p>
 </li>
-<li id="fn14" class="footnote-item"><p>Kafka 文档：4. 设计思想：4.7 Replication <a href="https://kafka1x.apachecn.org/documentation.html#replication">https://kafka1x.apachecn.org/documentation.html#replication</a> <a href="https://kafka.apache.org/36/documentation.html#replication">https://kafka.apache.org/36/documentation.html#replication</a> <a href="#fnref14" class="footnote-backref">↩︎</a></p>
+<li id="fn14" class="footnote-item"><p>Kafka Documentation: 4.7 Replication <a href="https://kafka1x.apachecn.org/documentation.html#replication">https://kafka1x.apachecn.org/documentation.html#replication</a> <a href="https://kafka.apache.org/36/documentation.html#replication">https://kafka.apache.org/36/documentation.html#replication</a> <a href="#fnref14" class="footnote-backref">↩︎</a></p>
 </li>
 <li id="fn15" class="footnote-item"><p>2013-02 Jun Rao: Intra-cluster Replication in Apache Kafka <a href="https://engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka">https://engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka</a> <a href="https://www.slideshare.net/junrao/kafka-replication-apachecon2013">https://www.slideshare.net/junrao/kafka-replication-apachecon2013</a> <a href="#fnref15" class="footnote-backref">↩︎</a></p>
 </li>