Распределенные системы: поддержание согласованности временных меток между различными узлами.

Контекст

У нас распределенная система. Мы испускаем события из одной из этих систем, которые считываются из другой системы для генерации отчета.

Логический порядок обеспечивается тем, что даже если система-эмиттер имеет N узлов, подчеркнут конечный автомат, который делает невозможным одновременную эмиссию события для одного агрегата. Эти события отмечаются временной меткой. N узлов не всегда могут синхронизироваться по времени.

Мы так заботимся о метке времени, потому что нижестоящая система, которая генерирует отчеты, почти всегда нуждается в метке времени, потому что «Люди, сообщающие о сообщениях» заботятся о таких данных, чтобы проверить, все ли идет правильно.

Проблема

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

Логический порядок событий таков:

Событие 1 => Событие 2 => Событие 3

Но в базе данных у нас может быть такая ситуация:

-------------------------------------------
|  Name   |  TimeStamp  |  Logical Order  |
-------------------------------------------
| Event 1 |      2      |        1        |
| Event 2 |      1      |        2        |
| Event 3 |      3      |        3        |
-------------------------------------------

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

Хорошо, это не будет происходить каждые 2 секунды, но это может произойти, потому что метка времени поступает из разных узлов. И с точки зрения отчетности это аномалия.

Возможные решения

  1. Сообщите ответственным лицам о возможной проблеме. Мы не можем иметь один глобальный источник времени (NTP не является хорошим решением по ряду веских причин), так что если есть расхождения в очень небольшое количество времени, это не проблема, и это означает, что «это событие произошло вокруг этого время".
  2. Обеспечьте согласованность временных меток, проверяя, что следующее событие в логическом потоке не может иметь временную метку, меньшую, чем предыдущее событие, что делает их равными. Это неправда, но поток остается согласованным даже с точки зрения не разработчика.

Есть ли у вас опыт по этой теме?


events timestamp distributed-system
person Mirko Bonadei    schedule 23.11.2013    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Если вы можете обеспечить причинно-следственную связь и иметь частичный порядок, я не вижу особых проблем в представлении «полезного бизнес-представления» с измененной отметкой времени. Я думаю, что базовая распределенная архитектура не соответствует бизнес-области.

Они, вероятно, понимают систему в целом, и принудительное изменение их ментальной модели может вызвать некоторые трения.

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

person Emanuele Rampichini    schedule 23.11.2013
comment
Итак, внутри базы данных я оставляю заданную временную метку... И только в системе отчетов я выполняю трюк, чтобы представить согласованные данные. Спасибо за ваше мнение. - person Mirko Bonadei; 23.11.2013

arrow_upward
1
arrow_downward

Исходя из вашего вопроса, я предполагаю, что временная метка генерируется до того, как событие будет прочитано конечным автоматом. Я бы посоветовал вам сортировать события по отметке времени вместо использования logical order. При работе с распределенными системами рекомендуется иметь один и только один способ сортировки событий.

Что касается распределенной последовательной генерации идентификаторов, я рекомендую вам взглянуть на этот ответ и к snowflake, упомянутому в предыдущей ссылке. Последний предоставляет распределенную службу, которую можно использовать в качестве централизованного генератора маркеров. Идентификаторы, сгенерированные снежинкой, состоят из: временной метки, рабочего номера и порядкового номера.

TL;DR

Если отметка времени достаточно надежна, чтобы гарантировать порядок событий, я предлагаю вам использовать ее вместо logical order, которая, как я предполагаю, генерируется после того, как отметка времени была.

Хо это помогает

person FlaPer87    schedule 23.11.2013
comment
Чао Флавио. :-) Мы используем MongoDB в качестве хранилища, и MongoId здесь хорош. Конечный автомат генерирует события. Таким образом, мы имеем здесь гарантированный логический порядок. Проблема заключается в узлах, которые могут иметь разные временные метки, и переход из состояния 1 в состояние 2 может произойти на узле 1, а переход из состояния 2 в состояние 3 может произойти на машине 2... Если на этих машинах разные настенные часы, я не могу доверять порядку временных меток. . - person Mirko Bonadei; 23.11.2013
comment
Я думаю, что Флавио предлагает запрашивать время или порядковый номер в централизованной службе, чтобы они всегда были согласованы? Этот сервис может совместно использоваться Aggregate, чтобы он был масштабируемым (опять же, внутри Aggregate существует только согласованность). - person giorgiosironi; 23.11.2013
comment
Ждать! Я получаю это сейчас. Спасибо, Джорджио. Давайте посмотрим на снежинку. - person Mirko Bonadei; 23.11.2013
comment
Джорджио, верно! Кроме того, ObjectID гарантирует FIFO с точностью до 1 секунды, а порядковый номер, встроенный в ObjectID, может быть перезапущен, что нарушит гарантию FIFO. - person FlaPer87; 23.11.2013