与Kafka，你可以得到保证，没有信息丢失，即使在失败的存在；我猜你用“懒散的坚持”选项就失去了保证，对吗？
这是一个很大的主题。
确保没有消息丢失
这取决于几件事。首先，您可以配置保留—在特定的时间段之后，邮件丢失对您来说是正常的。你可以考虑无限保留，但也要注意你有足够的存储空间，也许你需要压缩主题？
即使出现故障；我猜你用“懒散的坚持”选项就失去了保证，对吗？
kafka是一个分布式系统，分布式系统通常比同步磁盘写入更依赖于分布式复制。即使同步写入磁盘，磁盘也可能会死机并丢失。您希望在多大程度上使用分布式复制（例如3个或6个副本？）以及同步或异步磁盘写入，这取决于您的需求—但它也会在吞吐量方面进行权衡。e、 aws aurora是一个分布式数据库，使用6个副本。

对于任何解决方案，都不存在“不丢失消息”的合理或实用的方法。
Kafka的方法是在数据到达服务器后进行复制。正如@jonas所提到的，总吞吐量是一种权衡。kafka的生产者通常是开箱即用的异步的，因此可以合理地预期，进程（容器重启）或网络中断将导致来自生产应用程序端的可观察到的消息丢失。另外，懒散的持久性可能会导致由于进程或服务器端kafka故障而导致可合理观察到的消息丢失。
activemq的方法是使用操作系统系统调用fsync（）将数据同步到磁盘，这将导致对磁盘的写入。当您将其与raid存储相结合时，您可以最实际地保证数据不会丢失。
然而，有一种与持久性无关的替代模式可以实现更高程度的保证。这被一些金融交易系统和国防应用程序使用。
通常被称为“扇出”。activemq的客户机中包含扇出传输。工作原理如下：
生产者将消息发送到3台服务器（它们应尽可能相互隔离）。
消费者最多可收到3条信息。
第一条消息通过“wins”，消费者应用程序会删除另外两条消息。
使用这种方法，您可以完全跳过持久性，因为您有3条独立的路径，并且所有3条失败的几率都很低(在事件生产者网络离线的情况下，有一些策略可以提高生产者端的qos。
使用者可以选择处理第一条消息（快速）或要求至少2条消息来处理和验证请求是否合法（安全，但延迟更高）。