Как мы накормили драконов (и заработали кучу золота)

Как мы накормили драконов (и заработали кучу золота) Старейшины говорят, что это история о масштабировании SaaS-приложения, но я таких слов не понимаю — слишком заумно. Для меня это история о золоте, драконах с всё возрастающим аппетитом и фермерах, которые кормят этих драконов. Начиналось всё просто: несколько драконов регулярно прилетали к нашему городу, мы готовили им еду из продуктов с нашей фермы, они платили золотом. Все были довольны. Но драконы росли, их аппетиты увеличивались, появлялись новые голодные гости... Что делать, когда одна ферма больше не может прокормить всех? Как не дать городу сгореть от драконьего гнева? Зачем строить заморские колонии и создавать параллельные измерения? За 10 лет наше королевство прошло путь от маленького города с одной фермой до федерации независимых государств, специализированных поселений и городов в параллельных мирах. И да, драконы всё ещё голодны. Это сказка о том, как накормить растущих драконов и не потерять при этом ни золота, ни головы. С картинками, моралью и счастливым концом. Узнать, как накормить драконов

https://habr.com/ru/articles/918696/

#масштабирование #распределенные_системы #монолит #saas

Как мы заменили сотни Join’ов на один РТ-процессинг с 1kk RPS

Как связаны скидки, пользовательские пути и огромные массивы данных в Яндекс Рекламе? Привет, Хабр! Меня зовут Максим Стаценко, я работаю с базами данных и яростно в них копаюсь с 2010 года, а в Big Data — с 2016. Сейчас работаю в Яндексе в DWH поиска и рекламы. Мы работаем с ОЧЕНЬ большими данными. Каждый день миллионы пользователей видят рекламу Яндекса, а наши системы обрабатывают огромные объёмы данных. Чтобы реклама работала эффективно, нам нужно в каждый момент времени иметь максимально полную информацию об истории жизни рекламного объявления, а значит нужно каким-то образом передавать данные от одного события к другому внутри рекламной воронки. Расскажу, как мы решали эту проблему.

https://habr.com/ru/companies/oleg-bunin/articles/884560/

#ytsaurus #mapreduce #olap #oltp #антифрод #распределенные_системы #оптимизация #обработка_данных #хранилища_данных

Как консолидировать данные из разрозненных хранилищ с помощью Tarantool CDC

Компании часто сталкиваются с необходимостью переливать данные между системами. Но нередко это превращается в настоящий квест: форматы данных могут различаться, для интеграции инструментов может не быть готовых коннекторов, самостоятельно гарантировать консистентность данных в целевой системе может быть сложно или невозможно. Поэтому подобные задачи редко обходятся без применения CDC (Change Data Capture). Меня зовут Андрей Капустин. Я менеджер продукта Tarantool CDC в компании VK Tech. В этой статье я расскажу о Tarantool CDC и о том, как инструмент помогает консолидировать данные из разрозненных хранилищ, в том числе проприетарных СУБД, обеспечивая прозрачность, высокую консистентность и скорость. Как разрабатывался Tarantool CDC

https://habr.com/ru/companies/vktech/articles/913352/

#Tarantool #архитектура #отказоустойчивость #postgresql #высокопроизводительные_вычисления #распределенные_системы #субд #Tarantool_Queue_Enterprise #Tarantool_CDC #change_data_capture

Распределённые транзакции в микросервисах: от SAGA до Two‑Phase Commit

Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем – согласованность данных и транзакции . В монолите обычно можно обернуть несколько операций одной ACID-транзакцией: либо все операции выполняются успешно, либо при ошибке происходит полный откат. В мире микросервисов такой прямолинейный подход не работает. Каждый сервис автономен, у каждого своя база данных, и общаются они через сеть. Как результат, гарантировать атомарность и целостность процессов, охватывающих несколько сервисов, непросто. Возникает риск частичных обновлений: одна часть системы изменилась, а другая – нет, что приводит к неконсистентным (несогласованным) состояниям данных. Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC) . Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel) , паттерн Outbox , а также кратко упомянем eventual consistency , транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.

https://habr.com/ru/articles/906484/

#sql #nosql #базы_данных #микросервисы #распределенные_системы #распределенные_транзакции #программирование #программное_обеспечение #rest #http

Основные паттерны микросервисной архитектуры: Strangler Fig, API Gateway, Service Mesh и другие

Микросервисная архитектура стала де-факто стандартом для построения современных масштабируемых приложений. Вместо единого монолитного приложения система разбивается на набор мелких независимых сервисов, каждый из которых отвечает за свою четко обозначенную функцию. Такой подход позволяет упрощать разработку и развертывание отдельных компонентов, повышать отказоустойчивость и масштабируемость системы. Однако переход к микросервисам и их эффективное использование сопряжены с рядом сложных задач. Для их решения в практике выработаны архитектурные паттерны – типовые подходы и шаблоны проектирования. В данной статье мы разберем несколько ключевых паттернов, связанных с микросервисами. Речь пойдет о паттернах миграции и интеграции (таких как Strangler Fig – «удушающее дерево» и API Gateway ), о сетевых и структурных паттернах ( Service Mesh , Sidecar ), о шаблонах работы с данными ( Database per Service , CQRS ) и об особом подходе к хранению состояния ( Event Sourcing ). Для каждого паттерна мы рассмотрим его суть, назначение, примеры использования, а также плюсы и возможные сложности. К некоторым паттернам приведены упрощенные диаграммы и фрагменты кода, чтобы иллюстративно показать, как они работают на практике.

https://habr.com/ru/articles/904954/

#java #net #python #микросервисы #распределенные_системы #паттерны_проектирования #антипаттерны #распределение_трафика #распределенные_транзакции #высокая_производительность

Алгоритмы консенсуса Paxos, Raft и Zab в распределённых системах

В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos , Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.

https://habr.com/ru/articles/903792/

#paxos #raft #микросервисы #sql #nosql #распределенные_системы #высоконагруженные_проекты #высоконагруженные_приложения #высокая_доступность #высокая_нагрузка

И снова USB-IP — сервер теперь с автобиндом и детачем и сам подхватит ключ клиент

HA - как много в этом слове: Автоматический перенос виртуальных машин в кластере. 8 секунд и, например, сервер терминалов сменил место жительства совместно со всеми своими предустановленными программами - в другую серверную. И ... оставил аппаратные лицензии и ЭЦП, заботливыми руками проброшенные в виртуалки, тоскливо торчать из, возможно, погибшего железа. Отставить "оставил"!

https://habr.com/ru/articles/901988/

#usbip #linux #alt_linux #debian #systemd #bashscripting #распределенные_системы

Настройка Apache Kafka для высоконагруженных систем

Apache Kafka является одной из самых популярных платформ для обработки потоков данных, обеспечивая высокую пропускную способность и низкие задержки при передаче сообщений. В высоконагруженных системах, где необходимо обрабатывать миллионы сообщений в секунду, важность правильной настройки Kafka трудно переоценить. Без оптимизации её параметров можно столкнуться с серьёзными проблемами, такими как рост задержек, потеря сообщений и переполнение очередей. Эффективная настройка Kafka критична для обеспечения бесперебойной работы в условиях высокой нагрузки и стабильной обработки данных в реальном времени. Цель этой статьи — рассмотреть основные аспекты настройки Apache Kafka, которые влияют на производительность системы. Мы сосредоточимся на оптимизации параметров брокеров и продюсеров для достижения максимальной пропускной способности, минимальных задержек и надежности. Также рассмотрим важность мониторинга и тестирования системы для своевременного выявления и устранения узких мест.

https://habr.com/ru/articles/901200/

#apache_kafka #nosql #распределенные_системы #высоконагруженные_проекты #высокая_производительность #highload #высокая_нагрузка #высоконагруженные_приложения #высокая_доступность

Теорема CAP: почему нельзя иметь все сразу и как аналитик выбирает чем пожертвовать

Распределенные системы лежат в основе большинства современных приложений - от облачных сервисов до финансовых платформ и социальных сетей. Проектирование сопряжено с рядом сложных компромиссов, особенно когда речь идет о согласованности данных, доступности системы и устойчивости к сетевым сбоям. Теорема CAP (дословно: Consistency (согласованность), Availability (доступность), Partition Tolerance (устойчивость к разделению)), предложенная Эриком Брюером в 2000 году, объясняет, почему невозможно одновременно обеспечить все три этих свойства. Это ограничение имеет ключевое значение для системных аналитиков и архитекторов, которым необходимо принимать решения о том, какие свойства являются приоритетными в зависимости от бизнес-потребностей и пользовательских ожиданий. Да, многие могут сказать, что это больше стезя архитектора. Но грань между аналитиком и архитектором в текущих реалиях очень смазана. Хороший системный аналитик фактически является lite версией архитектора. Поэтому щас выскажусь!)))

https://habr.com/ru/articles/900330/

#системный_анализ #распределенные_системы #проектирование_систем #анализ_и_проектирование_систем

Отказоустойчивая распределённая архитектура для UX-аналитики

UX-аналитика – это сбор и анализ данных о взаимодействии пользователей с интерфейсом (клики, скроллы, навигация и прочие события). Такие события генерируются в огромных количествах, особенно при большой аудитории приложения. Чтобы эффективно обрабатывать эту информацию, необходима распределённая архитектура, способная масштабироваться под высокий поток событий и обеспечивать отказоустойчивость – т.е. работать надёжно даже при сбоях отдельных компонентов. Также важна возможность обработки данных в реальном времени , чтобы как можно быстрее получать метрики и инсайты об опыте пользователей. В этой статье мы рассмотрим ключевые аспекты такой архитектуры: масштабирование UX-событий, надёжный сбор метрик с устройств (в том числе офлайн), реалтайм-аналитику на основе потоковых технологий (Kafka, Flink, Kafka Streams, ClickHouse) и механизмы гарантированной доставки событий (at-least-once, exactly-once, retry, дедупликация). В результате станет понятно, как правильно спроектированная система UX-аналитики позволяет оперативно находить проблемные места UI, проводить A/B тесты и глубже понимать поведение пользователей.

https://habr.com/ru/articles/897798/

#clickhouse #kafka #flink #kafka_streams #распределенные_системы #отказоустойчивые_системы #аналитика #анализ_данных #анализ_и_проектирование_систем #анализ