Рубрика «распределенные системы» - 16

NewSQL=NoSQL+ACID - 1

До недавнего времени в Одноклассниках около 50 ТБ данных, обрабатываемых в реальном времени, хранилось в SQL Server. Для такого объема обеспечить быстрый и надежный, да еще и устойчивый к отказу ЦОД доступ, используя SQL СУБД, практически невозможно. Обычно в таких случаях используют одно из NoSQL-хранилищ, но не всё можно перенести в NoSQL: некоторые сущности требуют гарантий ACID-транзакций.

Это подвело нас к использованию NewSQL-хранилища, то есть СУБД, предоставляющей отказоустойчивость, масштабируемость и быстродействие NoSQL-систем, но при этом сохраняющей привычные для классических систем ACID-гарантии. Работающих промышленных систем этого нового класса немного, поэтому мы реализовали такую систему сами и запустили ее в промышленную эксплуатацию.

Как это работает и что получилось — читай под катом.
Читать полностью »

Как сделать платежную систему своими руками - 1

Привет! Мы в RBKmoney новый платежный процессинг написали. С нуля. Ну не мечта ли?

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

Мы расскажем, как написали весь процессинг RBKmoney Payments, так мы его назвали. Как делали его устойчивым к нагрузкам и сбоям оборудования, как придумали возможность его практически линейного горизонтального масштабирования.

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

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

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

КДПВ: LLTR Часть 0 - пневмотранспорт из Футурамы

Как построить топологию сети на канальном уровне, если в нужной подсети используются только неуправляемые свитчи? В статье я постараюсь ответить на этот вопрос.

Начну с причины возникновения LLTR (Link Layer Topology Reveal).

У меня был один “велосипед” - синхронизатор больших файлов “на полной скорости сети”, способный за 3 часа целиком залить 120 GiB файл по Fast Ethernet (100 Мбит/с; 100BASE‑TX; дуплекс) на 1, 10, 30, или 200 ПК. Это был очень полезный “велосипед”, т.к. скорость синхронизации файла почти не зависела от количества ПК, на которые нужно залить файл. Все бы хорошо, но он требует знания топологии сети для своей работы.

Подробнее в статье про него:

Ладно, а зачем понадобилось “гонять” 120 GiB файл по сети на такое количество ПК?


Этим файлом был VHD с операционной системой, программами, и т.п. Файл создавался на мастер‑системе, а затем распространялся на все остальные ПК. VHD был не только способом доставки системы на конечные ПК, но и давал возможность восстановления исходного состояния системы при перезагрузке ПК. Подробнее в статье: “Заморозка системы: история перехода с EWF на dVHD”.


Можно продолжить цепочку дальше, но на этом я прервусь.

Существующие протоколы обнаружения топологии канального уровня (LLDP, LLTD, CDP, …) для своей работы требуют соответствующей поддержки их со стороны всех промежуточных узлов сети. То есть они требуют как минимум управляемых свитчей, которые бы поддерживали соответствующий протокол. На Хабре уже была статья, как используя эти протоколы, “определить топологию сети на уровнях 2/3 модели OSI”.

Но что же делать, если промежуточные узлы – простые неуправляемые свитчи?

Если интересно как это можно сделать, то добро пожаловать под кат. Обещаю наличие множества иллюстраций и примеров.

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

Конкурентная сосиска

Аннотация

Обработка данных в реальном времени ровно один раз (exactly-once) — задача крайне нетривиальная и требующая серьезного и вдумчивого подхода на всей цепочке вычислений. Некоторые даже считают, что такая задача невыполнима. В реальности хочется иметь подход, обеспечивающий отказоустойчивую обработку вообще без каких-либо задержек и использование различных хранилищ данных, что выдвигает новые еще более жесткие требования, предъявляемые к системе: concurrent exactly-once и гетерогенность персистентного слоя. На сегодняшний день такое требование не поддерживает ни одна из существующих систем.

Предложенный подход последовательно раскроет секретные ингредиенты и необходимые понятия, позволяющие относительно просто реализовать гетерогенную обработку concurrent exactly-once буквально из двух компонент.

Введение

Разработчик распределенных систем проходит несколько стадий:

Стадия 1: Алгоритмы. Здесь происходит изучение основных алгоритмов, структур данных, подходов к программированию типа ООП и т.д. Код исключительно однопоточный. Начальная фаза вхождения в профессию. Тем не менее, достаточно непростая и может длиться годами.

Стадия 2: Многопоточность. Далее возникают вопросы извлечения максимальной эффективности из железа, возникает многопоточность, асинхронность, гонки, дебагинг, strace, бессонные ночи… Многие застревают на этом этапе и даже начинают с какого-то момента ловить ничем не объяснимый кайф. Но лишь единицы доходят до понимания архитектуры виртуальной памяти и моделей памяти, lock-free/wait-free алгоритмах, различных асинхронных моделях. И почти никто и никогда — верификации многопоточного кода.

Стадия 3: Распределенность. Тут такой треш творится, что ни в сказке сказать, ни пером описать.

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

Достаточно незаметно для популярных новостях прошло подписание одного весьма любопытного соглашения.

Шведский стартап Northvolt и немецкая корпорация Siemens в пятницу 25 мая подписали партнёрское соглашение. По нему мюнхенский концерн становится одним из инвесторов и поставщиком решений по автоматизации, управлению производственными процессами и cloud-окружения для шведского предприятия.
Читать полностью »

В предыдущем посте мы рассматривали принципиальные подходы к оценке ёмкости кластера и совсем немного поговорили про оптимизацию. Для любителей заглянуть «под капот» Алексей Гончарук 29 мая проведет вебинар с живыми примерами:

  • Откуда берется overhead при записи данных;
  • Приемы оптимизации;
  • Как планировать ёмкость кластера Apache Ignite;
  • Улучшения, которые ждут вас в ближайших релизах.

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

Публикуем расшифровку видеозаписи выступления Алексея Гончарука (Apache Ignite PMC Member и Главный архитектор Grid Gain) на митапе Apache Ignite сообщества в Петербурге 29 марта. Загрузить слайды можно по ссылке.

Участников сообщества Apache Ignite часто спрашивают: «Сколько нужно узлов и памяти для того, чтобы загрузить такой-то объем данных?» Об этом и я хочу сегодня поговорить. Забегая вперёд: такое прогнозирование пока что является достаточно сложной, нетривиальной задачей. Для этого нужно немного разбираться в устройстве Apache Ignite. Также я расскажу, как упросить себе задачу прогнозирования, и какие можно применять оптимизации.
Читать полностью »

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

Вы можете удивиться: зачем же разработчику ПО думать о механизме кэширования в CPU? Отвечу. С одной стороны, многие понятия из концепции когерентности кэша непосредственно применимы в распределённых системах и на уровнях изоляции СУБД. Например, представление реализации когерентности в аппаратных кэшах помогает лучше понять разницу в моделях согласованности (консистентности) — отличие строгой согласованности (strong consistency) от согласованности в конечном счёте (eventual consistency). У вас могут появиться новые идеи, как лучше обеспечить согласованность в распределённых системах, используя исследования и принципы из аппаратного обеспечения.

С другой стороны, неправильные представления о кэшах часто приводят к ложным утверждениям, особенно когда речь идёт о параллелизме и состоянии гонки. Например, часто говорят о трудности параллельного программирования, потому что «у разных ядер в кэшах могут быть разные/устаревшие значения». Или что квалификатор volatile в языках вроде Java нужен, чтобы «предотвратить локальное кэширование общих данных» и принудительно «читать/записывать только в основную память».
Читать полностью »

Я присоединился к Uber два года назад в качестве мобильного разработчика, имеющего некоторый опыт разработки бекенда. Здесь я занимался разработкой функционала платежей в приложении — и по ходу дела переписал само приложение. После чего я перешёл в менеджмент разработчиков и возглавил саму команду. Благодаря этому я смог гораздо ближе познакомиться с бэкендом, поскольку моя команда несёт ответственность за многие системы нашего бэкенда, позволяющие осуществлять платежи.

До моей работы в Uber у меня не было опыта работы с распределёнными системами. Я получил традиционное образование в Computer Science, после чего с десяток лет занимался full-stack разработкой. Поэтому, пусть я и мог рисовать различные диаграммы и рассуждать о компромиссах (tradeoffs) в системах, к тому моменту я недостаточно хорошо понимал и воспринимал концепции распределённости — такие, например, как согласованность (consistency), доступность (availability) или идемпотентность (idempotency).

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

Полный ли это список? Скорее всего, нет. Однако, если бы лично я сам узнал про эти концепции раньше, это сделало бы мою жизнь гораздо проще.

Итак, давайте приступим к нашему погружению в SLA, согласованность, долговечность данных, сохранность сообщений, идемпотентность и некоторые другие вещи, которые мне потребовалось выучить на своей новой работе.
Читать полностью »

Предисловие

Недавно прочитал очередную статью из серии: "мы лучше двухфазного коммита". Здесь я не буду анализировать содержания этой статьи (хотя, подумываю о том, чтобы дать развернутый анализ). Задача моего опуса — предложить самый эффективный вариант распределенного коммита с точки зрения временных задержек. Конечно, такой коммит дается высокой ценой. Однако цель — дать оценку и показать, что двухфазный коммит не является тормозным, как многие считают.

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

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js