Зачем использовать AMQP/ZeroMQ/RabbitMQ

Question

в отличие от написания собственной библиотеки.

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

Мне интересно использовать ZeroMQ для межсерверного и межпроцессного взаимодействия.Мой партнер предпочел бы кататься самостоятельно.Я жду от сообщества ответа на этот вопрос.

Я сам довольно начинающий программист и только что узнал об очередях сообщений.Когда я погуглил и прочитал, кажется, что все используют очереди сообщений для самых разных целей, но почему?Чем они лучше, чем написание собственной библиотеки?Почему они так распространены и почему их так много?

Answer 1

что делает их лучше, чем написание собственной библиотеки?

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

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

• вашему приложению придется взаимодействовать с машиной с прямым порядком байтов (sparc/powerpc) с машиной с прямым порядком байтов (x86, intel/amd).В вашей системе обмена сообщениями было некоторое предположение о порядке байтов:иди и исправь это
• вы разработали свое приложение так, чтобы оно не было бинарным протоколом/системой обмена сообщениями, и теперь оно работает очень медленно, потому что вы тратите большую часть времени на его анализ (количество сообщений увеличилось, и анализ стал узким местом):адаптируйте его, чтобы он мог передавать двоичную/фиксированную кодировку

• вначале у вас было 3 машины в локальной сети, никаких заметных задержек все доходит до каждой машины.ваш клиент/босс/босс-дьявол с заостренными волосами появляется и говорит вам, что вы установите приложение в глобальной сети, которой вы не управляете, - и тогда у вас начинаются сбои соединения, плохая задержка и т. д.вам нужно сохранить сообщение и повторить попытку отправки позже:вернитесь к коду и подключите это (и наслаждайтесь)

• Отправленные сообщения должны иметь ответы, но не все из них:вы отправляете некоторые параметры и ожидаете в результате электронную таблицу, а не просто отправляете и подтверждаете, возвращаетесь к коду и подключаете все это (и наслаждаетесь).

• некоторые сообщения имеют решающее значение, и их прием/отправка требует надлежащего резервного копирования/сохранения/.Почему ты спрашиваешь ?цели аудита

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

Вы можете реализовать это самостоятельно, но не тратьте на это много времени:вы, вероятно, все равно замените его позже.

Answer 2

Это очень похоже на вопрос: зачем использовать базу данных, если вы можете написать свою собственную?

Ответ заключается в том, что использование инструмента, который использовался некоторое время и хорошо понятен во многих различных случаях использования, окупается все больше и больше с течением времени и по мере развития ваших требований. Это особенно верно, если в проекте участвует более одного разработчика. Вы хотите стать сотрудником службы поддержки системы очередей, если вы переходите на новый проект? Использование инструмента предотвращает это. Это становится чужой проблемой.

Показательный пример: постоянство. Написать инструмент для хранения одного сообщения на диске очень просто. Написание персистора, который масштабируется и хорошо работает и стабильно, во многих различных случаях использования, является управляемым и дешевым в поддержке, сложно. Если вы хотите, чтобы кто-то жаловался на то, как тяжело, тогда посмотрите на это: http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange

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

Answer 3

Я сам собираюсь использовать ZeroMQ - поэтому я наткнулся на этот вопрос.

Давайте пока предположим, что у вас есть возможность внедрить систему очереди сообщений, которая отвечает всем вашим требованиям. Зачем вам использовать ZeroMQ (или другую стороннюю библиотеку) по сравнению с подходом «сделай сам»? Просто - стоимость.

Давайте на минутку предположим, что ZeroMQ уже отвечает всем вашим требованиям. Все, что нужно сделать, это интегрировать его в свою сборку, прочитать какой-нибудь документ и затем начать его использовать. Это должно быть гораздо меньше усилий, чем кататься самостоятельно. Кроме того, бремя обслуживания было перенесено на другую компанию. Поскольку ZeroMQ бесплатен, вы как будто только что увеличили свою команду разработчиков, чтобы включить (часть) команду ZeroMQ.

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

Возможно, вы (или, скорее, ваш партнер) страдаете, как и многие разработчики, от " Не Придумано здесь " синдром? Если это так, скорректируйте свое отношение и оцените использование ZeroMQ. Лично я очень предпочитаю преимущества отношения Proudly Found Elsewhere. Я надеюсь, что смогу найти ZeroMQ ... время покажет.

РЕДАКТИРОВАТЬ: я сталкивался с этим 20Standards_% 20 ___. Wmv "rel =" noreferrer "> видео от разработчиков ZeroMQ, в котором говорится о почему вам следует использовать ZeroMQ.

Answer 4

  

что делает их лучше, чем написание собственной библиотеки?

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

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

Answer 5

Прежде чем писать собственную библиотеку, прочитайте Руководство по 0MQ здесь: http://zguide.zeromq.org/ страница: все

Скорее всего, вы либо решите установить RabbitMQ, либо сделаете свою библиотеку поверх ZeroMQ, поскольку они уже выполнили все сложные части.

Answer 6

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