Как разбросать запросы на сервера по IP ?

Ты пишешь не в ту ветку.

Ты имеешь в виду sticky sessions?

Чтобы юзер с одним IP «прилип» к определ серверу

А зачем?

Балансировка нагрузки, Карл!

http://nginx.org/en/docs/http/load_balancing.html

Для nginx или HAProxy?

Nginx:

http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#ip_hash

HAProxy

http://blog.haproxy.com/2013/04/22/client-ip-persistence-or-source-ip-hash-lo...

А чем это лучше RR балансировки?

Это когда софт Г

http://nginx.org/ru/docs/http/ngx_http_upstream_module.html не?

тем что не нужно использовать «кластерные решение», КЭП

А что они будут делать, когда у них отгниет один из апстримов?

Эм, какие кластерные решения? Общее хранилище сессий теперь так называется?

Писать в штанишки и искать виновного. Порицать его и продолжать говнокодить говнопроект с говноархитектурой..

ну хотя бы

В пределах сессии ? Ну протухнет n/k кол-во сессий. Зато надежно и просто

Ой да ладно тебе - наплоди masterов а потом переключайся между ними при малейшем пуке и пытайся что-то сделать чтобы это все работало Вот тебе и говноархитектура

сириусли? мемкэшд - это «кластерное решение»? Кажется, у нас здесь второй эрзент нарисовался.

Надежностью здесь и не пахнет. Что ты будешь делать, если у тебя апстрим насосал данных для обработки и внезано перестал отвечать за connect_timeout? Перебросишь все запросы на другой? Но ведь первый их тоже обрабатывает, беря из бэклога.

речь идет о redis. Не понимаю как ты предлагаешь его использовать в конфигурации «master-slave» тем более что он однопоточный.

Ну сдох и фиг с ним - далее то данные будут обрабатываться другими потоками ?

Но ведь первый их тоже обрабатывает, беря из бэклога.

Что ты под этим имеешь ввиду ? Сервис сдох nginx на него запросы не посылает.

На него запросы могли прийти и висеть в очереди на обработку.

Кто тебе мешает в редис ходить несколькими клиентами одновременно?

Но зачем привязывать пользователя к серверу?

Хотя тебе и без меня уже всё объяснили.

ну да редис однопоточный соотв больше 1 процессора ему не сьесть если на сервере 20 ядер соотв получаем узкое место. балансировка по ап решает эту проблему

http://redis.io/topics/benchmarks

With high-end configurations, the number of client connections is also an important factor. Being based on epoll/kqueue, the Redis event loop is quite scalable. Redis has already been benchmarked at more than 60000 connections, and was still able to sustain 50000 q/s in these conditions. As a rule of thumb, an instance with 30000 connections can only process half the throughput achievable with 100 connections.

Нет, конечно, хозяин-барин, можете и липкие сессии использовать.

балансировка по ап решает эту проблему

и добавляет новых :D

Да nginx тоже так умеет только вот почему-то его запускают обычно в несколько workeров :)

Да и при любой CPU-жрщем запросе типа zrange 0 -1 все это очередь будет ждать пока этот запрос исполнится :)

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

А редис должен работать на мелких ключах (

С чего ты это взял ? Необязательно - Это ж не memcached :)

Потому что в другом случае в нем нет смысла, только лишняя трата времени.

Альтернативы по твоему ?

БД которая умеет в много потоков?

Ну да если следовать твоей логике не было бы таких проектов: https://github.com/yinqiwen/ardb

Следуя подобной логике этот проект и появился..

Note:

Ardb uses 1 threads in this benchmark test, since redis is single threaded application. But ardb is actually a multithreaded applcation, you can start the server with more threads by setting 'thread-pool-size' to 2 or higher to increase the read/write performance.

But ardb is actually a multithreaded applcation