Как я могу обеспечить согласованность при использовании подхода переноса состояния в Kafka?

Question

Давайте предположим упрощенный сценарий, подобный этому:

1. Есть две темы Кафки , пользователи и заказы и три микросервиса обслуживание пользователей , Служба заказа и Служба доставки .

2. Когда заказ размещается через службу заказов, событие OrderCreated добавляется в тему заказов и прослушивается службой доставки . Этот сервис должен получить информацию о пользователе для отправки заказа В соответствии с моими требованиями я не могу сделать REST-вызов пользовательскому сервису, но использую подход с учетом состояния. Другими словами, служба доставки - это приложение Kafka Streams, которое слушает тему пользователя, с таблицей KTable, поддерживаемой локальным хранилищем с полной информацией о таблице пользователя. Таким образом, при обработке заказа в нем уже есть локальная информация о пользователе.

Однако одной из проблем этого подхода является согласованность информации локального пользователя в службе доставки , например:

1. Пользователь обновляет свой адрес доставки в пользовательской службе, он обновляет свою локальную базу данных SQL и публикует событие в теме пользователя с этим изменением.

2. Пользователь размещает заказ, поэтому служба заказа публикует его в теме заказа.

3. По какой-либо причине служба доставки может обработать событие OrderCreated из темы заказа перед тем, как прочитать информацию UserUpdated из темы пользователя, чтобы использовать адрес, который больше не действителен.

Как я могу гарантировать, что служба доставки всегда будет иметь обновленную информацию о пользователе в этом сценарии передачи состояния, переносимого событиями?

Answer 1

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

Вы можете назвать эту тему «user_action» с уникальным идентификатором пользователя в качестве ключа (как обновление информации о пользователе, так и порядок пользователя являются действием пользователя). В вашем случае все три службы будут использовать тему user_action. В то время как служба пользователя учитывает только обновления пользователя, а служба заказов только учитывает заказы, служба доставки учитывает и то и другое.

Этот пост в блоге тоже может помочь: https://www.confluent.io/blog/put-several-event-types-kafka-topic/