SignalR в AppHarbor с несколькими экземплярами

Я оцениваю использование SignalR в приложении, размещенном в AppHarbor, работающем на 2+ экземплярах (веб-работники), но, читая, похоже, что это не сработает: Вики SignalR говорит, что масштабирование в веб-ферме все еще находится в разработке (и более 2 веб-воркеров для меня звучит как веб-ферма). Еще один вопрос здесь, в StackOverflow говорит, что не будет работать более чем на одном сервере iss. С другой стороны, на сайте поддержки AppHarbor говорят, что все работает отлично. не особо задумываясь об информации (не ответил на все вопросы, такие как количество одновременных подключений, ограничения балансировщиков нагрузки и т. д.).

Может ли кто-нибудь подтвердить, является ли SignalR правильным путем для AppHarbor?

Спасибо!


person Pietro    schedule 13.02.2012    source источник


Ответы (2)


Дэвид Фаулер работает над хранилищем сообщений Redis для SignalR. код находится на Github, и я считаю, что именно он позволит масштабировать приложения SignalR для нескольких экземпляров AppHarbor.

person friism    schedule 13.02.2012
comment
Это правильно. Мы, вероятно, рассмотрим решения, использующие и другие технологии, но вот пример JabbR, работающего на Redis (с использованием одного узла прямо сейчас). Это приложение должно иметь возможность масштабироваться между узлами. jabbr-redis.apphb.com - person davidfowl; 13.02.2012
comment
Я предполагаю, что Redis используется для хранения сообщений, верно? Где обычно хранится SignalR? В локальной файловой системе (которая, очевидно, стирается appharbor при каждом развертывании)? Часть для очистки при развертывании не будет работать с локальной файловой системой? У каждого веб-воркера своя собственная файловая система или только одна файловая система для приложения? - person Pietro; 13.02.2012
comment
SignalR обычно хранит данные в памяти. Текущая реализация использует Redis как чистую шину сообщений, а не для хранения сообщений. Сообщения реплицируются на каждый узел, когда они приходят. Что нужно добавить, так это некоторую отказоустойчивость, чтобы, когда появляется новый узел или тот, который был отключен, возвращался обратно, он повторно заполнял свой кеш из Redis или из любого места, где мы решили буферизовать сообщения. - person davidfowl; 13.02.2012
comment
@Pietro, использующий локальную файловую систему для хранения, не сработает, поскольку каждый экземпляр имеет свою собственную файловую систему, которая не синхронизируется с другими экземплярами. - person friism; 14.02.2012
comment
@dfowler, когда вы говорите о текущей реализации, что вы имеете в виду? Оригинальный SignalR или ваш SignalR.Redis? Интересно, исходный SignalR уже реплицирует сообщения на каждый узел, когда они приходят? - person Pietro; 14.02.2012
comment
SignalR сам по себе находится в памяти, на одном узле. SignalR.Redis использует Redis для отправки сообщений всем узлам. - person davidfowl; 14.02.2012
comment
возможно, для кого-то (например, меня), кто не знает Redis, следует отметить, что с помощью Booksleeve и Redis вы публикуете и подписываетесь на сообщения, похожие на шину сообщений. - person jl.; 21.02.2012
comment
@dfowler Вам действительно нужно повторно заполнять кеш, когда узел возвращается? Узел MessageBus должен заботиться только о новых сообщениях, прошлые сообщения будут обслуживаться из репозитория, и это обрабатывается приложением-потребителем, а не самим SignalR (т. е. методом GetPreviousMessages Jabbr Chat Hub). - person Javi; 04.03.2012
comment
Это зависит от того, я думаю, что это нужно настраивать, чтобы люди могли настроить долговечность, но, возможно, я слишком много думаю об этом. - person davidfowl; 05.03.2012
comment
Актуальную информацию о поддержке веб-ферм см. на странице сообщение в блоге dfowler о SignalR 0.5. - person Robert Westerlund; 12.05.2012
comment
SignalR.Redis больше не работает? Страницы на гитхабе больше нет. знак равно - person Nicholas J. Markkula; 03.12.2012

Обновленные ссылки на 2014 год:

страница SignalR Redis на GitHub, которая в настоящее время является просто URL-адресом документ Redis на веб-сайте ASP.Net.

person GraehamF    schedule 28.07.2014