Пишу проект на PHP, использую в качестве веб-сервера Apache.. Нужна система способная справиться с очень большим объемом посетителей на сайте. Переписать всё на яву - не предлагайте. Не вижу смысла. Мне кажется, что решения написанные на пхп должны без проблем справляться с любой нагрузкой, если распределить обработку пхп-скриптов по разным серверам (пример: wikipedia). А в Базу данных поставить на отдельном сервере/серверах. 

Т.е. со стороны Базы данны - проблем не предвидится, т.к. есть много хорого зарекомендовавших себя технологий. Интересная сторона PHP. Давайте пообсуждаем, как бороться и распределять нагрузку.

Можно использовать в качестве веб-сервера nginx, но это имхо решение для "бедных", когда нет возможности поставить нужное кол-во серверов.


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

Варианта всего два. Cisco - балансировщик нагрузок, либо грамотная реализация MVC. Других вариантов я не вижу

балансировщик ведь может быть любой.

Wowa, я незнаю других ) 

Вообще то это не совсем вебсервер, а reverse-proxy, собственно то что тебе нужно. reverse-proxy - быстрая штука, распределяющая запросы на целую сетку серверов. Сам он ничего не вычисляет, просто держит/отдаёт статику, которую push'ат сервера на подобии apache.

ок, но как мне кажется самое простое и действенное решение, это распределять загрузку уже на уровне DNS (round robin DNS).

ДНС-сервера будут выдавать случайным образом IP-адрес какого-то веб-сервера. 

А с помощью этой штуки можно управлять распределеним. Например, временно убирать из списка перегруженные сервера.
http://www.math.utah.edu/~pocock/lbnamed.html

Стоило, наверное, посетить HighLoad или, хотя бы, Веборуб, если планировалась такая задача
Вообще, с нуля, на форуме такие вещи не делаются, имхо.
Ну что насоветуют такие советчики, как я? Тут действительно надо общаться со специалистами. 
Насколько я понимаю, тут же все в комплексе. 
отдельно - сервера с динамикой, ngnix + PHP fcgi
отдельно - с картинками, ngnix или что-то ещё легче.
фронтендами(ом?) в Мамбе, насколько мне известно, стоит ngnix
сессии в мемкеше.
вообще, можно посмотреть презентации с ХайЛоада, http://highload1.rutube.ru/
там должны быть, кажется, как раз, схемы.

совместно можно srv - запись использовать !! 

Тогда нужно истинно REST (state-less) сервисы, т.е. никаких PHP сессий. А это значит большую половину нынешнего кода в утиль. Хотя этот форум так разгрузить можно, он сессии свои в базе держит. Также могут быть траблы если целая сеть будет использовать DNS кеш, тогда все ломануться на твою прервую машину и так до обновления кеша...

В самом простейшем случае - отказаться от монструозного апача в пользу "лайти", который имеет встроенный балансировщик.
Подробнее тут.

Подобная проблема уже обсуждалась на форуме неоднократно. И рекомендации приводились (типа папку для хранения сессий разместить на одном из серверов и примонтировать по NFS на все остальные). Думаю, сначала стоит прочитать все, что есть по этому вопросу на форуме и только потом начинать тему с вопросом.

Это сообщение отредактировал(а) FractalizeR - 8.3.2008, 13:37

Вов, чем тебе Nginx не угодил? У нас все проекты им прикрыты как балансером. Статику им же отдаем (картинки, css, js и т.п.). Посещаемость - от 1 млн. до 100 млн. обращений в сутки.

Сервера закрываем CARP-ом.
Сессии в БД или через NFS.
Скрипты либо дублируются по всем серверам, либо опять же доступны через NFS.

Хотя идея с NFS имеет один минус - если сервер отваливается, все процессы обращающиеся туда лочатся, что не очень приятно.

Стартовав эту тему я заблуждался думая. что проблем с Базой Данных не будет. На самом деле это самая серьезная проблема в сильно посещаемых проектах.

Для сессий и кеширования надо использовать memcache запущенный на отдельном(-ых) сервере(-ах). База при определённой нагрузке начнет не справляться с сессиями.
PHP масштабируется очень легко. Хотя бы даже через робин ДНС или nginx

Полнотекстовый поиск по БД - тут Сфинкс подойдет. Также масштабирование не вызовет проблем. 

А вот для базы данных  нужно ставить один Master(операции записи) и несколько Slave-серверов(операции чтения). Использовать репликацию. 

Но при определенной нагрузке, БД все равно не будет выдерживать. Поэтому базу и таблицу придеся сегментировать(прим. разделять на части).
IZ@TOP, у вас применяется сегментирование БД ? Интересно бы знать, когда без него уже не обойтись. При каком объеме данных и при каком кол-ве запросов.

Wowa,  можешь написать какая стоит сейчас архитектура и что используется.
Самому интересно в дальнейшем будущем будет, прошу поделиться идеей.