Я предполагаю, что вам не нужны статические активы 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.
Я уверен, что это не самый результативный процесс/сервер, но преимущество в том, что у него так много программного контроля, стоит того, и масштабирование имеет преимущество большей избыточности, поэтому мы не смотрим на сжатие последнего бита производительности из стека.
Я просто проверил действительно быстро, чтобы увидеть, могу ли я скопировать/вставить кучу кода, но мы быстро его кодируем, и у него много ссылок на вещи, которые не подходят для общественного потребления.