Можно ли использовать Apache Kafka в качестве «политики бесконечного хранения» в качестве основы для системы на основе событий с CQRS?

Question

В настоящее время я оцениваю варианты проектирования / реализации архитектурного подхода Event Sourcing + CQRS к проектированию системы. Поскольку мы хотим использовать Apache Kafka для других аспектов (обычный обмен сообщениями pubsub + потоковая обработка), следующим логическим вопросом будет «Можно ли использовать хранилище Apache Kafka в качестве хранилища событий для CQRS»? Или большеважно ли это было бы разумным решением?

Прямо сейчас я не уверен в этом. Этот источник, кажется, поддерживает это: https://www.confluent.io/blog/okay-store-data-apache-kafka/

Этот другой источник рекомендует против: https://medium.com/serialized-io/apache-kafka-is-not-for-event-sourcing-81735c3cf5c

В моих текущих тестах / экспериментах у меня возникают проблемы, аналогичные описаннымВторой источник:

1. перекомпоновка сущности: Кажется, что Кафка не поддерживает быстрый поиск / поиск определенных событий в теме (например: все команды, связанные сИстория заказа - необходимая для восстановления экземпляра объекта, кажется, требует сканирования всех событий темы и фильтрации только тех, которые соответствуют определителю идентификатора объекта, что не подходит). [Этот другой человек, похоже, пришел к аналогичному выводу: Запрос темы Кафки для конкретной записи - то есть это просто невозможно (не полагаясь на какой-то хакерский трюк)]
2. - согласованность записи: Kafka не поддерживает транзакционную атомарность в своем хранилище, поэтому кажется обычной практикой просто размещать БД с некоторым подходом блокировки (обычно оптимистической блокировкой) перед асинхронным экспортомсобытия в очередь Кафки (хотя я могу с этим смириться, первая проблема для меня гораздо важнее).
3. Проблема с разделами: В документации Кафки упоминается, что«Гарантия заказа», существует только в разделе «Раздел темы». В то же время они также говорят, что раздел является основной единицей параллелизма, другими словами, если вы хотите распараллелить работу, распределите сообщения по разделам (и, конечно, посредникам). Но это проблема, потому что «Хранилище событий» в системе источников событий требует гарантии заказа, поэтому это означает, что я вынужден использовать только 1 раздел для этого варианта использования, если мне абсолютно необходима гарантия заказа. Это правильно?

Несмотря на то, что этот вопрос немного открыт, на самом деле это так: использовали ли вы Кафку в качестве основного хранилища событий в системе источников событий? Как вы справились с проблемой перекомпоновки экземпляров сущностей из их истории команд (учитывая, что в этой теме миллионы записей сканируют весь набор, это не вариант)? Использовали ли вы только 1 раздел, жертвуя потенциальными параллельными потребителями (учитывая, что гарантия заказа ограничена определенным тематическим разделом)?

Любая конкретная или общая обратная связь будет принята с благодарностью, поскольку это сложная тема с несколькими соображениями.

Заранее спасибо.

РЕДАКТИРОВАТЬ Там6 лет назад было похожее обсуждение: Использование Kafka как (CQRS) Eventstore. Хорошая идея? Консенсус тогда также был разделен, и многие люди, которые считают этот подход удобным, упомянули, как Кафка изначально имеет дело с огромными объемами данных в реальном времени. Тем не менее, проблема (по крайней мере для меня) не связана с этим, но больше связана с тем, насколько неудобны возможности Kafka для восстановления состояния сущности. Либо путем моделирования тем в качестве экземпляров сущностей (где экспоненциальный рост количества тем нежелателен)или путем моделирования тем или типов сущностей (когда количество событий в теме делает восстановление очень медленным / непрактичным).

Answer 1

ваше понимание в основном верно:

1. Кафка не имеет поиска. определенно не по ключу. есть попытка установить временную метку, но она несовершенна и не подходит для того, что вы пытаетесь сделать.
2. Кафка на самом деле поддерживает ограниченную форму транзакций (смотрите ровно один раз) в эти дни, хотя если вы взаимодействуете с любой другой системой за пределамииз кафки они будут бесполезны.
3. единица чего-либо в кафке (упорядочение событий, доступность, репликация) является разделом. нет никаких гарантий для разделов одной и той же темы.

все эти действия не мешают приложениям использовать kafka в качестве источника истины для своего состояния, если:

1. Ваша проблема может быть «разделена» на тематические разделы, поэтому вам не нужен порядок событий между разделами
2. вы готовы «воспроизвести» весь раздел, если / когда вы потеряете локальное состояние в качестве загрузчика.
3. вы используете сжатые в журнале темы, чтобы попытаться сохранить их размер (поскольку вам нужно будет воспроизвести их для начальной загрузки, см. Выше)

samza и (IIUC) kafka-streams назадих государственные хранилища с логиками, запакованными в кафку. внутренне для офсета kafka и управления группами потребителей хранятся в виде сжатой в журнале темы с посредниками, имеющими «материализованное представление» в памяти - когда владелец раздела __consumer_offsets перемещается между посредниками, новый лидер воспроизводит раздел, чтобы перестроить это представление.