Apache kafka 即使制作人得到确认，卡夫卡中是否会发生消息丢失？

说：

• Kafka严重依赖文件系统来存储和缓存消息
• 现代操作系统提供了预读和后写技术，以大数据块倍数预取数据，并将较小的逻辑写入分组为较大的物理写入
• 现代操作系统越来越积极地使用主内存进行磁盘缓存。现代操作系统会很高兴地将所有可用内存转移到磁盘缓存中，而在回收内存时，性能损失很小。所有磁盘读写都将通过此统一缓存
• …与其在内存中维护尽可能多的内容，并在空间耗尽时将其全部刷新到文件系统，不如将其反转。所有数据都会立即写入文件系统上的持久日志，而不必刷新到磁盘。实际上，这只意味着它被传输到内核的页面缓存中。”

进一步说：

（3） 当所有同步副本都已将消息应用于其日志时，消息即为“已提交”。（4）只要至少有一个同步副本处于活动状态，任何已提交的消息都不会丢失

---

因此，即使我使用

acks=all

配置producer（这会导致producer在所有代理提交消息后接收确认），并且producer接收到特定消息的确认，这是否意味着它们仍然有可能丢失消息，特别是如果所有代理都宕机，并且操作系统从未将提交的消息缓存刷新到磁盘？

使用

acks=all

，并且如果主题的复制系数大于1，则仍有可能丢失已确认的消息，但可能性很小

例如，如果您有3个副本（并且所有副本都是同步的），并且

acks=all

，则您需要同时丢失所有3个代理，然后它们中的任何一个才有时间实际写入磁盘。使用

acks=all

，在所有同步副本接收到消息后发送确认，例如，您可以使用

min.insync.replicas=2

确保此数字保持较高

如果使用，则可以进一步降低出现这种情况的可能性（显然，代理位于不同的机架或更好的数据中心中）

---

总而言之，使用所有这些选项，您可以充分降低数据丢失的可能性，使其不太可能发生。

（1）这是否会使kafka不适合于无法容忍消息丢失的用例场景？或者人们仍然成功地使用卡夫卡，即使在这种情况下？（2） 是否有任何其他排队系统（RabbitMQ、ActiveMQ等）在消息确认后确保消息的持久性，从而不会丢失消息（至少不是因为队列服务器临时关闭）。虽然这是“可能的”，但如果在不同数据中心的代理上至少有3个副本，这是极不可能的。这并不意味着卡夫卡不适合数据丢失的情况。即使消息被写入磁盘，理论上所有代理的磁盘都可能同时崩溃。但在这里，这种情况极不可能发生。