Комментарии 25
Что-то не улавливаю, в чём новизна?
Как понимаю, фреймворк на яве, тогда причём тут memory barriers? ведь от CAS2 до JVM целая толща кода!
И потом, вроде всё сводится к тому, что есть классическая задача разделения доступа к ресурсу, ну кольцевой буфер вы привлекли для этого, очень хорошо, и что из того?
Сначала думал что у вас там хитрая lock-free стратегия какая-то, но вроде её тоже нет.
Вы недоговариваете про то как реализуется конкурентный доступ к тем же счётчикам.
А как насчёт fault-tolerance? Ну скажем этот unmarshaller не просто вышел покурить, а укурился совсем и его увезли на скорой в больницу?
Как-то неполно и нового ничего нет…
Вы извините, но эта тема мне интересна, мне приходилось самому разрабатывать такие системы в реальности (>30tps 24/7) и мне трудно поверить что на яве можно сделать что-то работающее в этом контексте.
НЛО прилетело и опубликовало эту надпись здесь
У меня ощущение что очередную примитивную вещь прикрывают заумными рассуждениями про барьеры памяти и тп. Почему-то такое часто наблюдаю когда слышу про яву. И даже Фаулера сюда прикрепили…

"… на java подобное неоднократно делалось, java для этого очень хорошо подходит"
Поверьте мне, ява не лучший инструмент для таких задач.
Вы просто не можете полагаться на какой-то jit когда речь идёт о вещах, которые должны быть вылизаны до блеска. Там же деньги крутятся, а ява со своей непредсказуемой сборкой мусора и капризами виртуальной машины быстро могут всё испортить.

Масштабироваться до 10Ktps без наращивания числа рабочих процессов вы не сможете. Это если у вас там не совсем примитивная обработка конечно, но тогда уж и вся эта затея с кольцевыми буферами не нужна, можно попроще что-то придумать.
А раз уж число процессов становится ощутимо большим, то тут и начинается главный challenge. Мы сравнивали однажды, ява гибла однозначно.
К тому же исходные данные как-то должны попадать в систему, значит рабочий процесс должен общаться с внешним миром. Это ещё один challenge.
Это всё будет работать, но на небольших нагрузках, для торгов не потянет…

Продолжать спорить не хочу, увидел вашу аватарку и понял что это надолго (шутка (с) ) :)
НЛО прилетело и опубликовало эту надпись здесь
Возможно неясно из моего поста, но данная система не находится в стадии прототипа, а была запущена год назад(октябрь 2010), и успешно функционирует, обрабатывая тысячи транзакций в секунду.
Сами буфферы весьма немаленькие — 20М слотов для входящего буффера и по 4М слотов для исходящих. Система буффера рестартуется ночью, во избежание дорогостоющего Garbage Collection.
Мне кажется мы говорит об обычной очереди сообщений или нескольких очередей. Чем очередь сообщений принципиально отличается от буфера?

Подалуйста, посните подробнее, потому-что просто так Duke's Choice Award, и хочется понять, чтобы плодотворно использовать!
НЛО прилетело и опубликовало эту надпись здесь
поправка, ">30000tps" конечно же, только сейчас заметил…
Полность согласен!
Я меня самого такая система работает, причем очередь реализована rabbitMQ. У ява машин иногда течет память в режиме lon-run (3-4 года без остановки высоконограженного сервиса), а с помощью сторонней очереди — можно перегрузить сервис без потери данных. Конечно эта схема полностью нарушает парадигму java прложений, но ведь работает! ;-)
Сложновато у меня с техническим русским.
И частично перевод, да.

Правда, статья Фаулера и в оригинале плоховато читается.
А в чём смысл партнёрки? Где регестрироваться, на оффсайте или на ней?
Ну то есть я понимаю, что профит владельцу партнёрки (Вам? :-), просто хочу всё знать :)
Регистироваться можно только на сайте LMAX.
Смысл партнёрки — это единственный ресурс на русском о LMAX
Это циклический буфер по которому гуляют несколько обработчиков не обгоняя друг друга?
То есть реализует параллелизм типа «конвейер». Единственное отличие от конвейера — механизм поставки данных через циклический буфер. Так?
А в чем преимущество по отношению к пулу потоков? Там ведь то же самое, просишь выполнить вызов метода асинхронно, и он выполняется в произвольном рабочем потоке. Плюс там уже готовый балансировщик, и масштабируемость автоматическая.
Я сам .NET-чик, но судя по тому, что я нагуглил за пару минут, в Java пул потоков примерно совпадает по функциональности с .NETным.
И да, перевод кривоват, тавтологии много.
Я не .NETчик и не JAVAчик, поэтому точно ответить не смогу.
Но у нас проблема в том, что некоторые операции должны происходить в чётком порядки FIFO — ведь система «играет» с настоящими деньгами. А если потоки начнут произвольно там что-то выполнять, клиенты от нас очень скоро смотаются.

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

void AsyncOperation()
{
// Синхронное выполнение какого-то кода.
DoSomething();
// Асинхронное выполнение следующего этапа.
new Action(DoStageTwo).BeginInvoke((IAsyncResult ar) =>
{
// После завершения этапа 2, произвольный поток. Еще что-то делаем.
DoSomethingElse();
// Планируем следующую часть.
new Action(DoStageThree).BeginInvoke((IAsyncResult ar) =>
{
// После завершения этапа 3, произвольный поток.
// и т.д.
}
}
}

Метод возвращает управление сразу же по завершении строчки «new Action(DoStageTwo)...»! Т.е. синхронна только часть, обращающаяся к пулу потоков. Дальше, если вызвать много таких операций, то их куски будут выполняться параллельно, но последовательно в рамках одной операции.
В .NET 4.0 для сокращения кода есть синтаксический сахар — ключевые слова ASYNC и AWAIT, которые позволяют написать указанный код без явного вызова Delegate.BeginInvoke.
А парадигма, парадигма-то где?
Да, любопытная либа хорошо работающая там для чего она создавалась.
Но ИМХО на парадигму не тянет.
Этот фреймворк можно использовать не только для такой системы, а для любой другой где важна низкая латентость, высокая скорость и предсказуемое поведение.

Disruptor — это новый подход к старым проблемам.
НЛО прилетело и опубликовало эту надпись здесь
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.