Kafka并不是严格意义上的1:1消息传递系统。多个生产者可以写一个主题，多个消费者可以从中阅读。此外，在Kafka，多个消费者可以分配相同或不同的消费群体。每个消息只由来自每个使用者组的一个使用者使用（负载平衡），并且所有使用者组都会收到每条消息的副本（当然，如果他们订阅了相应的主题并且没有消息丢失）。本文对这一过程进行了很好的描述：kafka消息传递使用消费者组的可伸缩性。
在kafka中，所有的消息都被保存在磁盘上并存储，直到压缩操作重新获取它，或者 retention.ms 通过，或超过日志大小。这是一个非常高层次的观点，这里有很多细微差别。例如：消息存储在段中，每个段包含多个消息。当一条消息的保留期过去时，它不会从该段中删除，而是等待该段中的所有消息都过期，然后立即删除整个段。而且，保留可能在日志超过最大大小之前出现，反之亦然：日志甚至在保留期过去之前就可能超过大小。等等。只需阅读文档并注意有关“日志清理器”和“保留”的主题。
Kafka消费者读取消息后，消息既没有压缩，也没有过期。所以，它没有从日志中删除，而是留在那里。这也意味着，如果需要，消费者可以重新阅读每条消息（直到它被完全删除）。如果您的某些消费者由于某种原因脱机，并且无法处理传入的消息，则此功能非常有用。它还允许一些有趣的特性，比如事务重放等等。坚持是Kafka的特征之一。
共享内存？严格来说，共享内存只允许在单个进程中使用。因此，当您需要从不同的进程访问“共享内存”时，通常不能使用它。而且，当你的应用程序在多台主机上运行时，绝对不可能有“共享内存”。不过，内存中也有代理。就像redis可以用作消息代理一样，它都在内存中。然而，如果这样一个代理因为某种原因重新启动，那么你将失去一切。谈到redis：它有两个专门用来处理重启的持久性配置。
我不确定rabbitmq，但它可能会在消费者默认确认消息后删除消息。所以更接近1:1的心理模型。但是，rabbitmq也使用磁盘持久性。