Масштабирует ли NATS по горизонтали (пропускная способность)

Мы используем NATS и используем кластеризацию из 3+ узлов. У нас несколько производителей и много потребителей. Размеры сообщений небольшие (~ 100 байт), однако наша пропускная способность несколько высока. ~ 40к / сек. Весь трафик передается во внутренние сети с пропускной способностью 2x10 Гбит / с.

Мне было любопытно, поможет ли масштабирование кластера с большим количеством узлов пропускной способности кластера. У нас есть небольшая задержка, которая, кажется, немного увеличивается по мере того, как пишется больше сообщений в секунду.

В качестве второстепенного примечания, есть ли советы / рекомендации, которые можно сделать для повышения пропускной способности? В настоящее время мы используем protobufs, но есть ли какие-то настройки сервера, которые можно сделать?


nats.io messagebroker
person Quinton Pike    schedule 04.04.2017    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Пропускная способность может снизиться, если есть много подходящих подписок по данной теме.

Например, предположим, что вы используете 1 соединение и публикуете на foo. На foo есть 100 подписок. Когда сервер получит сообщение, он доставит его во все соответствующие подписки. В данном случае это означает, что TCP отправляет это сообщение 100 раз, независимо от того, принадлежат ли подписки одному и тому же соединению или нет.

При отправке подписчикам сервер не читает другие сообщения, опубликованные этим соединением.

Горизонтальное масштабирование путем добавления серверов может помочь, если вы также распределяете нагрузку подписок в кластере. В приведенном выше примере предположим, что 50 потребителей находятся на одном сервере, 50 - на другом, тогда сервер, получающий опубликованное сообщение, теперь должен будет отправить это сообщение только 50 + 1 раз (50 для своих локальных подписчиков, 1 для маршрута). Затем другой сервер отправит 50 сообщений своим локальным подписчикам.

Но простое добавление серверов не улучшит пропускную способность отдельного соединения, если была единственная (или не было) совпадающей подписки.

Еще один способ повысить пропускную способность паба - использовать больше подключений. Поскольку сервер использует процедуру go для каждого соединения (для чтения данных из сокета и их отправки в подписки), некоторая работа может быть распараллелена.

Я мог бы запустить какой-нибудь тест, включенный в репо, чтобы получить верхний предел, который вы можете получить на своей машине. Например, серверные стендовые тесты обычно записывают данные непосредственно в сокет вместо использования клиента NATS. Это необходимо для измерения производительности сервера без каких-либо ограничений, налагаемых реализацией клиента:

    go test -v -run=xxx -bench=. ./test

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

Надеюсь это поможет.

person I. Kozlovic    schedule 04.04.2017