Согласованность данных на нескольких микросервисах, которые дублируют данные - PullRequest
Новая
       12

Согласованность данных на нескольких микросервисах, которые дублируют данные

1 голос
/ 26 марта 2019

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

Однако я не могу понять, что делать в следующем случае для обеспечения согласованности:

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

Мой код выглядит примерно так: 

             ...
            _dbContext.Add(customer);
            CustomerRegistered e = Mapper.Map<CustomerRegistered>(customer);
            await _messagePublisher.PublishMessageAsync(e.MessageType, e, "");
            //!!app crashes
            _dbContext.SaveChanges();
            ...

Итак, я хотел бы знать, как я могу обработать такой случай, когда приложение отправляет сообщение, но не может сохранить сами данные? Конечно, я мог бы поменять методы DbContextSave и PublishMessage , но проблема все еще остается. Что-то не так с моим подходом к хранению данных?

1 Ответ

0 голосов
/ 26 марта 2019

Да. Вы делаете двойное постоянство - постоянство в БД и длительную очередь. Если одному удастся, а другому не удастся, у тебя всегда будут проблемы. Есть несколько способов справиться с этим:

  1. Сохранение в БД, а затем изменение захвата данных (CDC) таким образом, чтобы данные из журнала опережающей записи в БД (WAL) использовались для создания материализованного представления во второй сервисной БД с использованием потоковой передачи в реальном времени

  2. Сохранение в долговременной очереди и кэше. Используя потоковую передачу в реальном времени, сохраняйте данные в обеих службах. Чтение данных из кэша, если данные доступны в кэше, в противном случае чтение из БД. Это позволит читать после записи. Даже если в худшем случае запись в кэш завершится неудачно, в течение нескольких секунд данные будут сохранены в БД при потоковой передаче

...