Kafka не является системой обмена сообщениями строго 1: 1. Несколько производителей могут писать в топи c, а несколько потребителей могут читать из него. Более того, в Kafka нескольким потребителям могут быть назначены одинаковые или разные группы потребителей. Каждое сообщение используется только одним потребителем из каждой группы потребителей (балансировка нагрузки), и все группы потребителей получают копию каждого сообщения (конечно, если они подписаны на соответствующие темы и сообщения не теряются). Хорошее описание этого процесса можно найти в этой статье: Масштабируемость обмена сообщениями Kafka с использованием групп потребителей .
В Kafka все сообщения сохраняются на диске и сохраняются до сжатия пожинает его, или retention.ms проходит, или размер журнала превышен. Это точка зрения очень высокого уровня и здесь много нюансов. Типа: сообщения хранятся в сегментах, каждый сегмент содержит несколько сообщений. Когда для сообщения истекает срок хранения, оно не удаляется из сегмента в этот момент, вместо этого Kafka ожидает, пока все сообщения в этом сегменте не истекут, и удаляет весь сегмент сразу. Кроме того, хранение может происходить до того, как журнал превысит максимальный размер, или наоборот: журнал может превысить размер даже до того, как пройдет период хранения. И так далее. Просто прочтите docs и обратите внимание на темы о «очистке журналов» и «хранении».
После того, как потребитель Kafka прочитает сообщение, оно не сжимается и не просрочено. Таким образом, он не удаляется из журнала и остается там. Это также означает, что каждое сообщение может быть перечитано потребителем при необходимости (пока оно не будет полностью удалено). Это может быть полезно, если некоторые из ваших потребителей отключились по какой-либо причине и не смогли обработать сообщения по мере их поступления. Это также позволяет использовать интересные функции, такие как повтор транзакций и так далее. Постоянство - одна из особенностей Kafka.
Общая память? Ну, строго говоря, общая память разрешена только внутри одного процесса. Таким образом, вы не можете использовать «разделяемую память», когда вам нужно получить к ней доступ из разных процессов. И нет абсолютно никакого способа иметь «разделяемую память», когда ваше приложение работает на нескольких хостах. Однако есть брокеры в памяти. Подобно Redis, его можно использовать в качестве брокера сообщений, и все это в памяти. Однако, если такой брокер по какой-то причине перезапустится, вы потеряете все. Говоря о Redis: он имеет две конфигурации сохраняемости специально для обработки перезапусков.
Я не уверен насчет RabbitMQ, но он, вероятно, удаляет сообщения после того, как потребитель подтвердил их по умолчанию. Так что это ближе к ментальной модели 1: 1. Однако RabbitMQ также использует сохраняемость диска.