Почему ActiveMQ, в отличие от простого Queue / Mutex? - PullRequest
4 голосов
/ 17 апреля 2009

Завтра я представляю свое обоснование выбора внутрипроцессной реализации очереди сообщений, и я не могу сформулировать свои рассуждения. Мои со-дизайнеры предлагают реализовать простую асинхронную очередь, используя только базовый список заданий и мьютекс для управления доступом, где я предлагаю ActiveMQ во встроенном режиме. Меня лично впечатлил ActiveMQ, и я хотел бы привести несколько веских и убедительных аргументов в поддержку своего внутреннего впечатления.

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

Стоит отметить, что до сих пор управляемость и расширяемость решения не были вескими аргументами. Я был бы рад, если бы кто-то дал мне больше аргументов. Может ли форум помочь мне с этим?

Ответы [ 3 ]

4 голосов
/ 17 апреля 2009

Аргументы ваших коллег не безосновательны. Добавление ActiveMQ в проект добавляет еще одну зависимость. Вероятно, его будет сложнее использовать, и он будет занимать больше места, чем пользовательское решение. Кроме того, поскольку вы принимаете его, он, вероятно, станет вашей обязанностью поддерживать и поддерживать бесперебойную работу - ошибки и все.

При этом ActiveMQ (и другие очереди) будут делать то, что вы могли бы написать сами, но это может оказаться проблемой. Одной из них является поддержка всего API-интерфейса JMS (хотя я предполагаю, что вы используете Java ... если нет, то этот пункт недействителен). Сериализация избыточных сообщений на диск в ситуациях с большим объемом памяти - это другое. Надежные подписчики и селекторы сообщений - это еще несколько вещей, которые приходят на ум. Кажется, что это в основном вещи для ваших нужд, но они становятся очень важными для надежной доставки сообщений.

Что бы вы ни решили, инкапсулируйте окончательный выбор посредника сообщений в стороне от клиентского кода, чтобы его было легче переключать.

3 голосов
/ 17 апреля 2009

Отсутствие необходимости отлаживать код параллелизма в странных крайних случаях - большое преимущество. Я не знаю, насколько важна эта структура как часть вашего общего проекта, но если очередь сообщений является большой частью вашего проекта, то вы можете воспользоваться огромными преимуществами, используя реализацию, которую имеет кто-то другой написано, уже отлажено, и будет поддерживать для вас. Если это просто какая-то единственная часть неважной подсистемы, то, вероятно, не имеет значения, что вы в итоге делаете. Но если это критично, я бы скорее подал отчет об ошибке, чем потратил время на отладку кода параллелизма (я уже начинаю откатываться в страхе!).

Краткая версия: не позволяйте синдрому NIH помешать вам использовать чужую работу, чтобы выполнять свою работу быстрее, лучше и дешевле. Но и не строите гору из мухи слона.

3 голосов
/ 17 апреля 2009

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

...