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

в 14:15, , рубрики: .net, .net core, C#, orm, postgres, RabbitMQ, микросервисы, микросервисы и базы данных, нагрузка, согласованность

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

Первые два голосовых проекта в разных компаниях мы реализовывали на связках .Net + Asterisk с преобразованием TCP/GRPC трафика. Более интересен именно второй проект в этой области, где в полной мере использовалась микросервисная архитектура (тогда как на первом, в рамках стартапа, несмотря на задел под микросервисы с тз организации кода, у нас сильно проседал деплой). 

Читать полностью »

в 11:01, , рубрики: AI, alignment, alignment ai, chatgpt, Fine-tuning, llm, machinelearning, ml, RLHF, согласованность

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

Практика alignment: данные, RLHF и UX как конкурентное преимущество - 1

Читать полностью »

в 14:15, , рубрики: outbox, transactional outbox, атомарность, идемпотентность, Программирование, согласованность, транзакции

Какую потенциальную проблему видите в коде?

await _applicationService.Create(application);
await _queue.Publish(new ApplicationCreatedEvent(application));

Сначала создается заявка в БД, после событие о создании отправляется в брокер сообщений(MQ) для оповещения другого сервиса о появлении новой заявки.

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

Читать полностью »

в 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