首先

卡夫卡具有机制来安全存储接收到的消息，即使发生故障也能够安全地保存消息。本次将简单介绍如何进行安全存储。
※ 请注意，本文未详细记录实际操作确认方法。

偶尔会看到一些网络文章声称 Kafka 可能会因障碍的时机而导致数据丢失，但只要正确地实施并有正确的知识，就可以做到避免数据丢失。我并不打算在这里展开细节讨论，但我认为这可能是因为考虑或验证 Kafka 的旧版本操作，进行纸上计算时出现错误，或者考虑到多重障碍和故障引起的复杂情况。

先决条件的了解

本文假设读者已经阅读并理解了以下相关文章，现在进行写作。
我试着描述了Confluent平台的魅力
关于Apache Kafka的消息发送和接收（使用REST-PROXY）
利用Kafka进行分布式处理（学习关于分区功能）

在Kafka集群中实现经纪人的冗余。

管理经纪人状态的Zookeeper。

※3台構成不如2台冗余可用性低，请注意。有关详细信息，请参阅此处的解释。
※由于zookeeper本身的运行等与主题略有偏离，我们省略了解释。它是一种配置信息管理软件，可以在Hadoop等环境中使用，虽然只能存储少量数据，但非常提高了可用性。

关于经纪人的身份确认

经纪人的识别是根据经纪人ID确定的。在集群内部，经纪人ID必须是唯一且没有重复的值，如果发生故障需要更换服务器并继承保存的消息，则必须将其设置为与故障的服务器相同的ID以进行继承。

在每个主题上设置冗长化。

Kafka的冗余配置在创建主题时决定了冗余规则。主要根据以下两个值来确定其操作。

• replication.factor (レプリカ数)

• レプリカをとる個数を指定します。指定した数のブローカーへ同一のパーティションが作られます。

• 　※　未指定の場合は ブローカーのdefault.replication.factorの値が作成時に適用されます

• min.insync.replicas (最小レプリカ数)

• 最低限同期できているレプリカの数を指定します。指定した数以上同期できていないパーティションに対しては新たなメッセージを送れなくなります。

※　未指定の場合は ブローカーのmin.insync.replicas のカレントの値が適用されます

复制品的数量和建议的最少复制品数量是多少？

根据用途选择适当的使用方式是重要的。下面我将介绍四种常用的方法。

(1) 三倍冗长 二倍耐性
replication.factor = 3
min.insync.replicas = 2

(2) 冗長度為3，耐性為2
複製因子 = 3
最小同步副本數 = 1

(3) 冗長度2 耐性1
副本因子=2
最小同步副本數=1

(4) 無需冗长
复制因子 = 1
最小同步副本 = 1
适用于非冗长化情况，主要适用于开发环境的使用方式。（不包括暂存）

日志的复制品是按分区划分的。

在每个分区上，日志都会进行复制。
例如，如果将副本数设置为3，并将分区设为2，则会将日志分散存储在四台经纪人上。

掌控复制品的领导角色

在这种情况下，领导者与制作人和消费者之间进行消息交流，并将日志信息的副本复制给成员（指除领导者之外的代理人）。
如果领导者发生故障，将从成员中选出新的领导者来接管处理，并继续进行处理。

发送消息（制作人）

当将消息传递给代理时，在API内部决定分区的方法如之前所述。

1. 当分区确定后，将向领导者代理传递消息。

领导者代理在传递消息后会向成员代理进行复制。

确认保存消息

当生产者向经纪人传递消息或在经纪人之间获取副本时发生故障时，可能会导致消息丢失。
在Kafka中，通过确认生产者发送的消息已经正确复制，来确保消息的可靠传递。
为了实现这一保证，请注意将生产者的acks属性设置为all。

所有参数设置为”acks=all”的操作

①　生产者向领导经纪人发送消息。
②　领导经纪人向成员发送消息副本。
③　成员收到副本后将确认(ACK)发送给领导。
④　领导确认拥有至少min.insync.replicas个副本（包括已持有的消息），然后向生产者发送ACK。
※ 即使超过min.insync.replicas的数量，成员仍会向领导发送确认(ACK)操作，但有时接收可能会在发送④的ACK之后进行，不能完全确定所有成员的副本都成功。

即使在发生故障的情况下，已接收Ack的消息是有保证的。
如果没有收到Ack，则不能保证消息可靠性，必须进行重试或错误处理。
※ 如果从Leader接收到的Ack未正确返回，则会在Producer内部进行重试，但需要在程序内部创建写入失败的行为，不相信这种重试。
※ 如果仅Ack消失，Producer会进行重试，并通过接收到来自Producer的已注册消息来防止重复，因为它们具有相同的序列号并在消息内部自动管理。

只需一个选择，用汉语将以下内容进行改写：

acks=1的操作

保证达到领导者层级，但是如果在2之后发生领导者故障，相关消息将会消失。※只在正常情况下保证可达性使用。与Acks=all相比，响应速度更快，因此在需要快速性的情况下经常使用，但在处理故障时可能会变得稍微复杂，存在一些缺点。

如果acks等于0的话

因为不进行消息到达确认，所以存在消息丢失的可能性最高的方法。
但是可以最快速地接收大量的消息。
※例如，在使用物联网温度传感器时，温度变化不会频繁，可以通过前后的消息来补全消息。这是一种在几条消息缺失的情况下也不会出现问题的情况下使用的方法。

消费者方的行为

如果万一经纪人遇到故障，成员升级为领导者后将阅读消息。由于Zookeeper保留了偏移和提交偏移信息，所以不会受到影响。

如果消费者出现故障，将从提交偏移量的下一条消息重新发送到消费者端，以便继续处理。

当进行诸如poll命令等从消费者到Kafka的下一指令时，会自动更新提交偏移量（当ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG为True时）。这种方法在同时接收多个消息并在消息处理过程中出现异常终止的情况下，可以返回并重新处理提交偏移量，从而可能导致处理结果重复。在这种情况下，可以通过手动方式（当ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG为false时）对每个处理记录逐个进行处理，以使提交偏移量逐个前进。

总结

只需要一种选项，请用中文将以下内容重新表述：
使用 Kafka，即使在万一发生故障的情况下，也具备了无数据丢失的功能，可以实现消息交换和处理的连续进行。但是，由于需要进行事先设置并且旨在实现高可用性，所以推荐以下配置。然而，由于实现高可用性会增加延迟，所以不能只有一种设置选项，还需要根据处理的数据内容和特性对每个主题进行相应的配置调整。

推荐高可用性的选项

如果你追求高可用性，我建议进行以下设置。

主题：
复制因子 = 3
最小同步副本数 = 2

制作人
acks = 全部
重试次数 ≥ 2

通过命令确认的方法。

要显示每个主题的分区数、副本数、个别配置信息以及每个分区的领导代理、副本代理和复制状态，请使用kafka-topics命令。

# docker-compose exec broker kafka-topics --bootstrap-server localhost:9092 --describe --topic test2
Topic:test2     PartitionCount:3        ReplicationFactor:3     Configs:min.insync.replicas=2
        Topic: test2    Partition: 0    Leader: 2       Replicas: 2,4,1   Isr: 2,1
        Topic: test2    Partition: 1    Leader: 3       Replicas: 3,1,2   Isr: 3,1,2
        Topic: test2    Partition: 2    Leader: 1       Replicas: 1,2,3   Isr: 1,2,3

※ 这是使用Docker-Compose的命令示例。

命令选项

• –bootstrap-server <FQDN名>:<TCPポート番号>

• ブローカーのFQDN及び接続ポート番号指定 （必須パラメータ）

• –describe

• トピックの詳細を表示するオプション

• –topic <topic名>

トピック名を指定するオプション

结果

• Topic:

• トピック名

• PartitionCount:

• パーティションの数

• ReplicationFactor:

• レプリカ数

• Configs

• トピック固有設定情報 5

Partition:
パーティションID
Leader:
リーダーとして稼働中のKafkaブローカーID
Replicas:
レプリカを取得する対象のKafkaブローカーのIDリスト
Isr:
in-sync replicaの略で、レプリケーションが完了してリーダと同じログを保持しているブローカIDリスト

LinkedIn是一个社交媒体平台，专门用于专业人士之间的连接和交流。

由于有人在Linked in上关心如何使用，所以我将提供尽我所知的信息。
集群数量：大约100个集群
每个集群（最多）：60个代理，50k个主题
峰值时每秒接收800k条消息，占用300MB（每条消息约300~400字节）。发送消息1GB
在Kafka上，replication.factor = 2是应用程序设计的标准，可以容忍消息丢失
硬件：双CPU（4核Xeon）/ 24GB内存
使用Apache Kafka的派生版本。

据说规模很庞大，可以看出每天都在进行大量的数据分析。
个人认为，由于规模、使用方式和应用程序设计都有太大的差异，最好根据使用需求进行选择，不要仅仅参考规模。因此，请不要受到老牌公司的限制，而是根据每个项目来考虑设计。请多多关照。