Здравствуйте, меня зовут Дмитрий Карловский и я.. стараюсь сложные вещи рассказывать простым языком, а простые вещи — эзоповым. И часто оказывается так, что в процессе упрощения и структурирования, на самом видном месте обнаруживаются скелеты древних динозавров, присыпанные мутными формулировками так, что долгие годы их никто не замечает. Что ж, если вы хотите окончательно разобраться в уровнях изоляции транзакций и гарантиях порядка операций, до давайте копать вместе.
Привет, Хабр! На связи Александр Бобряков, техлид команды МТС Аналитики. Это мой финальный пост про Apache Flink. В предыдущих частях мы рассматривали процессы сериализации данных, написали кастомный сериализатор, а также покрыли его тестами. В них проверялась поддержка эволюции схемы состояния. Для этого мы реализовали много удобных абстракций, связанных с перезагрузкой Flink MiniCluster, компиляцией тестовых java-классов, использованием их в classpath кластера и так далее.
В этом материале мы применим разработанный сериализатор JacksonStateSerializer в бою, а также автоматизируем проверку эволюции схемы для всех наших классов, участвующих в сериализации.
Весь разбираемый исходный код можно найти в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии. Данная статья соответствует релизной ветке с названием release/11_JacksonEvolvingState. По мере выхода новых материалов на Хабре ссылки на них будут появляться ниже.
Список моих постов про Flink:
Привет, Хабр! Меня зовут Глеб Типсин, я являюсь ведущим разработчиком продукта «Системы персонализации и геймификации» в SM Lab.
В этой статье мы разберём, как устроены метрики в Prometheus, как происходит их сбор, а также что с ними можно делать. Кроме того, обсудим подходы в мониторинге, архитектуру Prometheus и её ограничения.
Материал подойдёт тем, кто только знакомится с мониторингом и хочет освоить «базу», а также тем, кто уже работает с Prometheus, но хочет "освежить" свои знания и узнать что-то новое.
Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.
Изучая System Design, вы часто видите только теоретические материалы. В этой статье я постарался показать в том числе практическую реализацию многих вещей, чтобы вы не просто готовились к собеседованиям, но и знали, как эти вещи используются в реальном мире.
В мире микросервисов часто возникает необходимость сделать согласованные изменения в сервисах. Один из надёжных способов добиться этого — использовать паттерн «Сага», который помогает выполнять распределённые транзакции и при сбоях корректно откатывать изменения. Но, как всегда, есть нюансы, начиная от нереалистичных материалов на эту тему и заканчивая реальным опытом использования.
Алексей Бакин занимается разработкой внутренних продуктов. Один из них — это API-прокси, предоставляющее внешние API для внутренних сервисов. Для реализации этого решения использовали паттерн «Сага».
На один из процессов я разработала почти 150 тестов. В статье показываю и рассказываю, как тестировать в Camunda.
Статические таблицы нужны, чтобы хранить в них неизменяемые данные. Это означает, что данные, записанные в статическую таблицу, нельзя модифицировать в произвольном месте — их можно либо перезаписать полностью, либо дополнить, сделав запись в конец таблицы.
Основная боль при работе с такой таблицей возникает при росте количества хранимых в ней данных. Время чтения или записи возрастает пропорционально её объёму. Из‑за этого может настать момент, когда взаимодействовать с таблицей становится просто невозможно, и пользователям приходится придумывать ухищрения, чтобы справиться с этим.
В этой статье мы разберём механизм мёрджа чанков с помощью мастер‑серверов, который мы реализовали для статических таблиц YTsaurus — нашей платформы распределённого хранения и обработки больших данных с открытым исходным кодом.
Данная статья является попыткой моего личного обобщения и выделения различий над зоопарком современных технологий, в которых в том или ином виде используются термины: мульти-агенты ИИ (ollama, meta, camel), мульти-агенты неИИ (MAS, эмержность, интеллект роя) и актеры (Akka, асинхронность, сообщения). А также интерес применимости к домену планирования - логистики, производства. Составления расписаний. С упором на футуристичность =)
При переходе от монолитной к микросервисной архитектуре разработчики часто сталкиваются с несколькими проблемами.
Во-первых, это необходимость переработки существующего кода и его разбиения на независимые сервисы, что может быть трудоемким и сложным процессом.
Во-вторых, возникают сложности с обеспечением взаимодействия между микросервисами, включая управление сетевыми запросами и обработку ошибок. Кроме того, важно наладить мониторинг и логирование каждого микросервиса для своевременного выявления и устранения проблем в распределенной системе.
Использование в практике таких паттернов как Strangler Fig Pattern, Parallel Run Pattern, Decorating Collaborator Pattern и Change Data Capture позволяет разработчикам значительно снизить риски и проблемы, возникающие при таком сложном переходе.
Давайте рассмотрим основные концепции этих паттернов.
Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.
Изучая System Design, вы часто видите только теоретические материалы. В этой статье я постарался показать в том числе практическую реализацию многих вещей, чтобы вы не просто готовились к собеседованиям, но и знали, как эти вещи используются в реальном мире.
Хэширование — простой и надёжный способ проверить целостность данных. Но как быть, если нужно удостовериться, что часть данных принадлежит определённому набору? Например, проверить отдельную транзакцию в блоке Bitcoin или чанк файла в BitTorrent? Для этого используется уникальная структура данных — Merkle-tree. В этой статье вы узнаете, как с её помощью решать задачи проверки данных без доступа к их полному объёму.
Привет, Хабр! На связи Александр Бобряков, техлид команды МТС Аналитика. Это мой одиннадцатый пост про Apache Flink. В предыдущей части мы рассмотрели сериализацию данных во Flink, написали сериализатор, поддерживающий эволюцию схемы для Flink-состояния в операторе на основе Jackson.
В этой части мы научимся писать тесты на эволюцию схемы состояния при использовании своего сериализатора.
Весь разбираемый исходный код можно найти в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии. Этот материал соответствует релизной ветке с названием release/10_test_JacksonStateSerializer.
Продолжаем серию статей о CAP-теореме и языке Coq. В предыдущей части мы детально проанализировали определения CAP-теоремы, готовясь к её формализации на языке Coq, и нашли там серьёзную ошибку (теперь будет о чём поговорить при случае на system design interview).
В этой статье мы познакомимся с основами языка Coq и для практики формализуем небольшой фрагмент геометрической системы, близкой к евклидовой.
No subject appears to be more controversial to distributed systems engineers than the oft-quoted, oft-misunderstood CAP theorem. The CAP FAQ
— Сейчас я тебе объясню... — Объяснить я и сам могу, ты расскажи, что на самом деле происходит! (Из разговора политологов, но для CAP-теоремы подходит тоже)
— Давайте уже запишем CAP-теорему на языке Coq и посмотрим, что там на самом деле. (Я)
Привет, Хабр! Меня зовут Максим, я Go-разработчик из Wildberries. Свою дебютную статью я хочу посвятить довольно популярной теме, когда на проекте приходится уходить с одной технологии на другую. Данная статья будет полезна разработчикам, кто активно использует асинхронный способ передачи данных в своих проектах.
Массовая трансляция видео и аудио генерирует огромное количество трафика. А трафик это деньги. Иногда – большие деньги. И тогда бизнес начинает задумываться – как бы сделать так, чтобы эти деньги не платить. А желания бизнеса – плодотворная почва для интересных решений. Об одном из них мы и поговорим.
Всем привет, меня зовут Вадим Макеров, я работаю в iSpring бэкенд-разработчиком.
Однажды у нас в продукте был инцидент, который привел к даунтайму LMS и происходил несколько раз, в течении нескольких дней. Причина оказалась нетривиальной и находилась на уровне сетевых настроек подключений между сервисами.
Часто в распределенных ИТ-ландшафтах компании используют несколько хранилищ данных под разные задачи. Это делает их важным компонентом любой системы Change Data Capture (CDC) — они помогают отслеживать изменения данных и связывать используемые хранилища. Но далеко не все CDC-инструменты способны ответить на актуальные запросы бизнеса.
Меня зовут Евгений Афанасьев. Я архитектор VK Tech в команде Tarantool. В этой статье я расскажу о том, с какими вызовами сталкиваются современные компании при работе с данными и как на них помогает отвечать Tarantool CDC.
Этой статьёй я открываю серию материалов, посвящённых проблемам современного интернета, его централизации и возможным решениям. Вводная статья раскрывает основную проблематику: как интернет, задуманный как свободное и децентрализованное пространство, превратился в контролируемую и централизованную сеть. Здесь и в следующих статьях я представлю детальный разбор разработанной мною технологии децентрализации, которая может предложить решение для преодоления этих проблем.
Приветствую, Хабр! Хотелось бы этой статьей продолжить обзор нефинансовых применений блокчейн-технологий, начатый мной ранее на примере использования блокчейна для хранения идентификационных данных. Рассмотрим здесь существующие подходы по применению блокчейна в системах Интернета вещей различного назначения.
Казалось бы, между ресурсоемким по своей природе блокчейном и Интернетом вещей, построенном на использовании устройств с ограниченными ресурсами, лежит огромная пропасть. Однако многие из свойств блокчейна оказались настолько востребованными в Интернете вещей, что появилось целое направление блокчейн-технологий – низкоресурсный блокчейн (Lightweight Blockchain, LWB), в рамках которого было предложено множество подходов к созданию блокчейнов с пониженными требованиями к ресурсам и, следовательно, к их адаптации для реализации в системах Интернета вещей и, в частности, в устройствах с низкими вычислительными ресурсами.
Опишем далее, какие же свойства блокчейна оказались полезными для Интернета вещей, по каким направлениям идет создание низкоресурсных блокчейнов и как они впоследствии применяются.
