ZMQ pub / sub надежный / масштабируемый дизайн

Question

Я разрабатываю архитектуру pub / sub с помощью ZMQ. Мне нужна максимальная надежность и масштабируемость, и я потерялся в аду предоставляемых возможностей.

На данный момент у меня есть набор издателей и подписчиков, связанных брокером. Брокер - это простое устройство пересылки, открывающее интерфейс для издателей и серверную часть для подписчиков.

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

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

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

Я также написал своего рода «ленивый пиратский» (т.е. попробуйте / повторить один за другим) надежную службу имен на случай, если основная служба имен упадет.

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

Может быть, здесь можно будет использовать что-то на базе маршрутизатора / дилера?

Приветствую любые советы!

Answer 1

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

Вы заблудились из-за неправильного подхода. Считайте 0MQ языком, который вы еще не очень хорошо знаете. Если вы начнете с попытки написать «максимальная надежность и масштабируемость», вы закончите с рвотой Годзиллы.

Итак: используйте подход, который я использую в Руководстве. Начните с минимального решения для основного потока сообщений и заставьте его работать должным образом. Очень внимательно подумайте о том, какие розетки использовать. Затем вносите дополнительные улучшения, каждый раз полностью тестируя, чтобы убедиться, что вы понимаете, что на самом деле происходит. Регулярно реорганизуйте код по мере его роста. Продолжайте, пока не получите стабильную минимальную версию 1. Не стремитесь к "максимуму" с самого начала.

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

Повторяйте, пока полностью не решите проблему и не узнаете, как ее решить.

Answer 2

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

Вместо того, чтобы обрабатывать это на уровне приложения, вы можете справиться с этим на уровне сети.Относитесь к своим брокерам, как к любой другой простой сетевой службе, и используйте механизм аварийного переключения IP (например, pacemaker / corosync, UCARP и т. Д.), Чтобы передать виртуальный IP-адрес вторичной службе, если первичная становится недоступной.

Это значительно упрощает работу ваших издателей и подписчиков, поскольку вам не нужна служба имен.Им нужно знать только об одном виртуальном IP-адресе.ZMQ позаботится о повторном подключении к службе по мере необходимости (например, при аварийном переключении).