Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
 Eventual consistency  [new]
vas0
Member

Откуда: Таможенный союз (Россия, Казахстан)
Сообщений: 1279
Многие сейчас топят за микро-сервисную архитектуру. Но вот честно говоря пугает, что мы попадаем в мир "временно" несогласованных данных. Расскажите кто как с этим живет?

Сейчас вот есть возможность, разделить "некую" транзакцию на две отдельные. Основную часть сделать быстро, а вторую часть отложить на "когда-нибудь потом" (но в теории тоже сделать это как можно быстрее). Честно говоря неохота на эту скользкую тропу наступать.
24 сен 19, 13:33    [21977874]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
Неудивительно, но правильный ответ - все зависит от бизнеса.
Даже в такой области как финансы, допускается что банки обмениваются пачкой транзакций лишь в конце дня, что уж говорить об остальные.
Тебе нужно понять, что твое видение мира и видение мира бизнес-owner совершенно различные, во многих бизнес-процессах заложены flow для факап-path, например авиакомпании проще дать в продажу 102 билета вместо 100, и потом выслать письма разочарования двум клиентам и предложить им скидку 50% на следующий рейс, чем тратить миллиард на систему без eventual consistency. Бизнес живет так десятилетиями, а твоя система позволит сократить окно eventual-consistency с дней до пары минут и бизнес будет счастлив.

Другое дело, когда вводят eventual consistency потому что это модно, стильно, молодежно ну и шоп быстрее работало. Тут надо открещиваться всеми способами.
24 сен 19, 13:57    [21977906]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2089
vas0,
Приведи более конкретный пример. Да хоть вымышленный.
24 сен 19, 14:23    [21977953]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
vas0
Member

Откуда: Таможенный союз (Россия, Казахстан)
Сообщений: 1279
PetroNotC Sharp,

Более подробно.

Есть основной модуль, который "владеем" данными. Есть зависимые модули, которые тоже должны обновлены при изменении этих данных.

Сейчас все реализовано в рамках одной транзакции. Это хорошо с точки зрения согласованности. Но есть недостатки: связность, и если ошибка в одном модуле идет откат всей транзакции.

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

Плюсы это как раз развязать зависимости и уменьшить влияние "глючных" модулей на все остальные.

Но тут можно таких проблем огрести по согласованности данных, что потом замучаешься разгребать. Поэтому хотелось бы услышать success stories, перед реализацией всей этой затеи.
24 сен 19, 14:38    [21977971]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4838
vas0
Многие сейчас топят за микро-сервисную архитектуру. Но вот честно говоря пугает, что мы попадаем в мир "временно" несогласованных данных. Расскажите кто как с этим живет?


Никак. Начинают рассказывать друг другу саги :-)

vas0
Сейчас вот есть возможность, разделить "некую" транзакцию на две отдельные. Основную часть сделать быстро, а вторую часть отложить на "когда-нибудь потом" (но в теории тоже сделать это как можно быстрее). Честно говоря неохота на эту скользкую тропу наступать.


Не, ну можно через двухфазный комит...

А так, нужно смотреть насколько нужна именно распределенная транзакция.
Возможно есть другой способ решения задачи.
24 сен 19, 14:43    [21977976]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4838
vas0
Но тут можно таких проблем огрести по согласованности данных, что потом замучаешься разгребать. Поэтому хотелось бы услышать success stories, перед реализацией всей этой затеи.


Э-э-э огласите весь список пожалуйста.

Возможно временная не согласованность не так страшна.
Либо поделить данные таким образом, чтобы не нужно была абсолютная согласованность.
24 сен 19, 14:46    [21977981]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
vas0
Member

Откуда: Таможенный союз (Россия, Казахстан)
Сообщений: 1279
mad_nazgul
vas0
Но тут можно таких проблем огрести по согласованности данных, что потом замучаешься разгребать. Поэтому хотелось бы услышать success stories, перед реализацией всей этой затеи.
Э-э-э огласите весь список пожалуйста.

Возможно временная не согласованность не так страшна.
Здесь самое страшное, это как в поговорке.
Нет ничего более постоянного чем временное ©
24 сен 19, 14:53    [21978004]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7927
Как уже сказали, все зависит от бизнеса. Сам термин "согласованность" он как бы достаточно расплывчат и его можно трактовать как угодно. Например сейчас занимаюсь биллингом и что значит "согласованность" ? В реальности, например для бухгалтерии, "согласованность" это сдать документы в налоговую и что бы в них не было особой лажи. Т.е. с точки зрения бухгалтерии, транзакция - это один __месяц__. Т.к. если отчеты по движению расходятся с книгой покупки-продажи и не бьются с сальдо на конец месяца (а сейчас, из-за смены НДС 18 --> 20 % сальдо на конец месяца физически не может побиться с сальдо на начало месяца + движение за месяц ))) как хочет бухгалтерия ) - то для бухгалтерии данные становятся не согласованными.

К чему это я: Понятие "согласованные" чисто условное, т.ч. проблема "не согласованности" IMHO это чисто documentation bug. Опишите то, что кто то называет "не согласованно" в документации и все само собой станет "согласованно" )))

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

IMHO & AFAIK

"Ребята, вы меня ерундой не грузите. Я стратегией занимаюсь." ( C ) сова - стретегический консультант
24 сен 19, 14:58    [21978021]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2089
vas0
если ошибка в одном модуле идет откат всей транзакции.
вы смешали бизнес откат транзакции и форс мажор глючных модулей.
Странно. Вы вроде опытный.
24 сен 19, 15:37    [21978093]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7927
PetroNotC Sharp
vas0
если ошибка в одном модуле идет откат всей транзакции.
вы смешали бизнес откат транзакции и форс мажор глючных модулей.
Странно. Вы вроде опытный.

IMHO & AFAIK

Ну вроде это стандартное поведение. В случае не предсказумой ошибки (не обрабатываемой), откатываем всю транзакцию, что бы случайно из-за ошибки программиста не наделать бизнес-лажи
24 сен 19, 15:40    [21978101]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2089
Leonid Kudryavtsev,

Они в разных стеках идут из за
Catch
Ошибки непонятно какие
Catch
Ошибки sql
....
24 сен 19, 15:56    [21978121]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7927
Какая разница, какая __непредусмотренная программистом__ ошибка произошла: SQL или null pointer exception?
Если произошла непредусмотренная ошибка, поведение программы и результат НЕпредсказуем - сохранять данные нельзя.
24 сен 19, 16:19    [21978165]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
mayton
Member

Откуда: loopback
Сообщений: 42385
vas0
Многие сейчас топят за микро-сервисную архитектуру. Но вот честно говоря пугает, что мы попадаем в мир "временно" несогласованных данных. Расскажите кто как с этим живет?

Сейчас вот есть возможность, разделить "некую" транзакцию на две отдельные. Основную часть сделать быстро, а вторую часть отложить на "когда-нибудь потом" (но в теории тоже сделать это как можно быстрее). Честно говоря неохота на эту скользкую тропу наступать.

Давай представим что человечество вышло в открытый космос.
Средства связи при этом остались. Сохранили свои физические свойства. Тоесть скорость 300 000 километров в секунду
остается непреодолимым барьером. (Оставим пока разговоры про кванты и тахионы. Фантастика пока фантастика).
Скорость света в вакууме и скорость радио-волны примерно равны.

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

Тоесть если у вас две информационные системы на Земле и на Марсе то надо проектировать их взаимодействие
так что IP пакет долетает в 1 сторону за 20 минут (я когда-то считал это время. могу пересчитать заново).
Раундтрип соотвественно за 40 минут. В лучшие времена когда Марс пролетат близко эта задержка может
падать.

Если вы строите инфо-систему мы можем расчитывать на такую-себе ленивую электронную почту.
Или на JMS в одну сторону с очень сложным протоколом отбивки потеряных пакетов.

Давайте рассуждать в этом направлении.

Eventual consistency - нам нужна. Нам нужна идемпотентность. И односторонняя репликация класса мастер-подчиенный.
Или master-slave. Или синхронизация файлов в 1 сторону. Как rsync.
24 сен 19, 16:27    [21978181]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7927
В 90-х у нас была система, где обмен данными осуществлялся на дискетах

Таких умных слов. как "Eventual consistency" тогда и не слыхивали и, в целом. система была полностью "Eventual НЕ consistency" но работала. Другое дело, что в случае "Eventual НЕ consistency" справочников на отдельных компьютерах, оператору приходилось (заставляли) ручками эти справочники синхронизировать.

а вообще, стал читать статью про "Eventual consistency" в Вики, вроде же все и так разжованно по самое не хочу: (B)asically (A)vailable vs (S)oft state vs (E)ventually consistent
24 сен 19, 16:55    [21978228]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2089
vas0
Есть основной модуль, который "владеем" данными. Есть зависимые модули, которые тоже должны обновлены при изменении этих данных.
вы куда пропали из ответов?
У нас модуль Кадры владеет данными кадров. Модуль Склад влалеет данными склада.
А вас в ответе что странное. Не находите?
24 сен 19, 17:07    [21978249]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
mayton
Member

Откуда: loopback
Сообщений: 42385
Leonid Kudryavtsev, мне вспоминаются экзотические DBMS наподобие event-store. И CQRS.
Мне кажется они идеальный с точки зрения эвентов. Событие где-то случилось.
Оно записано в лог. Рано или поздно оно распространяется на всех заинтересованных.
Через милисекунду или через час все узнают правильный state бизнес-информации.
24 сен 19, 18:31    [21978345]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
Sergunka
Member

Откуда: Bay Area, CA
Сообщений: 1967
Походу Вы неизбежно подходите к обсуждению CAP теоремы

https://ru.wikipedia.org/wiki/Теорема_CAP

автор
Теорема CAP (известная также как теорема Брюера) — эвристическое утверждение о том, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств:

согласованность данных (англ. consistency) — во всех вычислительных узлах в один момент времени данные не противоречат друг другу;
доступность (англ. availability) — любой запрос к распределённой системе завершается корректным откликом, однако без гарантии, что ответы всех узлов системы совпадают;
устойчивость к разделению (англ. partition tolerance) — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.
24 сен 19, 21:14    [21978443]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2089
mayton
CQRS
да, но много и недостатков. Первый, под него нужен новый проект. То есть все переписать.
25 сен 19, 10:01    [21978619]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
mayton
Member

Откуда: loopback
Сообщений: 42385
Конечно. Eventual consistency потребует.

Кстати современный процессор с 3 слоями кешей тоже можно рассматривать как сабж.
25 сен 19, 10:30    [21978652]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
mayton
Member

Откуда: loopback
Сообщений: 42385
Почтовые протоколы. JMS/MQ системы. Шина сообщений.
25 сен 19, 14:34    [21978962]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
vas0
Member

Откуда: Таможенный союз (Россия, Казахстан)
Сообщений: 1279
mayton
Почтовые протоколы. JMS/MQ системы. Шина сообщений.
Да к этому склоняюсь.
25 сен 19, 15:52    [21979036]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 2089
vas0
mayton
Почтовые протоколы. JMS/MQ системы. Шина сообщений.
Да к этому склоняюсь.
ну и делай.
Как будто слово "микросервисы" в топике тебе что то дало.
Во всем мире приложения делят на dll, на jar, на модули, на подприложения.
Только у тебя почему то странный вопрос выше о том как делят приложения.
25 сен 19, 17:05    [21979103]     Ответить | Цитировать Сообщить модератору
 Re: Eventual consistency  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 2343
vas0
Поэтому хотелось бы услышать success stories, перед реализацией всей этой затеи.

В ozon.ru используют Apache Kafka и саги... и вполне себе успешно...
26 сен 19, 21:55    [21980321]     Ответить | Цитировать Сообщить модератору
Все форумы / Java Ответить