Всем добра!
Ранее я не имел дела с высоконагруженными сетевыми приложениями и распределёнными службами, поэтому сейчас нахожусь в некотором замешательстве. Ситуация такая. У меня есть 20 экземпляров одного и того приложения, запущенного на 6 машинах. Каждый из экземпляров обслуживает до 500 клиентских подключений. Понадобилась возможность отправлять клиентам уведомления о изменениях в состоянии общих документов, над которыми они работают. Вот ключевые моменты, которые меня смущают:
1. Уведомления надо отправлять группам клиентов, которые группы могут быть распределены по экземплярам любым образом.
2. Я не могу подключиться к экземпляру, к которому подключен конкретный клиент и сказать ему, чтобы тот передал уведомление. Тоесть технически могу, но это требование заказчика.
Я резонно предположил, что должны существовать сервисы подобные memcached, но предоставляющие очередь с функцией подписки вместо хэштаблицы. С возможностью линейного масштабирования. В принципе я представляю как написать такую штуку самому и даже нашёл годную статью как это сделать, но не хочу велосипед. Всё, что мне нужно, это создавать очереди и подписываться на сообщения в них для группы адресатов. Тогда каждый экзепляр приложения сможет отправить данные любому пользователю, а экземпляр, обслуживающий группу пользователей, сможет получить и переправить им соответствующие уведомления.
Непосредственно вопросы такие.
1. Правильное ли решение я пытаюсь применить или можно лучше/проще?
2. Какие из существующих технологий уважаемое сообщество порекомендует мне применить в моём случае? Сам я сейчас читаю про rabbitMQ и 0mq, но мне они видятся слишком навороченными для моего простейшего случая.
Спасибо уже за то, что дочитали вопрос до конца
Здравствуйте, Аноним, Вы писали:
А>Всем добра!
А>Ранее я не имел дела с высоконагруженными сетевыми приложениями и распределёнными службами, поэтому сейчас нахожусь в некотором замешательстве. Ситуация такая. У меня есть 20 экземпляров одного и того приложения, запущенного на 6 машинах. Каждый из экземпляров обслуживает до 500 клиентских подключений. Понадобилась возможность отправлять клиентам уведомления о изменениях в состоянии общих документов, над которыми они работают. Вот ключевые моменты, которые меня смущают:
А>1. Уведомления надо отправлять группам клиентов, которые группы могут быть распределены по экземплярам любым образом.
А>2. Я не могу подключиться к экземпляру, к которому подключен конкретный клиент и сказать ему, чтобы тот передал уведомление. Тоесть технически могу, но это требование заказчика.
А>Я резонно предположил, что должны существовать сервисы подобные memcached, но предоставляющие очередь с функцией подписки вместо хэштаблицы. С возможностью линейного масштабирования. В принципе я представляю как написать такую штуку самому и даже нашёл годную статью как это сделать, но не хочу велосипед. Всё, что мне нужно, это создавать очереди и подписываться на сообщения в них для группы адресатов. Тогда каждый экзепляр приложения сможет отправить данные любому пользователю, а экземпляр, обслуживающий группу пользователей, сможет получить и переправить им соответствующие уведомления.
А>Непосредственно вопросы такие.
А>1. Правильное ли решение я пытаюсь применить или можно лучше/проще?
А>2. Какие из существующих технологий уважаемое сообщество порекомендует мне применить в моём случае? Сам я сейчас читаю про rabbitMQ и 0mq, но мне они видятся слишком навороченными для моего простейшего случая.
А>Спасибо уже за то, что дочитали вопрос до конца
Redis может подойти
Publish/Subscribe messaging
Если уведомления не тяжеловесные 60000(6*20*500) может даже справится один хороший сервер.
Масштабируется через репликацию, master + много slave.
Простейший вид балансировки запросов прямо на клиенте. Сервер выбирается случайно из списка.
list servers = ["server1" ... "serverN"];
redis.connect( servers[ random(servers.length) ] );
Здравствуйте, roro, Вы писали:
R>Redis может подойти Publish/Subscribe messaging
Спасибо, посмотрю.
R>Если уведомления не тяжеловесные 60000(6*20*500) может даже справится один хороший сервер.
R>Масштабируется через репликацию, master + много slave.
Звучит заманчиво.
R>Простейший вид балансировки запросов прямо на клиенте. Сервер выбирается случайно из списка.
R>list servers = ["server1" ... "serverN"];
R>redis.connect( servers[ random(servers.length) ] );
Используется оптимизированный вариант этого метода — перемешать список случайным образом при старте и использовать сервера по очереди
Здравствуйте, Аноним, Вы писали:
А>Всем добра!
А>2. Какие из существующих технологий уважаемое сообщество порекомендует мне применить в моём случае? Сам я сейчас читаю про rabbitMQ и 0mq, но мне они видятся слишком навороченными для моего простейшего случая.
А>Спасибо уже за то, что дочитали вопрос до конца
RabbitMQ — годная штука, и неплохо масштабируемая.
Здравствуйте, Аноним, Вы писали:
apache kafka
