Мартин недавно объявил версии 2.0 из дезинтегратора — в основном там было так много изменений , так как мы первый с открытым исходным кодом его , что пришло время отметить , что официально. В его посте рассматриваются все изменения, цель этой статьи — попытаться перевести мои предыдущие посты в блоге на новый мир, поскольку потребуется много времени, чтобы переписать каждый из них снова и снова. Теперь я вижу недостаток в рисовании всего.
В старом мире
Это пример конфигурации Разрушителя (в частности, алмазная конфигурация). Если ничего из этого для вас ничего не значит, не стесняйтесь возвращаться и обновлять себя по всем (уже устаревшим)
деталям Disruptor .
Наиболее очевидные изменения за последние несколько недель:
- Обновленное соглашение об именах
- Интеграция барьера производителя в кольцевой буфер
- Добавление мастера Disruptor в основную базу кода.
Вы увидите, что основы в основном одинаковы. Это проще, потому что ProducerBarrier больше не является самостоятельной сущностью — его заменой является интерфейс PublishPort, который реализуется самим RingBuffer.
Точно так же имя DependencyBarrier вместо ConsumerBarrier поясняет работу этого объекта; Publisher (вместо Producer) и EventProcessor вместо Consumer также более точно представляют, что эти вещи делают. Имя Consumer всегда было немного запутанным, поскольку потребители никогда ничего не потребляли из кольцевого буфера. Мы надеялись, что это просто термин, который будет иметь смысл для тех, кто привык ставить реализации в очередь.
На диаграмме не показано изменение имени элементов в RingBuffer — в старом мире мы называли эту запись, теперь они являются событием, следовательно, EventProcessor на другом конце.
Цель этого оптового переименования не состояла в том, чтобы полностью дискредитировать все мои старые блоги, чтобы я мог продолжать вести блог о Disruptor
до бесконечности . Это далеко от того, чего я хочу — у меня есть другие, более пушистые вещи, о которых можно писать. Цель переименования — облегчить понимание того, как работает Disruptor и как его использовать. Хотя
мы используем Disruptor для обработки событий, когда мы открываем исходный код, мы хотели, чтобы он выглядел как решение общего назначения, поэтому соглашение об именах пыталось это представить. Но на самом деле модель обработки событий кажется более интуитивной.
Больше нет утомительной проводки
Теперь
мастер Disruptor является частью самого Disruptor , весь мой
пост о проводкедовольно бессмысленно — что на самом деле хорошо, потому что это было немного вовлечено.
В наши дни, если вы хотите создать ромбовидную модель (например,
тест производительности FizzBuzz ), это намного проще:
DisruptorWizard dw = new DisruptorWizard<FizzBuzzEvent>( ENTRY_FACTORY, RING_BUFFER_SIZE, EXECUTOR, ClaimStrategy.Option.SINGLE_THREADED, WaitStrategy.Option.YIELDING); FizzBuzzEventHandler fizzHandler = new FizzBuzzEventHandler(FIZZ); FizzBuzzEventHandler buzzHandler = new FizzBuzzEventHandler(BUZZ); FizzBuzzEventHandler fizzBuzzHandler = new FizzBuzzEventHandler(FIZZ_BUZZ); dw.handleEventsWith(fizzHandler, buzzHandler) .then(fizzBuzzHandler); RingBuffer ringBuffer = dw.start();
Обратите внимание, что в мастере Disruptor есть
вики-страница .
Другие изменения: улучшения производительности
Как Мартин упоминает в
своем посте , ему удалось значительно улучшить производительность (даже больше!) Disruptor в 2.0.
Короче говоря, это новый класс Sequence, который одновременно заботится о
заполнении строк кэша и устраняет необходимость в
барьерах памяти . Заполнение строк кэша теперь выполняется немного по-другому, потому что, если не считать маленьких хлопковых носков Java 7, ему удалось «оптимизировать» нашу старую технику.
Я оставлю вас, чтобы прочитать подробности в этом посте, в этом посте я просто хотел дать краткое изложение изменений и объяснить, почему мои старые диаграммы могут больше не соответствовать действительности.
С http://mechanitis.blogspot.com/2011/08/disruptor-20-all-change-please.html