Сервисный автобус (возможно?) Для веб-фермы

Question

Часть этого вопроса: я даже не знаю, что именно мне нужно будет спросить, поэтому я начну с ситуации и буду работать оттуда.

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

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

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

Я изначально занимался этим с помощью поставщика WCF Mesh, который не был хорошо документирован для начала, теперь у меня возникают проблемы с отправкой сообщений, иногда они теряются или задерживаются (я не уверен на 100% что там происходит), но он затягивает длинный опрос для COMET и ломает вещи довольно странным образом (нажатие кнопки может вызвать событие, или оно будет зависать в течение 10 секунд {длительная продолжительность опроса} и фактически ничего не делать).

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

1. Нет единой точки отказа (вне базы данных)
2. Нет жестко прописывать сверстников.
3. Near-реальном времени (без опроса, на основе событий было бы лучше)

Мой идеальное решение предполагает, что, когда сервер приходит вверх, он позволяет другим серверам знать о его существовании (даже если это просто строка где-нибудь в таблице), и они могут начать отправлять широковещательные сообщения между собой, причем каждый сервер является одновременно издателем и подписчиком. Это то, что я имел в WCF Mesh, но я не слишком уверен в этом коде.

Может ли кто-нибудь указать мне в правильном направлении? Даже правильные условия для поиска в документах для поставщиков сервисных автобусов были бы хороши на этом этапе. Или сервисные автобусы не то, что я хочу? На этом этапе я решил бы настроить сервер Jabber на каждом веб-сервере и использовать его, если он может соответствовать моим ограничениям.

Answer 1

Я не могу говорить тонну NServiceBus, но я ожидаю, что ответы будут похожи.

1. Единая точка отказа: MSMQ может использовать многоадресную, что означает каждая конечная точка будет транслировать это существование и не требуется никакой таблицы БД. RabbitMQ использует этот процесс привязки Exchange-to-Queue, что означает, что пока экземпляр или кластер Rabbit встанут, сообщения все еще существуют. RabbitMQ может быть сгруппирован, MSMQ быть не может. * Примечание. У вас могут быть проблемы с многоадресной рассылкой с Rackspace, не знаю, как они работают. Если это так, вам придется отказаться от служб времени выполнения для MSMQ (а не RabbitMQ), что создаст единую точку сбоя, потому что у каждого есть одна точка для координации управляющих сообщений.

2. Твердое кодирование сверстников: обсуждалось выше; Многоадресная рассылка MSMQ обрабатывает его.Кролик также можно сделать, просто привяжите очереди к обмену, который вы хотите прослушать. MassTransit позаботится об этом для вас.

3. Near-realtime: оба используют обмен сообщениями, который близок к реальному времени. В вашем коде потребителя сообщений нет опроса.

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

Чтобы начать работу с MassTransit, у нас есть документация: http://readthedocs.org/projects/masstransit/ и список рассылки http://groups.google.com/group/masstransit-discuss. Присоединяйтесь к списку рассылки, если у вас возникнут будущие вопросы, и кто-то попытается помочь вам.