Рекомендации по использованию ZeroMQ

Я разрабатываю новое клиент-серверное приложение (.Net) и до сих пор использую WCF, который прекрасно подходит для подхода к запросу приложения. Однако меня попросили заменить это на решение на основе сокетов, частично для поддержки клиентов, не являющихся клиентами, и будущих требований к публичным суб-вещам/вещам (я понимаю, что WCF способен, но есть и другие факторы, лежащие в основе решения). Провавшись неудачно при написании моего собственного решения асинхронного сокета, я теперь смотрю на ZeroMQ.

В моем клиентском приложении есть несколько фоновых потоков, которые периодически запрашивают данные с сервера. Кроме того, некоторые действия пользовательского интерфейса (например, нажатие кнопки) могут вызывать сообщение на сервере. WCF сделал это легко - код просто называется соответствующим методом на прокси-сервере Singleton WCF (на самом деле я использую средство WCW Castle Windsor, которое дает мне возможности асинхронного вызова, но это, вероятно, не имеет отношения к моему вопросу).

Я не слишком уверен, как этот подход переведёт на ZeroMQ, особенно в отношении управления сокетами - я очень новичок в ZeroMQ и все еще читаю руководство. Правильно ли я говорю, что мне понадобится отдельный сокет для каждого потока (т.е. Два потока b/g и пользовательский интерфейс)? Как насчет времени жизни сокета - создаем ли я каждый раз, когда я хочу отправлять/получать (предположительно неэффективно), или создавать сокет, когда поток запускается и повторно используется для всего жизненного цикла потока?

Ответы

Ответ 1

Одно должно быть очень ясно. Сокеты ZMQ могут подключаться и разговаривать только с сокетами ZMQ.

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

Выбор ZMQ Sockets для таких средств - хорошая идея. Это позволяет вам мгновенно создавать много коммуникационных шаблонов, таких как req/rep, push/pull, pub/sub и т.д., А также создавать более сложные топологии с использованием устройств ZMQ.

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

Является ли ваше клиентское приложение регулярными сокетами? Можно ли переписать его для использования сокетов ZMQ?

если нет, тогда не используйте сокеты ZMQ для внешнего интерфейса но только для вашей внутренней связи компонентов.

[Изменить: Дальнейшие заметки]

ZMQ - это оболочка поверх сокетов, но это делает несколько вещей, которые трудно выполнить вручную

  • Он управляет обменом сообщениями с более высокой пропускной способностью, одновременно добавляя несколько сообщений
  • Оптимизирует использование сокета одновременно
  • Сокет может отправлять сообщения только одному другому сокету, гнездо ZMQ может подключаться к нескольким сокетам ZMQ
  • Решение на основе сокетов на основе ZMQ может сразу же использовать различные шаблоны - REQ/REP, PUSH/PULL, PUB/SUB и т.д.

Как обычно, ZMQ является ошибкой в ​​очереди сообщений.

  • Очередь сообщений как доступная имеет другие свойства, такие как сохранение сообщений и гарантия доставки и т.д. путем реализации очереди для хранения.
  • ZMQ означает "Zero Messaging Queue"

В последнее время я изучал ZMQ и очень рад его использовать.

Оформить мой мини-учебник по ZMQ и посмотреть, имеет ли смысл использовать его:

http://learning-0mq-with-pyzmq.readthedocs.org/en/latest/