Распределенный список атомов c: синхронизация между микроуслугами - PullRequest
Новая
       65

Распределенный список атомов c: синхронизация между микроуслугами

0 голосов
/ 19 февраля 2020

В настоящее время я развернул две службы: front и back:

back запрашивает front ожидающих обработки resources для back.

  1. back запрашивает ожидающие идентификаторы ресурсов для front.
  2. Для каждого полученного идентификатора ресурса:
    • back загружает весь ресурс в соответствии с его id .
    • back переваривает полученный ресурс.
    • back отправляет подтверждение на front.

Работает хорошо, но это не масштабируется. Я имею в виду, что если я хочу масштабировать back до 2-х реплик?

Затем два экземпляра back будут извлекать для ожидания resources независимо от того, переваривает ли другой тот же resource.

Надеюсь, я так хорошо объяснил.

Есть идеи?

Ответы [ 2 ]

0 голосов
/ 24 февраля 2020

Некоторые возможности, с вариациями:

  1. После выдачи ресурса для обработки «front» откладывает его на настраиваемый или указанный в периоде времени запроса: если подтверждение не было получено в течение этого времени «фронт» восстанавливает его. Классы систем, большинство из которых делают это из коробки: message queues, work queues, task queues (например, RabbitMQ 1 , 2 ; но также ActiveMQ , SQS и, возможно, другие), конкретные термины для поиска, например, "acknowledge processing" или "confirm completion".
  2. Служба новичка "back" регистрируется на "front", а затем в некоторой форме "обнаружения живучести". ", например, periodi c heartbeats, используется фронтом, чтобы определить, находится ли он еще. Фронт решает, какой" задний "получает какие ресурсы (например, если 2" задних ": один получает" нечетные "идентификаторы, другой получает" даже "идентификаторы".
  3. Сообщите "обратным" службам об их конфигурации. Например, сделать так, чтобы «обратные» службы участвовали в кластере (например, Zookeeper, etcd, JGroups (если в Java), некоторая форма протокола сплетни). Как только вторая служба «присоединяется» к кластеру, первая служба начинает запрашивать ресурсы с «нечетными» идентификаторами, вторая - с «четными» идентификаторами. Когда служба «умирает», другой узнает об этом и снова начинает запрашивать все идентификаторы. Для меня такой подход выглядит (огромным) излишним в вашем случае.
0 голосов
/ 19 февраля 2020

Не совсем уверен, понял ли я ваш контекст, но это похоже на то, что предлагают многие службы баз данных (+ подобные). Например, Etcd - это распределенное хранилище значений ключей, а не традиционная база данных. Он использует управление версиями ключей (ключ + количество) для отслеживания исторических версий и предоставляет своего рода монитор распределенных транзакций, основанный на алгоритме консенсуса плоту (https://raft.github.io/).

Есть Много подобных услуг на выбор с различными нишами. Они считаются легкими таким же образом unix считаются экземплярами микроуслуг .

...