Почему ActiveMQ, а не простая очередь/мьютекс?

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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