многосерверная архитектура чата java

Question

В настоящее время я нахожусь на стадии разработки чата (фактически переноса более старой версии с одним сервером) с использованием нескольких серверов (машин).

Я хочу использовать библиотеку Java NIO.

Причина, по которой я это делаю, заключается в том, что текущая реализация работает очень медленно, когда подключается огромное количество клиентов (около 10 тыс.), А также текущая реализация основана на библиотеке сокетов ввода-вывода. Я также оцениваю, что через 1 год будет около 40-50 тысяч живых клиентов.

Итак .. У меня есть несколько вопросов:

1. Как вы думаете, сколько клиентов сможет обработать NIO, поскольку я слышал, что это намного лучше, чем в старой реализации сокетов?
2. У вас есть какие-либо идеи или вы можете указать мне на уже реализованную архитектуру использования многосерверного чата.
3. с какими основными проблемами я могу столкнуться при использовании многосерверной архитектуры?

Заранее спасибо

Answer 1

Я не думаю, что есть какие-либо ограничения с точки зрения библиотеки NIO. В конечном итоге производительность зависит от конфигурации вашего сервера и сети.

---

Возможно, вы захотите взглянуть на Apache MINA Project для платформы NIO.

Apache MINA - это инфраструктура сетевых приложений, которая помогает пользователям легко разрабатывать сетевые приложения с высокой производительностью и высокой масштабируемостью. Он предоставляет абстрактный · управляемый событиями · асинхронный API через различные транспорты, такие как TCP / IP и UDP / IP через Java NIO.

Apache MINA часто называют:
, NIO framework · библиотека,
, платформа клиент-сервер · библиотека или
, сетевая библиотека сокетов.

Answer 2

Оценки сложно дать без тестирования производительности; количество поддерживаемых клиентов зависит от памяти, скорости / нагрузки процессора, пропускной способности / объема, требований к задержке, требований к хранилищу ...

Существует несколько подходов, которые вы можете использовать для обмена данными между серверами; Я бы пошел на широковещательный / многоадресный UDP между ними, так как это самый масштабируемый подход.

Самая большая проблема, с которой вы, вероятно, столкнетесь, - это справиться с перебоями в работе сервера и правильно управлять балансировкой нагрузки.

EDIT Если вы не привязаны к NIO для сервера-сервера, JMS в режиме pub / sub может быть хорошим решением.