2012-04-20 1 views
3

Наш проект должен выполнить балансировку нагрузки TCP-пакетов на node.js.Nginx или LVS для баланса нагрузки Node.js?

Предложение: (Nginx или LVS) + Keepalived + Узел кластера

enter image description here

Вопросы:

  1. Высокие одновременных клиентских подключений к TCP-сервер должен быть долговечным , Какой из них более подходит, Nginx или LVS?
  2. Нам необходимо выделить разные уровни приоритетов для мастера узла на главном сервере (приоритет локального сервера будет выше, чем удаленные серверы). Кто может это сделать, Nginx или LVS?
  3. Чье использование процессора меньше, а пропускная способность выше, Nginx или LVS?
  4. Любые рекомендуемые документы для сравнения производительности/функции производительности Nginx и LVS?

Наконец, мы задаемся вопросом, разумно ли наше предложение. Есть ли другие лучшие предложения или компоненты для выбора?

ответ

3

Я предполагаю, что вам не нужны статические активы nginx для сервера, иначе LVS не будет вариантом.

1) nginx поддерживает только TCP через сторонний модуль https://github.com/yaoweibin/nginx_tcp_proxy_module Если вам не нужен веб-сервер, я бы сказал, что LVS более подходит, но см. Мой дополнительный комментарий в конце ответов # 'd.

2) LVS поддерживает приоритет, nginx - нет.

3) Возможно, LVS: nginx - это userland, ядро ​​LVS.

4) Ложь, проклятая ложь и бенчмарки. Вы должны имитировать свою нагрузку на свое оборудование, написать скрипт клиентского узла и поднять настройку.

Мы смотрим на происходящее все узел спереди назад с до https://github.com/LearnBoost/up Не в производстве, но мы проводим этот маршрут по следующим причинам:

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

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

3) Мы можем видеть все, потому что мы нажимаем любую метрику, которую хотим видеть на сервере redis.

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

Я просто проверил действительно быстро, чтобы увидеть, могу ли я скопировать/вставить кучу кода, но мы быстро его кодируем, и у него много ссылок на вещи, которые не подходят для общественного потребления.