Обновите центральный кеш, изменив системное изменение данных в масштабной архитектуре микросервисов.

Question

Мы создаем микросервисную систему, новые данные которой могут поступать из трех (или более) разных источников и которая в конечном итоге влияет на конечного пользователя.
Неважно, какова цель системы для этого вопроса, поэтому я действительно постараюсь сделать это проще. Пожалуйста, смотрите прилагаемую схему.

Данные могут поступать из следующих источников:

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

Услуги:

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

Основная идея:

1. Каждый микросервис имеет свою собственную базу данных.
2. Каждый микросервис может масштабироваться.
3. Каждое изменение данных в одной из трех частей влияет на пользователя и должно быть отправлено в службу кэширования, чтобы в конечном итоге это отражалось на основном сайте.
4. Кэш (Redis) содержит все данные, объединенные с предварительно подготовленными ответами для основного сайта.
5. Каждое изменение данных службы будет публиковаться в теме pubsub для службы кэша для обновления базы данных Redis.
6. Система должна обслуживать около 200 миллионов пользователей.

Итак ... вопросы: .

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

3. Можно ли вообще подготовить ответы на основе нескольких источников, которые могут периодически меняться? как правильно подойти к этой проблеме?

   

Answer 1

Я постараюсь ответить на некоторые ваши вопросы, дайте мне знать, если я неправильно понял, что вы спрашиваете.

1) Я полагаю, что вы спрашиваете о том, как обеспечить порядок сообщений, чтобы старое обновление не перекрывало более новое. Есть поле «publish_time» сообщения (https://cloud.google.com/pubsub/docs/reference/rpc/google.pubsub.v1#google.pubsub.v1.PubsubMessage) для координации на основе времени, когда облачный сервер pubsub получил ваш запрос на публикацию. Если вы хотите координировать на основе какого-либо другого времени или механизма упорядочения, вы можете добавить атрибут к ваше PubsubMessage или полезная нагрузка для этого.

2) Кажется, это общая проблема синхронизации, не обязательно связанная с облачным pubsub; Я оставлю это другим, чтобы ответить.

3) Облачный поток данных реализует механизм управления окнами и водяными знаками, аналогичный тому, что вы описываете. Возможно, вы могли бы использовать это для удаления конфликтующих обновлений и выполнения предварительной обработки перед записью их в резервное хранилище. https://beam.apache.org/documentation/programming-guide/#windowing

-Daniel