Comments 9
Не хватает, например, детерминированных транзакцй
ACID при оркестрации и хореографии – весьма спорный вопрос в части «I»
Не озвучен главный вывод: только старый добрый monolith и 2PC может гарантировать ACID (табличка нагло врет). Все остальные способы -- это велосипеды, которые в лучшем случае дают BASE и иллюзию транзакционности, при этом заставляя пользователя чуть менее чем полностью перелопатить определенным образом всю бизнес операцию, а также на порядок усложнить архитектуру. И ни в одном подобном анализе не озвучены гарантии и ограничения, которые предполагает каждый из способов. Кроме того, все предложенные "велосипеды" сфокусированы только на скоординированной записи, замалчивая такую важную вещь как консистентное чтение, где уже потребуется распределенный механизм блокировок.
Мне все эти саги и компенсации кажутся наивным способом переизобрести заново то, что уже было проанализированно и реализовано ранее, а именно: нужен координатор + поддержка 2PC для каждого endpoint-а. Без этого можно до бесконечности извращаться -- никогда не получите консистентной бизнес операции (за исключением множества частных случаев).
а именно: нужен координатор + поддержка 2PC для каждого endpoint-а
Вы всё верно говорите, только при таком подходе скорость записи будет страдать в угоду консистентности.
В общем при увеличении нагрузки когда монолит не справляется и нужна распределенность оказывается, что в этом мире физика запрещает серебрянную пулю и нужно выбирать решение исходя из специфики задачи.
Данная статья отличная как справочный материал. Ей бы добавить больше примеров в каких случаях лучше подходит та или иная архитектура.
Насколько я понимаю БД краеугольной проблемой является определение истинной последовательности исполнения транзакций в распределенной системе.
Вот если бы можно было в каждом ДЦ иметь синхронизированные между всеми атомные часы, то проблема была бы решена. Но такое только Google насколько помню себе смог позволить. И то только для части наиболее важных данных.
В общем при увеличении нагрузки когда монолит не справляется и нужна распределенность оказывается, что в этом мире физика запрещает серебрянную пулю и нужно выбирать решение исходя из специфики задачи.
Там проблема не с монолитом, а с хранилищем. Чтобы создать масштабируемое хранилище, при том консистентное, потребуется механизм распределенных локов, а он отюдь не быстрый и не очень надежный. Распределенные системы хорошо работают, когда архитектура взаимодействия между микросервисами строго линейная или древовидная -- именно для нее по большей части и предложены вышеперечисленные методы. Но чуть сложнее data flow -- и уже не существует никакого универсального решения.
Вот если бы можно было в каждом ДЦ иметь синхронизированные между всеми атомные часы, то проблема была бы решена.
Точное время не поможет упорядочить транзакции -- одна транзакция может начаться раньше, а закончиться позже, чем другая. Их консистентность описывается с точки зрения конечного эффекта (сериализуемость): если существует хотя бы одна цепочка, при которой эти транзакции будут выполняться строго последовательно, и которая дает такие же конечные результаты, то транзакции консистентны.
Во-во. Именно, врет. Если бы было, как в табличке, то не было бы этой статьи. Все децентрализованное - поиск компромиссов.
Спасибо, то мы в соседней теме голову сломали над:
Таков и простой и сложный вопрос, но очень важный:
Есть кафка в которую забрасываем очень много сообщений, например просмотры страниц.
Есть сервис который просыпается в N минут, вычитывает очередь , суммирует результаты и 1 раз делает update в основную базу данных.
Вопрос для знатаков как обеспечить атомарность данной операции с учетом то что электричество может оборваться на любой строке кода
{
var msgs = kafka.readAllMessagesFromLastCheckpoint();
maindb.IncrementField(ID, msgs.Count);
kafka.Commit();
}
Если мы упадем на 3й строке , то данные уже записались в db , и в след раз мы по новой возьмем теже сообщения и еще раз плюплюсуем.
Если сначала долать комит а потом записывать в БД, то если упадем на строке работы с ДБ , то мы просто потеряем эти сообщения.
Заранее спасибо!
Прошу прощения, Каденция, Шаговые функции и Долговечные функции в примерах оркестрации это автоперевод?
Сравнение подходов к реализации распределенных транзакций для микросервисов