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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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 ... время покажет.

РЕДАКТИРОВАТЬ: я наткнулся на это видео от разработчиков ZeroMQ, в котором говорится о , почему вы должны использовать ZeroMQ.

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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