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

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

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

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

Но была и проблема: типичное игровое разрешение того времени — 320 на 200 точек при палитре из 256 цветов, что даёт нам 64 килобайта на кадр или полтора мегабайта на 25 кадров, при скорости чтения с компакт диска в 150 килобайт в секунду. Т.е. видео надо было жать и жать довольно сильно, а сжав, потом надо суметь декодировать, ведь мы помним, компы были слабенькие и декодирование, например, MPEG им было вообще не по силам. Тем не менее производители видео игр успешно решили проблему недостаточной производительности породив заодно множество видео-кодеков и игровых видео-форматов, некоторые из которых могли проигрываться аж 286-м (прописью: двести восемьдесят шестым) процессором.

Так началась эпоха FMV игр (Full Motion Video Games). Я думаю, многие помнят её ярких представителей: Crime Patrol от American Laser Games, Lost Eden, Cyberia, Novastorm и даже Command & Conquer, в который многие играли только ради видеовставок между миссиями. В те времена выглядело это очень круто. Вау! Вау! Ну а мне было интересно, как же они закодировали это видео, в книжках о мультимедиа приводили то же описание проблемы, что и я выше, но ничего внятного о методах сжатия не писали, видимо, авторы в этом мало понимали и пересказывали какие-то сомнительные слухи.

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

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

При разработке энтерпрайз приложений зачастую с базами данных взаимодействуют посредством ORM технологии, в мире джавы наиболее известна технология JPA (Java Persistence API) и её реализации — Hibernate и EclipseLink. JPA позволяет взаимодействовать с базой данных в терминах объектов предметной области, предоставляет кэш, репликацию кэша при наличии кластера в middle tier-е.

Как это обычно происходит:

Как известно, ConcurrentModificationException к многопоточности никакого отношения не имеет. Возникает эта гадость, когда мы пытаемся модифицировать коллекцию во время итерирования по ней. Как обычно, это имеет исторические корни: коллекции и итераторы появились в Java 1.2, в те времена избежать явного использования итератора при обходе коллекции было никак нельзя, так что предложение менять коллекцию посредством методов итератора не выглядело совсем ужасным:

Iterator iterator = collection.iterator();

while (iterator.hasNext()) {
    Object element = iterator.next();
    if (iDontLikeThisElement(element)) {
         iterator.remove();
    }
}

Stream API — замечательная вещь быстро завоевавшая популярность у джава программистов. Лаконичные однострочники обрабатывающие коллекции данных посредством цепочек простых операций map, filter, forEach, collect оказались очень удобны. Операции над парами ключ-значение, конечно, тоже не помешали бы, но увы.

В целом примерно понятно как это всё устроено, но все же зачастую ответ на вопрос «А как бы это написал я?» здорово помогает понять внутренние механизмы той или иной технологии. Так получилось, что внезапно для себя я ответил на этот вопрос применительно к Stream API, историей изобретения этого велосипеда и спешу с вами поделиться.