Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Finder_b, Вы писали:


vsb>>>Будем считать, что очередь работает всегда и данные в ней никогда не теряются.
F_>>Вы же понимаете что это нереально? Сервис очередей высоконагруженный и персистентный. Последнее означает, что по CAP теореме будет низко-надежным и плохо-масштабирующимся. Читай как самой часто-ломающейся частью системы.

S>А почему тут вылетают A(низко-надежным) И P(плохо-масштабирующимся), если по CAP теореме наоборот должно остаться 2 из 3, а вылететь одна буква?
S>"Выберите 2 из 3".
Для очереди в бинес-приложени Сonsistency очень важно — его отсутствие означает как потерю сообщений так и их реордеринг. Остается A или P. Чистое CA и CP существуют лишь в математическом мире. Они обычно довольно бессмысленные в реальной системе. По тому что такая система будет рассыпаться от малейшего чиха, без возможности ее поднять. Обычно делают какую-то комбинацию из всех трех. Например, приложение в 80% аварий себя как CP и 5% аварий ведет себя как AP. Это классическая база данных с репликаций на стандбай, в другой датацентр. С подтверждением записи из другого датацентра при комите. Если связь между датацентрами рвется то админы отключат репликацию на стенбай. При этом С неизбежно теряется. При последующем отказе мастера, база стенбай уже не сможет вернуть тот-же ответ на запрос. Падения аплинка и базы не так маловеротно, как может показатся на первый взгляд, так как аварии сильно коррелирует, из-за человеческого фактора. Формулу такой реальной базы данных можно написать так C:0.80 P:0.80 A:0.05 . 35% съедают не оптимальности реализации. Например админы могут случайно включить стендбай в продовый режим при разрыве связи. Провести некорректную смену мастера. Криво настроить сеть. В базе данных есть баги мешающее корректной репликации и тп. Вообще получить чистую CP систему можно только в идеальном математическом мире. Возможно получить 100% в Consistency. Я делал статическую валидацию кода, которая доказывала что программа обладает 100% Consistency. Но тот код который который проходил эту валидацюю, я ни кому не пожелал бы увидеть в проде. Там одновременно использовалась теория графов, теория параллельных вычислений, дискретные топологи, event-soursing и теория акторов. Еще и элементы из блокчейна, связанных с нахождение целостности цепочки. Без блокчейна можно было обойтись, но это было забавно . Изначальный который я реализовывал, был в разы проще чем у кафки.

Таким образом поскольку мы не можем получить ста процентов на ни на C ни на P. Система будет плохо масштабироватся, и часто ломаться. Мы можем только управлять этими вероятностями. Хуже всего то, что иногда она будет ломаться при попытке масштабироватся. Что для программы, у которой не доказано что она 100% C, почти гарантированно приводит к потере Сonsistency. Что ведет нас к рердеренгу сообщений или их потере (в реальной системе обычно нет разницы что из двух произошло).

vsb>>>Вообще по сути вся эта машинерия очень напоминает что-то вроде state machine, где всё распределено, схема неявным образом спрятана в коде, который обрабатывает это всё.
F_>>Да, сага и есть такой конечный автомат, где на каждой стадии выполняется какая-то работа.
F_>>Это реализации паттерна workflow. Но заточенные на другое.
S>А чем в данном контексте state machine от workflow отличается?
С математической точки зрения не чем не отличается. Они изоморфны друг-другу. То-есть помощью достаточного количества вложенных саг, можно реализовать любой workflow. С помощью достаточно сложного workflow можно описать любую сагу. Оба это частные случаи eventualy-consistensy конечного автомата. Я это различи понимаю так. Сага — это линейное последовательность шагов выполняемых строго один за другим, для каждого из которых на случай сбоя описан сценарий отката, который тоже состоит из линейной последовательности шагов. При реализации в лоб получается n*(n+1)/2 шагов. Workflow это полноценный граф состояний, в котором мы описываем в куда мы можем перейти из каждого состояния в каждом возможном случае. В случае если результат операции такой — переходим сюда, если второй переходим туда, если случалась ошибка1 в третье состояние, если ошибка2 то в четвертое. При том во многих концепциях мы еще и управляем данными которые получаем на каждом шаге. Это мягко скажем не правильно объяснение, зато простое и понятное .
Чистые саги как и чистые воркфло не кто не использует. Представь как прописывать сотни шагов отката для большой саги из чуть более десятка шагов, или сотни возможных переходов для такого же форквло. На такое извращение не способны даже суровые корпоративные программисты. По этому в реальности использую гибриды.

F_>>Раньше ими решали проблему того как быстро поправить бизнес процесс если деплой приложения происходит один раз в два года.
S>Т.е. пропатчить dll с соотв. wf и отправить заказчику?
Нет воркфло хранились централизованно в базе данных в виде различных конфигов или в специальном сервисе который отдавал эти настройки. Конечно, в теории, код в виде конфигов ни чем не отличается от кода в виде текста на языке программирования. Практика показывает, что сломать его еще проще — тесты на конфиги я не видел не разу в жизни. Но в забюрократизированных компаниях согласовать обновление конфигурации гораздо проще чем обновление приложения. Хотя знал одну систему где критически к обновлению код хранился в блобах базы данных, в виде собраных модулей (class фалы java, загружались специальным класс-лоадром).

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

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Finder_b, Вы писали:


vsb>>>Будем считать, что очередь работает всегда и данные в ней никогда не теряются.
F_>>Вы же понимаете что это нереально? Сервис очередей высоконагруженный и персистентный. Последнее означает, что по CAP теореме будет низко-надежным и плохо-масштабирующимся. Читай как самой часто-ломающейся частью системы.

S>А почему тут вылетают A(низко-надежным) И P(плохо-масштабирующимся), если по CAP теореме наоборот должно остаться 2 из 3, а вылететь одна буква?
S>"Выберите 2 из 3".
Для очереди в бинес-приложени Сonsistency очень важно — его отсутствие означает как потерю сообщений так и их реордеринг. Остается A или P. Чистое CA и CP существуют лишь в математическом мире. Они обычно довольно бессмысленные в реальной системе. По тому что такая система будет рассыпаться от малейшего чиха, без возможности ее поднять. Обычно делают какую-то комбинацию из всех трех. Например, приложение в 80% аварий себя как CP и 5% аварий ведет себя как AP. Это классическая база данных с репликаций на стандбай, в другой датацентр. С подтверждением записи из другого датацентра при комите. Если связь между датацентрами рвется то админы отключат репликацию на стенбай. При этом С неизбежно теряется. При последующем отказе мастера, база стенбай уже не сможет вернуть тот-же ответ на запрос. Падения аплинка и базы одновременно не так маловероятно, как может показаться на первый взгляд, так как аварии сильно коррелирует, например из-за человеческого фактора. Формулу такой реальной базы данных можно написать так C:0.80 P:0.80 A:0.05 . 35% съедают не оптимальности реализации. Например админы могут случайно включить стендбай в продовый режим при разрыве связи. Провести некорректную смену мастера. Криво настроить сеть. В базе данных есть баги мешающее корректной репликации и тп. Вообще получить чистую CP систему можно только в идеальном математическом мире. Возможно получить 100% в Consistency. Я делал статическую валидацию кода, которая доказывала что программа обладает 100% Consistency. Но тот код который который проходил эту валидацию, я ни кому не пожелал бы увидеть в проде. Там одновременно использовалась теория графов, теория параллельных вычислений, дискретные топологи, event-soursing и теория акторов. Еще и элементы из блокчейна, связанные с нахождение целостности цепочки. Без блокчейна можно было обойтись, но это было забавно . Изначальный алгоритм, который я реализовывал, был в разы проще чем у кафки.

Таким образом поскольку мы не можем получить ста процентов на ни на A ни на P. Система будет плохо масштабироватся, и часто ломаться. Мы можем только управлять этими вероятностями. Хуже всего то, что иногда она будет ломаться при попытке масштабироватся. Что для программы, у которой не доказано что она 100% C, почти гарантированно приводит к потере Сonsistency. Что ведет нас к рердеренгу сообщений или их потере (в реальной системе обычно нет разницы что из двух произошло).

vsb>>>Вообще по сути вся эта машинерия очень напоминает что-то вроде state machine, где всё распределено, схема неявным образом спрятана в коде, который обрабатывает это всё.
F_>>Да, сага и есть такой конечный автомат, где на каждой стадии выполняется какая-то работа.
F_>>Это реализации паттерна workflow. Но заточенные на другое.
S>А чем в данном контексте state machine от workflow отличается?
С математической точки зрения не чем не отличается. Они изоморфны друг-другу. То-есть помощью достаточного количества вложенных саг, можно реализовать любой workflow. С помощью достаточно сложного workflow можно описать любую сагу. Оба это частные случаи eventualy-consistensy конечного автомата. Я это различия понимаю так. Сага — это линейное последовательность шагов выполняемых строго один за другим, для каждого из которых на случай сбоя описан сценарий отката, который тоже состоит из линейной последовательности шагов. При реализации в лоб получается n*(n+1)/2 шагов. Workflow это полноценный граф состояний, в котором мы описываем в куда мы можем перейти из каждого состояния в каждом возможном случае. В случае если результат операции такой — переходим сюда, если второй переходим туда, если случалась ошибка1 в третье состояние, если ошибка2 то в четвертое. При том во многих концепциях мы еще и управляем данными которые получаем на каждом шаге. Это мягко скажем не правильно объяснение, зато простое и понятное .
Чистые саги как и чистые воркфло не кто не использует. Представь как прописывать сотни шагов отката для большой саги из чуть более десятка шагов, или сотни возможных переходов для такого же форквло. На такое извращение не способны даже суровые корпоративные программисты. По этому в реальности использую гибриды.

F_>>Раньше ими решали проблему того как быстро поправить бизнес процесс если деплой приложения происходит один раз в два года.
S>Т.е. пропатчить dll с соотв. wf и отправить заказчику?
Нет воркфло хранились централизованно в базе данных в виде различных конфигов или в специальном сервисе который отдавал эти настройки. Конечно, в теории, код в виде конфигов ни чем не отличается от кода в виде текста на языке программирования. Практика показывает, что сломать его еще проще — тесты на конфиги я не видел не разу в жизни. Но в забюрократизированных компаниях согласовать обновление конфигурации гораздо проще чем обновление приложения. Хотя знал одну систему где критически к обновлению код хранился в блобах базы данных, в виде собраных модулей (class фалы java, загружались специальным класс-лоадром).

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