Рубрика «согласованность»

в 11:39, , рубрики: backend, конкурентность, согласованность, транзакции

Всем привет! Я Олег, fullstack‑разработчик в компании Тензор, тимлид небольшой команды.

Одна из моих обязанностей в роли тимлида — code review. За годы работы многое повидал и выделил для себя типовые ошибки, с которыми сталкиваются начинающие backend‑разработчики. Сегодня расскажу о некоторых из них.

О чем пойдет речь

Разберем типовые ошибки, которые допускаются при работе с SQL‑базами данных в рамках сервиса с высокой нагрузкой и конкурентными запросами.

В качестве БД возьмем PostgreSQL, в примерах кода будет использоваться как SQL-запросы, так и «некий ORM чем‑то напоминающий Sequelize» (все совпадения случайны).Читать полностью »

в 19:52, , рубрики: paxos, TLA+, Алгоритмы, асимметричность информации, атомарность, высокая производительность, двухфазный коммит, моделирование, распределенные системы, согласованность, транзакции, трёхфазный коммит

В этой статье мы смоделируем и исследуем протокол двухфазного коммита с помощью TLA+.

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

Проблема двухфазного коммита

Транзакция проходит через диспетчеры ресурсов (RM). Все RM должны договориться, будет транзакция завершена или прервана.

Менеджер транзакций (TM) принимает окончательное решение: коммит или отмена. Условием для коммита является готовность к коммиту всех RM. В противном случае транзакцию следует отменить.
Читать полностью »

в 15:29, , рубрики: github, mysql, Orchestrator, бд, внесение неисправностией, высокая производительность, репликация, Серверное администрирование, согласованность, Тестирование IT-систем, хаос-инжиниринг, хранение данных

Роковые 43 секунды, которые вызвали суточную деградацию сервиса

На прошлой неделе в GitHub произошёл инцидент, который привёл к деградации сервиса на 24 часа и 11 минут. Инцидент затронул не всю платформу, а только несколько внутренних систем, что привело к отображению устаревшей и непоследовательной информации. В конечном счете данные пользователей не были потеряны, но ручная сверка нескольких секунд записи в БД выполняется до сих пор. На протяжении почти всего сбоя GitHub также не мог обрабатывать вебхуки, создавать и публиковать сайты GitHub Pages.

Все мы в GitHub хотели бы искренне извиниться за проблемы, которые возникли у всех вас. Мы знаем о вашем доверии GitHub и гордимся созданием устойчивых систем, которые поддерживают высокую доступность нашей платформы. С этим инцидентом мы вас подвели и глубоко сожалеем. Хотя мы не можем отменить проблемы из-за деградации платформы GitHub в течение длительного времени, но можем объяснить причины произошедшего, рассказать об усвоенных уроках и о мерах, которые позволят компании лучше защититься от подобных сбоев в будущем.
Читать полностью »

в 9:01, , рубрики: большие коллективы, закон Амдала, менеджмент, Микроформаты, раздутый штат, распараллеливание работы, согласованность, управление персоналом, управление проектами, управление разработкой

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

Закон Амдала

В 1967 году Джин Амдал представил довод против параллельных вычислений. Он утверждал, что рост производительности ограничен, поскольку только часть задачи поддаётся распараллеливанию. Размер остальной «последовательной части» отличается в разных задачах, но она есть всегда. Этот довод стал известен как закон Амдала.

Если построить график «ускорения» выполнения задачи в зависимости от количества выделенных ей параллельных процессоров, вы увидите следующее:

Издержки согласования в коллективах - 1
Это асимптотический график для фрагмента, который не поддаётся распараллеливанию («последовательная часть»), поэтому существует верхний предел максимального ускорения
Читать полностью »

в 7:08, , рубрики: paxos, Блог компании Cloud4Y, консенсус, облако, Облачные вычисления, распределенные системы, Сетевые технологии, системное администрирование, согласованность, хранение данных

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

Если у вас есть часть данных, которую многие люди хотят прочесть и сразу отредактировать, например, общий текстовый файл, банковский счёт или мир в многопользовательской игре, как достичь общего согласия с тем, что находится в документе, и убедиться, что никто не перезаписывает чужую работу? Это проблема консенсуса в распределённых системах, и для того, чтобы разобраться с этим, мне придётся рассказать об овцах, диктаторах и вымышленных островах древней Греции.

Как принять закон или обработка данных в распределённых системах понятным языком - 1

«Каких ещё островах?», — спросите вы?Читать полностью »

в 8:09, , рубрики: acid, nosql, sql, базы данных, доступность, разработка, согласованность, устойчивость к разделению сети

В любом обнаружении NoSQL баз данных кто-нибудь обязательно вспомнит о CAP-«теореме». Я не случайно пишу слово «теорема» в кавычках. CAP-«теорема» вовсе не теорема в математическом понимании этого слова. Это неформальное утверждение, сделанное Эриком Брюером в докладе на конференции Principles of Distributed Computing (PODC) в 2000 году. Эрик утверждал, что невозможно создать распределенное (состоящие из нескольких равноценных экземпляров — звеньев) веб-приложение, которое будет одновременно обладать тремя свойствами: согласованность (consistency), доступность(availability) и устойчивость к разделению(partition tolerance), сокращенно CAP. Неформальность утверждения заключается в том, что Брюер не дал определения этим трем понятиям.

Спустя два года Сет Гилберт и Ненси Линч опубликовали исследование, где дали определения понятиям CAP а также формализовали "отложенную согласованность" (Delayed Consistency), которую потом прозвали "согласованность в конечном счете" (Eventual Consistency) и доказали CAP-«теорему» в терминах указанных определений. Если вы еще не читали исследование, то это обязательно стоит сделать — lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

Эта «теорема» так бы и не была никому нужна, если бы её не взяли на вооружение маркетологи NoSQL.
Читать полностью »

Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js