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

а не писать собственную библиотеку.

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

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

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

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Предположим на данный момент, что у вас есть возможность внедрить систему очередности сообщений, которая отвечает всем вашим требованиям. Почему вы принимаете ZeroMQ (или другую стороннюю библиотеку) по принципу "roll-your-own"? Простая стоимость.

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

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

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

EDIT: я столкнулся с этим видео от разработчиков ZeroMQ, в котором говорится о , почему вам следует использовать ZeroMQ.

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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