可靠的数据传递是系统的属性之一，不能作为事后考虑。与性能一样，它必须从第一个白板图中被设计成一个系统。事后你就不能保证可靠性了。更重要的是，可靠性是一个系统的属性——而不是单个组件——所以即使当我们谈论Apache Kafka的可靠性保证时，您也需要记住整个系统及其用例。说到可靠性，与卡夫卡集成的系统和卡夫卡本身一样重要。因为可靠性是一个系统概念，它不可能是一个人的责任。每个人——Kafka管理员、Linux管理员、网络和存储管理员以及应用程序开发人员——都必须共同努力，以构建一个可靠的系统。
Apache Kafka在可靠的数据传递方面非常灵活。我们知道卡夫卡有很多用例，从跟踪网站上的点击量到信用卡支付。一些用例需要最大的可靠性，而另一些则则优先考虑速度和简单性，而不是可靠性。Kafka被编写成足够可配置，它的客户端API足够灵活，可以允许各种可靠性权衡。

由于它的灵活性，在使用卡夫卡时也很容易不小心击中自己的脚——相信你的系统是可靠的，而实际上它不是。在这篇文章中，我们将首先讨论不同类型的可靠性，以及它们在阿帕奇·卡夫卡的背景下的含义。然后我们将讨论卡夫卡的复制机制，以及它如何有助于系统的可靠性。然后，我们将讨论Kafka的代理和主题，以及应该如何为不同的用例配置它们。然后，我们将讨论客户、生产者和消费者，以及应该如何在不同的可靠性场景中使用它们。最后，我们将讨论验证系统可靠性的主题，因为仅仅相信一个系统是可靠的是不够的——必须彻底测试这样的假设。
kafka的基础保证
Kafka为分区中的消息提供了顺序保证。如果消息B在消息A之后是命令十，在同一分区中使用相同的生产者，那么Kafka保证消息B的偏移量将高于消息A，并且消费者将在消息A之后读取消息B。
当生成的消息被写入所有不同步副本上的分区（但不一定刷新到磁盘）时，它们被认为是“提交”。当消息完全提交、写入给领导或通过网络发送时，生产用户可以选择接收已发送消息的确认。只要至少有一个复制副本仍然存在，已提交的消息就不会丢失。
消费者只能读取已提交的消息。
这些基本的保证可以在构建一个可靠的系统时使用，但在它们本身中，并不能使系统完全可靠。构建一个可靠的系统需要进行权衡，而Kafka的构建是为了允许管理员和开发人员通过提供允许控制这些权衡的配置参数来决定他们需要多少可靠性。权衡通常涉及可持续和持续地存储消息的重要性，而不是其他重要的考虑因素，如可用性、高吞吐量、低延迟和硬件成本。接下来，我们将回顾卡夫卡的复制机制，介绍术语，并讨论如何将可靠性纳入卡夫卡。之后，我们将回顾我们刚才提到的配置参数。
每个Kafka主题都被分解为分区，这些分区是基本的数据构建块。一个分区存储在单个磁盘上。Kafka保证分区内的事件顺序，并且分区可以是联机（可用）或脱机（不可用）。每个分区可以有多个副本，其中一个是指定的引头。所有事件都从领导者复制副本产生和消耗。其他的副本只需要与领导者保持同步，并按时复制所有最近的事件。如果引线不可用，则其中一个不同步的复制副本将成为新的引线。
如果一个副本是一个分区的引头，或者它是一个追随者：与动物园管理员有一个活跃的会话，那么它就被认为是不同步的——这意味着，它在最后6秒内向动物园管理员发送了一个心跳（可配置的）。•在过去10秒内从引线处获取消息（可配置）。•在最后10秒内获取了领导者的最新消息。也就是说，仅仅是追随者仍然从领导者那里得到信息是不够的；它必须几乎没有延迟如果一个复制副本失去了与动物园管理员的连接，停止获取新消息，或者在10秒内无法赶上，则认为该复制副本不同步。当一个不同步的复制副本再次连接到动物园管理员时，它将恢复同步，并赶上写入给领导者的最新消息。这种情况通常在临时网络故障修复后很快发生，但如果存储复制副本的代理停机较长时间，则可能需要一段时间。
略微落后的不同步副本会降低生产者和消费者的速度，因为他们会等待所有不同步副本才能得到消息。一旦一个复制副本不同步，我们就不再等待它来获取消息。它仍然落后了，但现在没有了对性能的影响。问题是，由于不同步副本较少，分区的有效复制因子更低，因此停机或数据丢失的风险更高。
Broker Configuration
代理中有三个配置参数可以改变Kafka关于可靠消息存储的行为。与许多代理配置变量一样，这些变量可以应用于代理级别，控制系统中所有主题的配置，并在主题级别，控制特定主题的行为。
能够在主题级别上控制可靠性权衡意味着相同的Kafka集群可以用于托管可靠和不可靠的主题。例如，在银行中，管理员可能希望为整个集群设置非常可靠的默认值，但对存储可以接受某些数据丢失的客户投诉的主题进行例外。
Replication Factor
主题级的配置是复制因子。在代理级别上，您可以控制针对自动创建的主题的default.replication.factor。在此之前，在整本书中，我们一直假设主题的复制因子为3，这意味着每个分区在三个不同的代理上被复制了三次。这是一个合理的假设，因为这是Kafka的默认设置，但这也是一个用户可以修改的配置。即使在一个主题存在之后，您也可以选择添加或删除复制副本，从而修改该复制因子。复制因子N允许您丢失N-1代理，同时仍然能够可靠地读取和写入该主题的数据。因此，更高的复制系数会导致更高的可利用能力、更高的可靠性和更少的灾难。另一方面，对于复制因子为N，您将至少需要N个代理，并且您将存储N个数据副本，这意味着您将需要N倍的磁盘空间。我们基本上是在交换硬件的可用性。
如果您完全可以在重新启动单个代理（这是集群正常操作的一部分）时特定主题不可用，那么复制速率1可能就足够了。不要忘记确保您的管理和用户也同意这种权衡——您在磁盘或服务器上节省，但失去了高可用性。复制因子为2意味着你可以失去一个代理，并且仍然可以，这听起来已经足够了，但是请记住，失去一个代理有时（主要是在旧版本的卡夫卡控制器上）会将集群发送到一个不稳定的状态，迫使你重新启动另一个代理——卡夫卡控制器。这意味着，当复制功能为2时，您可能会被迫进入不可用状态，以便从操作问题中恢复。这可能是一个艰难的选择。
由于这些原因，我们建议任何对可用性存在问题的主题的复制因子为3。在极少数情况下，这被认为是不够安全的——我们已经看到银行用5个副本来运行关键的主题，只是为了以防万一。复制品的放置也非常重要。默认情况下，Kafka将确保分区的每个副本都位于单独的代理上。然而，在某些情况下，这还不够安全。如果一个分区的所有副本都放在同一机架上的代理上，并且机架顶部的交换机行为错误，那么无论复制因素如何，您都将失去该分区的可用性。为了防止机架级的不幸，我们建议将代理放置在多个机架中，并使用代理。机架代理配置参数为每个代理配置机架名称。如果配置了机架名称，Kafka将确保分区的副本跨越多个机架，以保证更高的可用性。
此配置仅在代理级别（实际中为集群范围）可用。参数名称为unclean.leader.election.enable，默认情况下设置为true。
如前所述，当分区的引线不再可用时，将选择其中一个不同步的复制副本作为新的引线。这次领导人选举是“干净的”，因为它保证不会丢失提交的数据——根据定义，已提交的数据存在于所有不同步的副本上。但是，除了刚刚不可用的引导之外，当没有同步副本存在时，我们该怎么办呢？这种情况可能发生在两种情况中的一种：分区有三个副本，两个追随者不可用（假设两个代理崩溃了）。在这种情况下，随着制片人继续写信给引线，所有消息都被确认并提交（因为引线是唯一的不同步副本）。现在让我们假设领导者变得不可用（哦，另一个经纪人崩溃）。在这个场景中，如果其中一个不同步的追随者首先开始，我们将有一个不同步的副本作为该分区的唯一可用的副本。•这个分区有三个副本，由于网络问题，这两个追随者落后了，所以即使他们已经启动和复制，它们也不再同步。引头将继续接受消息作为唯一的不同步的复制副本。现在，如果引头不可用，则这两个可用的复制副本将不再同步。
在这两种情况下，我们都需要做出一个困难的决定：如果我们不允许不同步的副本成为新的领导者，分区将保持离线，直到我们将旧的领导者（以及最后一个不同步的副本）重新联机。在某些情况下（例如，内存芯片需要更换），这可能需要很多小时。
如果我们确实允许不同步的副本成为新的领导者，我们将丢失在该副本不同步时所有写入旧领导者的消息，这也会导致消费者的一些不一致。为什么想象一下，当副本0和1不可用时，我们用偏移量100-200向副本2编写消息。现在，副本3不可用，而副本0已恢复联机。复制副本0只有消息0-100，而不是100-200。如果我们允许副本0成为新的领导者，它将允许生产者编写新的消息，并允许消费者读取它们。所以，现在新领导人有了全新的圣人100-200。首先，让我们注意的是，一些消费者可能读过旧的圣人100-200，一些消费者得到了新的100-200，有些人两者兼有。当查看下游报告等内容时，这可能会导致相当糟糕的后果。此外，复制品2将重新上线，成为新领导者的追随者。此时，它将删除它得到的领先于当前领导者的任何消息。这些信息将来将不会向任何消费者使用。
总之，如果我们允许不同步的副本成为领导者，我们就会面临数据丢失和数据不一致的风险。如果我们不允许他们成为领导者，我们将面临较低的可用性，因为我们必须等待最初的领导者可用，才能使分区重新在线。将unclean.leader.election.enable设置为真意味着我们允许不同步的复制成为领导者（称为不干净的选举），我们知道当这种情况发生时我们将失去圣人。如果我们将其设置为false，我们将选择等待原始领导者返回在线，从而导致可用性降低。在数据质量和一致性至关重要的系统中，我们通常会看到不干净的领导设备被禁用（配置设置为false）——银行系统就是一个很好的例子(大多数银行宁愿这样做无法处理几分钟甚至几小时的信用卡支付，冒有错误支付的风险)。在可用性更重要的系统中，如实时点击流分析，不干净的领导人选举通常是启用的。
Minimum In-Sync Replicas
如果我们一个topic拥有3个副本，可能会有一个副本不同步，如果这个副本不可用，我们必须要在可用性 和一致性之间做出选择，cap定律 但是这不是一个容易的选择，根据kafka的可靠性保证，必须写入所有in-sync副本 才会提交，只有一个副本，并且如果该副本不可用，数据也可能会丢失。
如果要确保已提交的数据写入多个副本，则需要将不同步副本的最小数量设置为更高的值。如果一个主题有三个副本，并且将min.insync.replicas设置为2，那么只有如果三个副本中至少有两个同步，才能写入主题中的分区。
当三个副本是 in-sync,如果一个副本不可用，如果2/3的副本不可用，brokers不在接受消息，生产者显示
NotEnoughReplicasException，消费者可以读取消息。事实上，一个in-sync副本变成了只读副本，这就阻止了消息不一致的产生，而只在不干净的选举发生时消失。为了从这种只读情况中恢复，我们必须再次使两个不可用分区中的一个可用（可能重新启动代理），并等待它赶上并保持同步
在一个可靠的系统中使用生产者
即使broker配置已经确保了可靠性，但是生产者的配置不好仍然还会有数据丢失的情况。
先看下面两种情况
情况1 我们为broker配置了三个副本，不干净的broker选举就被取消了。所以我们永远不应该丢失一条提交给Kafka集群的消息。但是，我们将生产者配置为使用acks=1发送消息。我们发送了一个来生产者的消息，它被写给了leader，但还没有写给不同步的副本。leader向生产者发送了一个回复，称“消息写入成功”，并在数据被复制到其他副本之前立即崩溃。其他的复制副本仍然被认为是不同步的，而其中一个将会成为领导者。由于该消息没有写入复制副本，因此它将丢失。但是生成的应用程序认为它是成功编写的。该系统是一致的，因为没有消费者看到该消息（它从未被提交，因为复制副本从未得到它），但从生产者的角度来看，一条消息丢失了。
情况2我们为broker配置了三个副本，不干净的broker选举就被取消了。我们从错误中吸取了教训，并开始使用acks=all。假设我们试图给卡夫卡写一个信息，但是我们所写的分区的领导刚刚崩溃了，一个新的领导仍然被选中。卡夫卡会回应为“领袖不可用”。此时，如果生产者没有正确处理该错误，并且在写入成功之前不重试，则该消息可能会丢失。同样，这也不是代理的可靠性问题，因为代理从未得到过消息；这也不是一个一致性问题，因为消费者也从未得到过消息。但是，如果生产者没有正确地处理错误错误，它们可能会导致消息丢失。
需要做到以下两点避免
1使用正确的acks配置来匹配可靠性要求，
2正确地处理配置和代码中的错误
使用发送确认机制
acks=0意味着如果生产者成功通过网络发送消息，则被认为是成功写入Kafka。如果您发送的对象无法序列化或者网卡失败，您仍然会得到错误，但是如果分区脱机或者整个Kafka集群决定长期休假，您将不会得到任何错误。这意味着，即使在预期的leader选举干净的情况下，你的生产者也会失去信息，因为它不知道在新领导人当选时，领导人是不可用的。使用acks=0运行的速度非常快（这就是为什么您会看到大量使用这种配置的基准测试）。您可以获得惊人的吞吐量和利用您的大部分带宽，但如果您选择这条路由，您保证会丢失一些消息。
acks=1意味着leader将在收到消息并将其写入分区数据文件时发送确认或错误（但不需要-通常同步到磁盘）。这意味着在领导选举的正常情况下，您的生产者将在leader当选时获得leader不可用异常，如果生产者正确处理此错误，它将重试发送消息，消息将安全到达新的领导。可能丢失消息 ，leader崩溃但是没有同步到副本。
acks=all leader将等待所有不同步的副本得到消息，然后再发送确认或错误。与broker上的min.insync.replica配置相结合，这使您可以控制在确认消息之前获取消息的副本数量。这是最安全的选择——在完全提交之前，生产者不会停止发送消息。这也是最慢的选项——生产者先等待所有副本获取所有消息，然后才能将消息批处理标记为“已完成”并继续执行。这可以通过对生产者使用异步模式和发送更大的批次来减轻影响，但这个选项通常会获得更低的吞吐量。

配置生产者的重试次数
处理生产者中的错误有两部分：生产者会为您自动处理的错误，以及您作为使用代理库的开发人员必须处理的错误。
生产者可以处理由代理为您返回的可检索的错误。当生产者向代理发送消息时，代理可以返回成功代码或错误代码。这些错误代码属于两类——在重试后可以解决的错误和无法解决的错误。例如，如果代理返回错误代码LEADER_NOT_AVAILABLE，生产者可以尝试再次发送错误——可能选择了一个新的代理，第二次尝试将成功。这意味着LEADER_NOT_AVAILABLE是一个可检索的错误。另一方面，如果代理返回了一个INVALID_CONFIG异常，那么再次尝试相同的消息将不会更改配置。这是一个不可检索的错误的例子。
一般来说，如果您的目标是永远不会丢失消息，那么最好的方法是配置生产者在遇到可检索错误时继续尝试发送消息。为什么因为像缺乏领导者或网络连接问题这样的事情通常需要几秒钟来解决——如果你让生产者继续尝试直到它成功，你就不需要自己处理这些问题。我经常被问到“我应该配置多少次生产者来重试？”答案实际上取决于在生产者抛出一个异常并重试之后你打算做什么
如果你的答案是“我将抓住异常并重试一些”，那么你肯定需要将重试次数设置得更高，让制作人继续尝试。当答案是“我将删除消息；没有必要继续重试”或“我只在其他地方写它，以后处理”时，你想停止重试。请注意，kafka的跨副本复制工具（镜像制造器，默认配置为不断地重试（即重试=MAX_INT）——因为作为一个高度可靠的复制工具，它不应该只删除消息。
请注意，重新尝试发送失败的消息通常包含一个小风险，即两个消息都成功写入代理，从而导致重复。例如，如果网络问题阻止代理确认到达生产者，但消息已成功编写和复制，生产者将把缺乏确认视为临时网络问题，并重试发送消息（因为它不知道收到了消息）。在这种情况下，代理最终会有两次相同的消息。重试和仔细的错误处理可以保证每条消息将至少存储一次，但是在当前版本的Apache Kafka（0.10.0）中，我们不能保证它将完全只存储一次。许多真实世界的应用程序为每个消息添加了一个唯一的标识符，以便在使用消息时检测重复项并清理它们。其他应用程序使消息幂等——这意味着即使同一消息发送两次，也不会对正确性产生负面影响。例如，消息“帐户值为110$”是幂等式的，因为发送它几次并不会改变结果。
其他错误处理
使用内置的生产者重试是一种正确处理各种错误而不会丢失消息的简单方法，但是作为一个开发人员，您必须仍然能够处理其他类型的错误。
这些错误包括：
不可检索的代理错误，如关于消息大小的错误、授权错误等。
•在消息发送到代理之前发生的错误-例如，当生产者耗尽所有重试时或生产者使用的可用内存在重试时使用所有错误存储消息时发生的错误
这些错误处理程序的内容是特定于应用程序及其目标的——你会扔掉“坏消息”吗？日志记录错误？是否要将这些消息存储在本地磁盘上的一个目录中？触发到另一个应用程序的回调？这些决策都是特定于您的体系结构的。请注意，如果您的处理方式是所有错误都是重试发送消息，那么您最好依赖于产品开发程序的重试功能。

在一个可靠的系统中使用消费者
可靠处理的重要消费者配置属性为了配置消费者以实现所需的可靠性行为，需要理解四个重要的消费者配置属性。
group.id
一个partition只能被一个消费组的一个消费者消费，一个消费者可以消费多个partition分区的数据，有个问题就是一般我们在做日志的多种异构存储(比如Hbase, Hive, Es, clickhouse等)的消费的时候，怎么让一个分区的消息能同时多个异构消费者消费呢，那就是开启不同的消费组(goupId不同，我们提交到coodinator的消费偏移互不干扰(消费记录=groupid + topic + partition + offset))
第二个相关的配置是auto.offset.reset。此参数控制当没有提交偏移量 这里只有两种选择。如果选择最早，当分区没有有效偏移时，使用者将从分区的开始。这可能导致消费者两次处理大量消息，但它保证了最小化数据丢失。如果您选择最新的，用户将在分区的末尾开始。这最大限度地减少了消费者的重复处理，但几乎肯定会导致一些消息被消费者遗漏。
第三个相关的配置是enable.auto.commit。这是一个很重要的决定：您是打算让消费者根据时间表为您提交偏移量，还是计划在代码中手动提交偏移量？自动偏移提交的主要好处是，在实现消费者时不用再担心一件事。如果在合并轮询循环中对消耗的记录进行所有处理，那么自动偏移量提交保证您永远不会提交未处理的偏移量。自动偏移提交的主要缺点是，您无法控制您可能需要处理的重复记录的数量（因为您的使用者在处理一些记录后就停止了，但在自动匹配的提交启动之前）。如果您做了任何有趣的事情，比如将记录传递到另一个线程并在后台处理，那么自动提交可能会为消费者已经读取但可能尚未处理的记录提交偏移量。
第四个相关配置与第三个配置绑定，是auto.com mit.interval.ms。如果选择自动提交偏移量，此配置允许您配置提交的频率。默认值是每5秒钟运行一次。通常，更频繁地提交会增加一些开销，但减少了在消费者停止时可能发生的重复的数量。
在消费者中正确地提交偏移量
在处理事件后始终提交偏移量如果您在轮询循环中执行所有处理，并且不在轮询循环之间维护状态（例如，用于聚合），这应该很容易。您可以在轮询循环结束时使用自动提交配置配置或提交事件。
提交频率是性能之间和重复数量的权衡
即使在最简单的情况下，你做所有的处理在轮询循环和不维护状态之间的循环，你可以选择提交多次循环（甚至在每个事件后）或选择只提交每几个循环。提交有一些性能开销（类似于使用acks=all的生产），所以这完全取决于对您有效的权衡。
请记住，在处理消息后始终提交偏移量是至关重要的——为读取但未处理的消息提交偏移量可能会导致消费者丢失消息
消费者可能需要重试
在有些案例中 在poll和处理记录后，有些记录没有完全处理，需要稍后处理。例如，您可以尝试将记录从Kaffa写入数据库，但发现该数据库当时不可用，因此您可能希望稍后重试。请注意，与传统的pub/sub系统不同，您提交偏移量而不是打包单个消息。这意味着，如果您未能处理记录#30，并且成功处理了记录#31，您不应该提交记录#31——这将导致将所有记录提交到#31，包括#30，这通常不是您想要的。相反，请尝试遵循以下两种模式之一。
处理方式1当遇到错误时，提交成功处理的最后一条记录。然后将仍然需要处理的记录存储在一个缓冲区中（这样下次poll就不会覆盖它们），并继续尝试处理这些记录。在尝试处理所有记录时，您可以使用消费者pause（）方法，以确保额外的pull不会返回额外的数据，从而使重试更容易。
第二个选项是，当遇到一个错误时，将其写入一个单独的主题并继续。可以使用单独的用户组处理重试主题的重试，或者用户可以订阅主主题和重试主题，但在重试之间暂停重试主题。这种模式类似于在许多消息传递系统中使用的死信-队列系统。
消费者可能需要保持状态
在某些应用程序中，您需要跨多个调用维护状态才能进行pull。例如，如果您希望计算移动平均值，则您将希望在每次为新事件投票给Kaffa后更新平均值。如果进程重新启动，您不需要从上一个偏移量开始消耗，还需要恢复匹配的移动平均值。一种方法是，在提交偏移量的同时，将最新的累积值写入一个“结果”主题。这意味着，当一个线程启动时，它可以在启动时拾取最新的累积值，并在它停止的地方进行拾取。然而，这并没有完全解决这个问题，因为卡夫卡还没有提供事务。您可能会在写完最新结果和提交偏移量之前崩溃，反之亦然。一般来说，这是一个相当复杂的问题，而不是自己解决，我们建议看像Kafka流这样的库，它为聚合、连接、窗口和其他复杂的分析提供类似高级dsl的api。
处理时间长
有时处理记录需要很长时间。也许您正在与一个可以阻止或做一个非常复杂的计算的服务进行交互，即使您不想处理其他记录，您也必须继续pull，以便客户端可以向代理发送心跳。在这些情况下，一种常见的模式是将数据传递给线程池，通过并行处理来加快速度。在将记录传递给工作线程之后，您可以暂停或者继续pull，而无需实际获取额外的数据，直到工作线程完成。一旦完成，你就可以恢复消费者。因为使用者从未停止pull，因此心跳将按计划发送，并且不会触发重新平衡。
无数据丢失
虽然kafka目前还没有提供完全一次的补充端口，消费者没有什么可用的技巧可以让他们保证卡夫卡中的每条消息都被写入外部系统一次
最简单也可能是最常见的方法——一次是将结果写入一个支持唯一键的系统。这包括所有键值存储、所有关系数据库、弹性搜索，可能还有更多的数据存储。当将结果写入关系数据库或弹性搜索等系统时，记录本身包含唯一的键（这是相当常见的），或者您可以使用主题、分区和偏移组合创建唯一的键，它唯一地标识Kafka记录。如果您用一个唯一的键编写记录作为一个值，然后再重新使用相同的记录，您将只写完全相同的键和值。数据存储将覆盖现有的数据存储，您将得到与没有意外重复相同的结果。这种模式被称为幂等写法，它非常常见和有用。
还有一个选择是可以写入一个含有事务的系统，早期的关系数据库就是一个例子，但是HDFS有原子重命名，通常用于相同的目的。其想法是在同一事务中写入记录及其偏移量，这样它们就会保持同步。启动时，检索写入外部存储的最新记录的偏移量，然后使用 consumer.seek()从这些偏移量重新开始合并。

验证系统可靠性
领袖选举：如果我杀了领袖会发生什么？消费者和消费者需要多长时间才能开始正常工作？
•Controller election：重启控制器后，系统恢复需要多长时间？
•Rolling restart：我是否可以逐个重新启动代理而不丢失任何消息？
•Unclean leader election test：当我们一个接一个地杀死所有的副本（以确保每个副本都不同步），然后启动一个不同步的代理时，会发生什么？

这些都需要测试
验证应用程序
一旦您确定代理和客户端配置满足了您的需求，就该测试应用程序是否提供了所需的保证了。这将检查您的自定义错误处理代码、偏移提交、重新平衡列表器以及应用程序逻辑与Kafka的客户端库交互的类似地方。
测试方法
客户端失去了与服务器的连接
Leader election
Rolling restart of brokers
Rolling restart of consumers
Rolling restart of producers
生产可靠性监控

总结
default.replication.factor 一般设置为3 设置更多的副本
unclean.leader.election.enable 设置为false 禁用不干净的领导选举 可用性降低
min.insync.replicas设置为2 设置同步副本数量
生产者
acks=all
retries=3 设置重试次数
消费者
group.id 唯一的
enable.auto.commit 改为手动提交
第四个相关配置与第三个配置绑定，是auto.com mit.interval.ms。如果选择自动提交偏移量，此配置允许您配置提交的频率。默认值是每5秒钟运行一次。通常，更频繁地提交会增加一些开销，但减少了在消费者停止时可能发生的重复的数量。