Java: использовать Disruptor или нет.,

Question

Hy,

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

Теперь, когда приходит сообщение, два значения извлекаются и добавляются в объект SynchronizedDescriptiveStatistics. После каждого добавления в список значений вся последовательность вычислений выполняется заново (фактически это является частью требования).

Проблема, с которой я сталкиваюсь сейчас, заключается в том, что, поскольку я использую прослушиватели, иногда в середине вычислений принимается одно или несколько сообщений. Хотя SynchronizedDescriptiveStatistics самостоятельно решает все проблемы, связанные с потоками, но он добавляет все ожидающие значения в свой список номеров сразу, когда он выходит из-под контроля или что-то в этом роде. Хотя моя проблема заключалась в том, чтобы добавить одно значение, затем выполнить вычисления для него, затем второе значение и так далее.

Решение, которое я придумал, заключается в использовании очередей заданий в моей программе (а не очередей amq). Таким образом, всякий раз, когда вызовы завершены, программа будет искать дальнейшие задания в очереди и будет продолжаться соответствующим образом.

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

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

Жду ответа.,,

С уважением.

Answer 1

Я дам наш типичный ответ на этот вопрос: сначала протестируйте и примите решение на основе ваших результатов.

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

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

Измерьте в первую очередь, и решите на основе ваших результатов.