Поместить данные сначала в Кафку или Базу данных?

Question

Что такое за и против при размещении данных сначала в Kafka, а затем в базе данных, или другим способом?

Пример: пользователь выполняет вызов REST (POST) для хранения, скажем, продуктов.Обычно я бы взял этот вызов в серверной части и сохранить тело в базе данных (после проверки и все ..).Лучше всего подобрать этот вызов и сохранить данные в Kafka fist, а затем сохранить их в базе данных (в данном случае база данных является потребителем kafka).

Или лучше сохранить егосначала в базу данных, а затем отправить ее кафке?

Спасибо

Answer 1

давайте возьмем пример обоих сценариев с вашим вариантом использования, вызов API для хранения продукта, скажем, PRODUCT1:

ваша база данных: product_table (product_id, product_name, product_info)

псевдокод API:

1. valiadteProductInfo
2. save - сначала в kafka или в DB

ПОДХОД 1 -

сначала сохранение в kafka означает, что вы можете увидеть этот результат в БД через некоторое время, вы вернете идентификатор продукта пользователю, и если пользователь захочет заполнить идентификатор продукта, он не виден.для меня это неправильный подход, так как вам придется обрабатывать многие вещи на стороне пользовательского интерфейса для такой задержки.

APPROACH 2 - сохранение в db сначала и kafka во втором есть дваСценарии: 1. Кафка push синхронизируется в коде - в этом случае при отправке на kafka происходит сбой, который в вашем экономическом случае очень важен, поскольку зависит от других микросервисов.это неправильный подход, но если все в порядке, то в течение <0,001% времени, если push не удается, а затем вы удаляете продукт из БД и возвращаете исключение пользователю.Я думаю, что это вполне нормально. </p>

kafka push - это опрос базы данных на предмет изменений и внесение изменений в kafka (об этом читайте в разделе EventSourcing): в этом случае вы получите 100% гарантию, но небольшую задержку.это также вы можете использовать

Answer 2

Сначала вы захотите создать различные темы, которые будут действовать как очереди в Кафке для ваших данных.Затем у вас будут потребители этих данных, которые будут записываться в вашу базу данных.Это позволит вашей системе быть повторно входящей в случае отказа одного компонента.

Кроме того, если у вас есть какие-либо другие потребители данных, это просто, как создать потребителя очереди kafka и предоставить его вашему потребителю через согласованный общий интерфейс (REST, SOAP, RPC и т. Д.).

Кроме того, вы можете масштабировать производительность, имея несколько читателей по теме, которые затем могут объединять свои запросы в базу данных.

Answer 3

Это полностью зависит от ваших требований.

1. Если вы хотите, чтобы функциональность была:

- при сбое исключения из журнала push в тему kafka и выхода.

- независимо от того, является ли kafka push успешным или нет сохранения данных на вашем конце.

- заставьте потребителя сохранить его в БД.Я предполагаю, что когда вы отправляете сообщение, вы хотите манипулировать данными в вашем методе слушателя.Таким образом, это зависит от того, какое состояние данных вы хотите сохранить в вашей БД.

Кроме того, если вы используете Kafka, вы будете вызывать другой микросервис, является ли ваша таблица, которую вы хотите обновить, доступной для обеих служб, т. Е. Если службы совместно используют базу данных (в идеале, они не будут).

Если база данных не является общей, и вы все еще хотите сохранить эти данные, которые необходимо сохранить до или после вызова pushMessage для kafka, потому что это степень проверки, которую вы можете иметьесли сообщение успешно отправлено или нет.У pushMessage будет метод сбоя, вы можете выдать исключение и там, в зависимости от сбоя, после сохранения данных или выхода.

Answer 4

Я бы предпочел поставить Кафку, так как она имеет гарантию, что сообщение не будет потеряно и оно долговечно.Но если вы поставите 1-е место в db, то у Кафки есть риск, что ваш сервис может упасть между записью в db и kafka.