Есть некая Система которая принимает запросы в json-формате, обрабатывает их и возвращает(выводит).
Предположим нагрузка ~400 запросов в секунду.
Время выполнения(среднее) запроса при минимальной нагрузке 0.075 сек. 
 
1) Есть ли смысл задумываться о создании дублирующих серверов-обработчиков при нагрузке 400 запросов в секунду?
2) Есть ли смысл городить распределение на php? есть готовые решения?
3) Оправдает ли себя схема:
a) отправляем запрос на первый сервер, где находиться скрипт-распределитель, который залазит в memcache где лежит массив пользователей которые обращались к шлюзу, с указанием на какой сервер определен пользователь. Если пользователь уже был, отправляем его на ранее отведенный сервер, если нет - отводим его на тот сервер, на котором меньше пользователей определено(по тому же массиву).
б) 2 и 3 сервера только обрабатывают запросы. 
в) memcache и mysql крутиться на отдельном, четвертом сервере. 

3.1) как наиболее разумно "пересылать" пользователя с сервера-распределителя, на сервер-обработчик? fopen? Curl? иначе? 
3.2) насколько адекватно определение "загруженности" сервера, так как описано? Нужно смотреть нагрузку на железо на серверах-обработчиках?
3.3) Разумно ли хранить массив "те кто были онлайн" в memcache? сможет ли он обрабатывать 400-800 запросов в секунду? не будет ли он "узким местом"?  

никто не сталкивался с такими задачами?

1) грубая оценка:
0,075сек * 400запросов / 2сервера = 15 сек поэтому, возможно, что и двух серверов будет мало  , правда, тут не учитывается много факторов, к тому же, если 0,075 сек на одном сервере (где и СУБД и похапе), то тут еще высвободится ресурсов, 
лично я работал с сервером (4 ядра, 8ГБ ОЗУ, HDD 12k rmp), который уверенно обрабатывал порядка 100-150 запросов/сек, причем логика была не простая и на каждый запрос приходилось порядка 10 запросов к СУБД (OLTP), все находилось на одном сервере. Так что тут самый надежный способ - это погонять прототипы нагрузочными скриптами.

2) если один сервер не будет справлятся, то для решения задачи в любом случае придется пилить распределенность + почти все системы имеют тенденцию расти (и по нагрузке и по сложности задач + часто новые модификации плодят костыли и вносят хаос в код) и если намечается рост и есть возможность, то лучше изначально спроектировать так, чтобы потом мощность можно было увеличивать добавлением новых серверов а не переписыванием и оптимизациями в режиме аврала  

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


Насчет описанной схемы, у меня есть замечание: если точка входа (фронт-контроллер) будет "смотреть" куда кого посылать в memcache, то пусть мемкеш будет на этом же сервере, так не будет лишних задержек, и если фронт только распределяет запросы (и не делает сложных пре-обработок или фильтраций) то он будет относительно свободным, а на сервере СУБД и так будет "жарко". Также нужно учитывать, что мемкеш, если я не ошибаюсь хранит данные только в RAM и при падении/выключении все будет потеряно, нужно ли против этого страховаться? (знаю точно, что Redis, например, тоже предоставляет key-value хранилище в памяти но также умеет сохранять на диск данные).

Насчет производительности мемкеш - 400 запросов можно даже не парится, через мемекш тысячи а то и десятки тысяч запросов гоняют   

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

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

Насчет того, как быстрее пересылать запросы исполнителям - тут дано мало инфы, трудно давать оценку, но в любом случае лучше сделать имитацию и перепробовать несколько вариантов (+ нужно реализацию "транспорта" скрывать от всего остального - реализовать в виде такой сущности, которая только умеет посылать/принимать сообщения , как она это делает, остальных не касается, тогда при неодбходимости можно будет, не меняя остального кода, заменять сам трансморт, оставляя неизменным интерфейс). 

Еще добавлю, как вариант, в качестве распределителя использовать обратный прокси  - тот же apache в режиме прокси или nginx, еще есть varnish, у которого можно задавать очень сложные правила распределения.