Использование нескольких LMAX Disruptor

Question

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

Запрос отправляется на платформу для отправки СМС, запрос очищается/проверяется на наличие простых ошибок и регистрируется.

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

Правильный маршрут маршрутизации проанализирован и выбран. Затем из SMS-информации настраиваются и передаются маршрутизатору определенные для платформы параметры протокола.

Нравится программа? Поделись с друзьями! В каждой фазе будет параллельное или последовательное выполнение в потоке программы. Если это представление высокого уровня проекта, должна использоваться инфраструктура разломов LMAX для связи (sms-info) между различными модулями?

Если это так, то нужно создать грохот разломов?

Если мое понимание правильное, новые кольцевые буферы созданы между разными слоями/функциональными возможностями?

Можно ли записать объект POJO в ringbuffer? Как это можно применить к кластерной среде? Хотя я прочитал некоторые документы и увидел некоторые видеоролики в этой структуре, я не могу визуализировать решение, используя эту инфраструктуру.

Любые рекомендации/примеры/визуальные диаграммы/документы или ваша идея по этому поводу мне очень помогут.

Answer 1

Мы немного поработали с разрывом и используем его как библиотеку для обеспечения высокопроизводительных, настраиваемых параллельных потоков выполнения.

В данном сценарии я вижу две конфигурации буферных буферов. Один для отправки SMS и другой для получения SMS.

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

ССМ отправки конфигурации буфера кольцо может иметь событие потока стадии как Аналогично принимающая часть также может иметь конфигурацию ступени.

Что касается вашего вопроса на POJO. Кольцевой буфер имеет концепцию Event bucket, где POJO могут быть помещены как полезная нагрузка для обработки, а транслятор Event может использоваться для заполнения ведра Event.