Автоматическое разрешение конфликтов в среде с более, чем одним ведущим узлом (в данной статье под ведущим узлом понимается узел, который принимает запросы на изменение данных) – очень интересная область исследований. Существует несколько различных подходов и алгоритмов, в зависимости от области применения, и в данной статье будет рассмотрена технология Операциональных Преобразований (Operational Transformations, OT) для разрешения конфликтов в приложениях совместного редактирования, таких как Google Docs и Etherpad.

В мае вышла новая версия Apache Ignite — 2.5. В неё внесено множество изменений, с полным списком которых можно ознакомиться в Release Notes. А в этой статье мы рассмотрим ключевые новшества, на которые стоит обратить внимание.

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

Ignite применяют в тех случаях, когда нужна горизонтальная масштабируемость и очень высокая скорость обработки данных. Последнее достигается также за счет оптимизации платформы под хранение данных непосредственно в RAM в качестве первичного хранилища, а не кеша (In-Memory Computing). Отличительными особенностями продукта являются полноценный движок запросов ANSI SQL 1999, дисковое хранилище, расширяющее RAM, большое количество встроенных интеграционных инструментов и Zero-ETL машинное обучение.

Среди компаний, которые используют Apache Ignite такие фирмы, как Veon/Beeline, Сбербанк, Huawei, Barclays, Citi, Microsoft и многие другие.

Новый вариант топологии: звезда вокруг ZooKeeper

Одно из главных изменений в версии 2.5 — новый вариант топологии. Ранее в Ignite была лишь топология «кольцо», которая использовалась для обмена событиями внутри кластера и обеспечивала эффективную и быструю масштабируемость, на масштабе до 300 узлов.

Новая топология предназначена для инсталляций из многих сотен и тысяч узлов.

Один из главных трендов развития информационных технологий в последние 20 лет – перенос сложных вычислений с локального компьютера на удаленные серверы, которые соединены с ним через компьютерные сети. Начиналось всё с концепции «сетевого компьютера», которая затем переросла в облачные вычисления.

И вот после этой логичной технологической эволюции мы снова слышим разговоры о том, что часть вычислений лучше всё-таки переносить на локальные устройства. Речь идёт о так называемых периферийных вычислениях, или Edge Computing. Что это — дальнейшее развитие технологий или разворот назад?

Привет, Хабр!

Вместе с нашими друзьями из IBM приглашаем на митап, где подробно расскажем про HyperLedger Fabric. Ждём всех: разработчиков, архитекторов, инженеров и просто тех, кто хочет разобраться, как работает Fabric.

Увы, но ответ неоднозначный – и да, и нет. Выбрать-то, конечно, легко, но запутаться еще проще. Так вот, о том, как не запутаться, и пойдет речь.

ДГУ у вас или другое оборудование — универсального решения по дистанционному мониторингу и управлению, которое подходит всем, умеет все и стоит дешево, не существует. Ограничения есть всегда. Один вариант предлагает скудный набор функций, но за копейки, другой наоборот – требует высокой цены, но за большие возможности. А между ними будут бесчисленные вариации, сочетающие в себе функциональность и цену в разных пропорциях. И кажется, что можно легко потеряться в этом море решений. Хотя…



Но на самом деле все проще, ведь вариантов решений всего 3, и в них можно разобраться.

Привет Хабр! Предлагаю вашему вниманию перевод статьи «Do you need a Blockchain»

Часть 1 (Управление цепочками поставок)

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

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

Мы различаем публичные (permissionless) Bitcoin \ Ethereum, и частные (permissioned) Hyperledger \ Corda блокчейны и противопоставляем их свойства свойствам централизованно управляемых баз данных. мы покажем структурированную методику для определения оптимальных технических подходов при решении конкретных прикладных задач. мы проанализируем три случая — Управление цепями поставок (Supply Chain Management), межбанковские и международные платежи (Interbank and International Payments), и Децентрализованные автономные организации (Decentralized Autonomous Organizations).

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

В офисе компании Pusher у нас висит небольшой счетчик с постоянно увеличивающейся цифрой. Он показывает количество доставленных сообщений за всё время существования Pusher Channels. В пятницу в 22:20 по UTC число увеличилось на один разряд и достигло 10.000.000.000.000. В нём 13 нулей — 10 трлн.

Вы можете подумать, что счётчик общего количества сообщений — бесполезная кичливая метрика. Но это число — ключевой индикатор успеха Pusher Channels, нашего продукта для коммуникации в режиме реального времени. Во-первых, данный счётчик отражает доверие, оказанное нам пользователями. Во-вторых, он измеряет масштабируемость нашей системы. Чтобы цифра увеличивалась, мы в Pusher должны сделать так, чтобы пользователи доверяли отправку сообщений нашему сервису, и мы должны быть уверены в том, что наша система способна обработать эти сообщения. Но что нам стоит доставить 10 трлн сообщений? Давайте посмотрим.

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

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

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

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

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

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

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

{ объем изображений: 924 KiB; текста: 69 KiB; смайликов: 9 шт. }

Аннотация

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

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

Введение

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

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

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

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

Привет Хабр!

Меня зовут Алексей Солодкий, я PHP-разработчик в компании Badoo. И сегодня я поделюсь текстовой версией моего доклада для первого Badoo PHP Meetup. Видео этого и других докладов с митапа можно найти здесь.

Любая система, состоящая хотя бы из двух компонентов (а если у вас есть и PHP, и база данных, то это уже два компонента), сталкивается с целыми классами рисков во взаимодействии между этими компонентами.

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

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

Рассмотрим, что делать, когда сервис падает или тупит, как организовать сбор метрик и что делать, когда всё вышесказанное вас не спасёт.

У всех существующих мессенджеров есть свои плюсы и минусы, но каждый из них тянет одеяло на свою сторону из-за несовместимости с другими – и от этого страдают пользователи.

Единым стандартом мог бы стать XMPP, но он, в отличии от E-Mail, появился относительно поздно и не успел набрать достаточную аудиторию, чтобы корпорации не могли уже от него отказаться. Ведь там быстро поняли, что без удержания аудитории внутри собственной экосистемы много не заработать. Да и кроме того, надо признать, у XMPP было достаточно недостатков из-за обилия расширений, многие из которых, несмотря на свою важность, оставались в экспериментальном статусе, а какие-то и вовсе дублировали друг друга.

Пожив в «новом дивном мире» десятка мессенджеров в смартфоне, и ощутив все недостатки такого положения дел, мы наконец готовы к чему-то новому.

И да, нам нужен новый стандарт!

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

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

Однажды перед нами встала задача автоматизировать различные workflow в крупной компании. Для нас это значило соединить воедино на момент старта порядка 10 систем. Причем связать всё надо было асинхронно, масштабируемо, надежно.

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

Для решения этой задачи мы решили использовать архитектуру обмена сообщениями через шину данных, и нам отлично подошел MassTransit с его Saga в связке с RabbitMQ.

Привет, Хабр! Представляю вашему вниманию перевод статьи "A Deeper Look at Different Smart Contract Platforms".

Мы живем в эпоху смарт-контрактов. В то время как Биткоин показал нам, что платежная система может существовать в децентрализованной одноранговой сети, именно Эфириум открыл ящик Пандоры второго поколения блокчейн, и люди наконец увидели истинный потенциал распределенных приложений (Dapps) и смарт-контрактов.

В этой статье мы рассмотрим одну из новых платформам смарт-контрактов Cardano и посмотрим, в чем ее отличие.

Прежде чем мы это сделаем, давайте зададим себе вопрос.

Что такое смарт-контракты?

Смарт-контракты автоматизированные контракты. Они самоисполняются с конкретными инструкциями, написанными на языке программирования, которые выполняются при выполнении определенных условий.

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

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

Вебинар будет интересен тем, кто планирует использовать Apache Ignite в реальном проекте и хочет оценить аппаратную конфигурацию или объём памяти для хранения в Ignite заданного объёма исходных данных.

Ждем вас онлайн 29 мая в 19:00 (время московское).
Регистрация обязательна.

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



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

Предисловие

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

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

Сегодня многие компании, начиная новый проект или улучшая существующие системы, задаются вопросом, какой вариант разработки более оправдан — воспользоваться «классическим» трехслойным подходом или же спроектировать систему как набор слабосвязанных компонентов?

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

В этой статье я расскажу, как и почему мы в 2ГИС выбрали второй вариант для построения новой системы, как решали возникающие задачи и какие выгоды от этого получили. Под катом — про Amazon S3, Apache Kafka, Reactive Extensions (Rx), eventual consistency и GitHub, сжатые сроки и невозможность собрать команду необходимого размера из инженеров, использующих один стек технологий.

В данной статье мы разберем алгоритм консенсуса Паксос, обсудим зачем он нужен, почему работает, докажем его корректность и немного поговорим о проблемах практического применения. Во многом это вольный пересказ статьи Лесли Лампорта «Paxos Made Simple»

Зачем нужен распределенный консенсус и что это такое

Привет, Хабр!

В скором времени у нас выходит изысканная новинка для разработчиков высшего класса — "Реактивные шаблоны проектирования".

Автор книги Роланд Кун — звезда первой величины в области распределенных систем, один из разработчиков Akka. Под катом предлагаем перевод его программной статьи о распределенных системах и акторной модели, размещенной на сайте GitHub