Эффективный TCP-сервер и преобразование данных в Java

Question

Фон

В моем java-приложении у меня достаточно большие объемы данных, хранящиеся в ConcurrentHashMap.

Теперь мне нужно передать эти данные клиентскому клиенту в формате XML, когда клиент подключается к моему приложению через порт TCP.

Итак, в двух словах - у меня есть TCP-сервер, к которому подключается клиент. Как только клиент подключается, я должен прочитать все данные на карте и выложить их в формате XML (настраиваемый) на порт TCP. Данные на карте обновляются автоматически откуда-то еще, используя рабочие потоки и т. Д., Поэтому мне приходится снова и снова отправлять свежие данные клиенту через этот порт tcp.

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

ПРИМЕЧАНИЕ. В будущем мне может потребоваться поддержка нескольких форматов вывода (например, через запятую, Json, HL7 и т. Д.) Для простоты, скажем, есть другой порт TCP, который клиент может подключить для определенного формата.

Вопрос

С учетом сказанного - я искал лучшее решение для моей реализации TCP-сервера и процесса преобразования данных из ConcurrentHashMap в XML.

Для TCP-сервера люди говорят о

• NETTY

• Kryonet

• Apache MINA

Мой клиент будет сторонним, так что я думаю, что kryonet отсутствует, поскольку клиент не будет заниматься "регистрацией", необходимой Kryonet. Так что из MINA и NETTY, что является масштабируемым и легче для понимания? Любое другое предложение?

ДЛЯ преобразования данных из ConcurrentHashMap в XML я думал об использовании XSTREAM Любое другое предложение?

Спасибо

Answer 1

Как быстро это должно быть? Кажется, что вы должны быть в состоянии создать что-то, что возвращает менее чем за 10 мс (плюс RTT), просто используя tomcat и стандартную среду, такую ​​как spring-mvc. Используйте JAXB для преобразования объектов в XML. Если вы хотите поддерживать дополнительные форматы вывода, такие как json, это тривиально (для этого используйте библиотеку Джексона, api аналогичен JAXB).

У меня был сотрудник, который попробовал подход с сокет-сервером, и в итоге мы использовали tomcat, потому что он был почти таким же быстрым, а QPS был более стабильным / предсказуемым.

Answer 2

Если у вас есть 100 или 1000 соединений, вы должны начать учитывать масштабируемость. Однако, если у вас небольшое количество подключений, вам может понадобиться использование простых сокетов.

Если изменяется только часть данных, лучше отправлять только те данные, которые изменились, или, по крайней мере, только восстановить XML, который изменился.