目前，一些互联网公司将使用消息队列从事核心业务。因为它是核心业务，所以它对数据的最终一致性更为敏感。如果数据在中间丢失，它将吸引用户的投诉。表演将在今年年底变为325。它会丢失消息吗？如果您丢失消息，该如何采取赔偿措施？让我们分析本文并介绍如何使用操作而不会丢失数据。
本文的操作基于：github.com/shopify/sarama
介绍Wikipedia对：
KAFKA是由Apache软件基金会开发的开源处理平台，由Scala和Java编写。该项目的目的是提供一个统一，高吞吐量且低延迟的真实时间数据。它的持久性层实际上是“分布式事务日志结构的大规模发布/订阅消息队列”，这使得作为企业基础结构处理流数据非常有价值。此外，KAFKA可以通过外部系统（用于数据输入/输出）连接到外部系统（数据输入/输出）kafka connect，并提供Kafka流-A Java]流处理库。设计受到交易日志的极大影响。
Kafka的整体体系结构相对简单，主要组成：
对于架构图，我们解释了一个模块：
我们还介绍了一些概念：
看看生产者的一般写作过程：
通过此过程，我们可以看到Kafka最终将返回ACK以确认推送消息结果。这里的Kafka提供了三种模式：
因此，根据这三种模型，我们可以推断出生产者有一定的机会在推送消息中丢失。分析如下：
因此，在生产环境中，我们可以选择模式2或模式3，以确保消息的可靠性。根据业务方案选择的具体需要。如果吞吐量是通过吞吐量，则选择模式2。选修模式3对于无损失的数据最可靠。
KAFKA群集接收到数据后，数据将长时间存储。最终数据将写入磁盘中。在磁盘上写作的步骤也可能导致数据丢失，因为操作系统将首先写入磁盘，然后第一个第一个第一个。数据编写缓存，操作系统尚不确定何时将数据写入缓存中的磁盘，因此，在这种情况下，如果机器突然下降，也会导致数据丢失。但是，这种概率发生很小。通常，该公司的内部Kafka机器将是备份，这是极端极端的，可以忽略。
推送消息将添加到分区中，并在推送消息时分配一个偏移。此偏移代表当前消费者消费的位置。通过此分区，它还可以确保消息的顺序。消费者您可以设置自动提交或手动提交提交，并将其成功的成功扣除，并且偏移将被抵消：
因此，自动提交数据丢失数据，手动提交重复数据的问题，分析如下：
与数据丢失相比，重复消费与业务期望一致。我们可以通过一些性设计避免这个问题。
完整的代码已上传到GitHub：github.com/asong2020/golang_dream/tree/master/master/code_demo/kafkka_demo
它主要通过两点解决：
因此，我们编写以下代码（挑选客户端部分）：
该解决方案相对粗糙。提交的方式直接提交。每次实际消费后，我都会手动提交偏移，但会导致反复的消费问题。
代码示例：
以上主要是创建消费组部分。小心的读者应该看到。我们在这里使用它自动提交。我们使用手动提交的内容是什么？这是因为我们的Kafka库具有不同的特征。此自动提交需要在提交之前使用MarkMessage（）方法提交（有疑问的朋友可以练习或查看源代码），否则提交将失败，因为当消费者逻辑时我们是这样写的：
或使用手动提交方法来解决它，只有两个步骤：
步骤1：关闭自动提交：
步骤2：将以下代码添加到消费者逻辑中。在手动提交中，您还需要首先标记。
完整的代码可以下载和验证！
我们主要解释本文的两个知识点：
在日常业务的开发中，许多公司喜欢将消息队列脱钩，因此您应该注意。使用kafka发出消息队列不能保证数据不会丢失。我们需要手动配置补偿。FieldP0事故。
作者：Golang Dream Factory