Реализовать прочный паб / саб? - PullRequest
0 голосов
/ 27 мая 2011

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

Как я могу это реализовать?

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

Итак, это будет график времени:

Издатель запущен. Нет слушателей.

Издатель отправляет сообщение 1.

Издатель отправляет сообщение 2.

Издатель отправляет сообщение 3.

Слушатель 1 запускается и подписывается с издателем.

Издатель отправляет сообщение 4.

Слушатель 1 получает сообщение 4.

Слушатель 2 запускается и подписывается с издателем.

Издатель отправляет сообщение 5.

Слушатель 1 получает сообщение 5.

Слушатель 2 получает сообщение 5.

Слушатель 2 удара.

Издатель отправляет сообщение 6.

Слушатель 1 получает сообщение 6.

Издатель отправляет сообщение 7.

Слушатель 1 получает сообщение 7.

Слушатель 2 возвращается, подписка не требуется.

Слушатель 2 получает сообщение 6.

Слушатель 2 получает сообщение 7.

Суть в том, что мне нужна одна очередь на слушателя и одна очередь или канал для отправки и получения сообщений для «начала прослушивания» и «остановки прослушивания». Думал ли я в правильном направлении, или я совершенно не прав?

Ответы [ 2 ]

3 голосов
/ 27 мая 2011

Вам не нужна отдельная очередь на подписчика , но вам понадобится как минимум две очереди. Первоначальный ключ к масштабируемости - убедиться, что когда издатель доставляет свое первоначальное сообщение, вы не пытаетесь «разветвлять» его всем подписчикам в этот момент времени. Вместо этого вы помещаете его в полученную очередь и немедленно возвращаетесь, чтобы издатель узнал, что это успешно. Оттуда у вас есть работники, которые питаются от основной очереди приема и несут ответственность за то, чтобы «разветвлять» сообщение различным подписчикам. Он делает это, выясняя, кто эти подписчики, и генерируя N сообщений, содержащих исходное сообщение от издателя, с информацией об адресе / привязке каждого слушателя и помещая их в очередь доставки. Наконец, у вас есть работники, которые отвечают за удаление сообщений из очереди доставки и попытки доставки с использованием информации об адресе / привязке.

Способ устранения ошибок доставки может быть связан с перемещением сообщения в очередь повторных попыток, в которой сообщения будут помещены в спящий режим на Х в течение определенного времени, прежде чем их снова поместят в очередь доставки. Тогда вам, конечно, придется обрабатывать сообщения об отравлении, когда вы повторяли 5 раз, а слушатель просто выдает вам ошибки каждый раз. Их нужно переместить в какую-нибудь очередь недоставленных сообщений для сообщения об ошибках.

0 голосов
/ 27 мая 2011

Вы правы, и именно так NServiceBus (например) реализует pub-sub поверх MSMQ. Подробнее об этом здесь: http://docs.particular.net/samples/pubsub/.

...