Возможная согласованность с одной базой данных

Охватывает ли возможная согласованность только репликацию данных (копии одних и тех же данных):

Чтобы привести пример без копий одних и тех же данных:

  • У меня есть одна единственная база данных.
  • У меня есть микросервис A, который выполняет действие. Допустим, я вношу средства на свой банковский счет. Микросервис в этом примере обрабатывает ТОЛЬКО хранение ваших депозитов и снятий средств, но не имеет ничего общего с вашей учетной записью.
  • Когда микрослужба A завершает работу, она сообщает микрослужбе B, что ей необходимо обновить балансы в учетной записи.
  • Микросервис B обновляет остатки на счетах

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

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


comment
Особенно при работе с деньгами ваша база данных должна иметь согласованность транзакций. Один микросервис должен делать депозиты, снимать деньги и поддерживать баланс, чтобы обновления базы данных могли выполняться успешно или вместе.   -  person Gilbert Le Blanc    schedule 19.02.2021
comment
Не думаю, что вы найдете авторитетный ответ на этот вопрос. Для аудитории, которая работает над очень сложной проблемой распределенного хранилища, это почти наверняка не будет согласованностью в конечном счете. Но в других сообществах, которые используют этот словарь более щедро, почему бы и нет?   -  person VoiceOfUnreason    schedule 19.02.2021


Ответы (1)


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

Вместо этого рассмотрите базу данных, которая отслеживает онлайн-игру. Всякий раз, когда вы выигрываете матч, база данных немедленно сохраняет результат матча. Он также публикует событие с информацией о результате на асинхронной шине публикации/подписки.

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

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

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

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

Приведенный выше пример основан на асинхронности и некоторой денормализации, но при таких обстоятельствах вы можете легко спроектировать в конечном счете непротиворечивые системы даже для одной базы данных.

person Mark Seemann    schedule 19.02.2021
comment
Шикарный пример, спасибо. - person user3007447; 20.02.2021