Единичный NIO канал или пул NIO каналов для обмена данными между сервисами на одном сервере?
Здравствуйте!
Мне необходимо, чтобы два сервиса обменивались информацией настолько быстро, насколько это возможно. К сожалению, не могу указать, какова будет нагрузка, потому не будем принимать во внимание этот фактор.
Сервисы работают на компьютере с Ubuntu, написаны на Java, обмен информацией будет происходить множеством пакетов разного размера (от 50 байт до 100 килобайт). Возможно количество сервисов больше двух и соотношение «один ко многим».
По некоторым причинам я не могу реализовать весь функционал в одном сервисе, необходимо именно несколько их.
Навскидку вижу три варианта:
1. Открыть между каждыми двумя приложениями один канал и вести обмен по нему.
2. Открыть между приложениями фиксированное количество каналов и задействовать их по очереди.
3. Открывать на каждый сеанс персональный канал, вести обмен через него, а по завершении сеанса закрывать.
Я бы попробовал протокол sctp, в 7-й java появилась поддержка в jdk. В отличие от tcp, протокол ориентирован на сообщения (т.е. нет необходимости кодировать как-то кодировать данные в случае tcp), можно задать получение сообщений по мере их поступления (а не по порядку). Есть одно но, размер сообщения ограничен в 64 кб. Зато достаточно открыть только 1 соединение. Посмотрите в wiki: ru.wikipedia.org/wiki/SCTP
Если использовать классический tcp и требования к latency жесткие, то скорее всего сделал бы пул каналов.
P.S. JMX не рассматриваете из-за требований к производительности?
Опечатался, имел ввиду JMS. Просто когда будут появляться новые требования, то, скорее всего с jms будет жить проще. Например, делать повторные попытки доставить сообщения, если получатель недоступен (упал/перезагружается).
Я, к сожалению, не могу перезатачиваться с каналов, поскольку у меня есть собственный довольно обширный и отлаженный велосипед, который нужно просто дополнить описанной функциональностью.
Если JMS никак, то лучше всего открывать по одному каналу на каждую связь сервис-сервис
Открывать каналы с каждым сообщением сильно накладно, а держать один канал на все сервисы тоже не очень хорошо — допустим, сервис1 послал 100 пакетов, а сервис 2 послал 1 пакет, тогда пока из канала не прочитают 100 пакетов от первого, 1 пакет от второго получен не будет.
Количество каналов должно равняться количеству связей между сервисами. Если сервис1 общается с двумя другими и сервис2 с тремя другими, то всего должно быть 5 каналов.
Поговорил со своими сетевиками, они особой причины создания несколько сокетов не видят. Если в сети проблема, то все сокеты тоже будут терять пакеты. Я думаю, не нужно оптимизировать без нужды, сделайте, как проще, и потестируйте.
Простой
