一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第17天，点击查看活动详情。
本章节介绍kafka事务相关的知识点，面试中问到的概率比较大
精确一次
Kafka提供了“至少一次”的交付语义。这意味着发送的消息可以传递一次或多次。人们真正想要的是“恰好一次”的语义，即不传递重复的消息。 出现重复邮件的常见原因有两个：
如果客户端尝试向群集发送消息并收到网络错误，则重试可能会导致重复。如果在传递邮件之前发生网络错误，则不会发生重复。但是，如果在将邮件追加到日志之后，但在将响应传递给发件人之前发生网络错误，则发件人将不知道发生了什么。唯一的选择是重试并冒重复的风险，或者放弃并声明消息丢失。 如果使用者从主题中读取消息，然后崩溃，则当使用者重新启动或另一个实例接管消费时，新使用者将从原始使用者的最后一个已知位置开始。
UUID方法
重复数据删除的一个简单而不切实际的实现是让客户端为其发送的每条消息（例如UUID）创建一个唯一的ID，并让服务器为其保留的所有消息保存所有此类ID。将针对此数据库检查新邮件，并拒绝已存在的邮件。这至少可以满足基本要求，但效率低下，因为数据库将包含O（num_messages）条目。实际的实现必须提供一种类似的方法来检测重复项，但空间要求较低，查找性能影响可以忽略不计。
总结
以上是对kafka对精确一次和UUID的相关处理方法，需要理解和掌握。至少一次、最多一次，类似的概念在别的组件中也有提及，但实现原理是相通的，我们可以利用kafka自带的配置，或者根据业务UUID来实现这种需求。另一方面，如果业务对数据的准确性要求不是那么严格，也可以忽略处理，从而提升系统吞吐量，需要根据实际情况进行判断
