kpuzuc

Когда-то передо мной вставала подобная задача. Гляньте мою статью по этому поводу.
habrahabr.ru/post/106311/

if (confirm('У Вас установлен скайп?')) {
    ...
}

:)

HL это на самом деле задача по оптимизации. В первую очередь надо уменьшить времена формирования ответа, времена загрузки на клиенте, что достигается оптимизацией самого приложения (профилирование, склеивания запросов и разнесения контента) и и потом уже кеширования, которое бывает разное — тупое (ставим nginx ) или структурное ( разбиваем на блоки, которые формируем и кладем например в memcached ), управляемое ( содержимое меняется при необходимости ) и нет ( по таймауту ). Для кеширования может понадобиться изменять приложение ( обновления в данных ) или адаптировать кеширование ( сброс кеша или его игнорирование по кукам например )
Дальше, если сервер уже не справляется в одиночку или надо HA, переходим к горизонтальному масштабированию. И начинать надо с того что запросы должны быть атомарными — любые состояния, типа сессий, усложнят масштабирование ( придется расшаривать сессии на кластер или привязывать пользователя к серверу по ip например, что легко если шардинг, но HA страдает ). Какая база ( SQL или NoSQL. не говоря уже об названии ) или кластер — зависит в первую очередь от приложения, а не от моды или комментов на хабре. Лучше жить на MySQL, тем более что Percona+Galera очень даже неплохи, если вы его хорошо знаете, чем окунаться в проблемы незнакомого сервера на production. Опять же конкретная технология должна решать конкретные проблемы, которые определяются, исходя из архитектуры приложения в первую очередь. Ну и пробовать, экспериментировать.

Вы очень поверхностно описали вопрос.
Nginx + php-fpm очень рекомендую. Но самая главная замарочка — репликация/шардинг базы данных. Рекомендую читать не только на официальных сайтах баз данных (там всегда всё «быстро надёжно автоматически»), но и на serverfault, news.ycombinator.com. MySQL очень плоха в репликации, MongoDB тоже имеет с этим косяки. Про PostgreSQL хорошо отзываются (даже master-master есть), но я сам не пробовал на практике. Пробовал Couchbase — прекрасно кластеризуется, даже ребёнок справится, умеет кросс-датацентр репликацию. Но это NoSQL — бд нужно выбирать по задаче. Если больше подходит именно rdbms, то лучше PostgreSQL, imho :)
Ещё вам понадобится кластеризация кэша — как варианты: Amazon ElastiCache, Couchbase, Riak. Через несколько месяцев будет Redis Cluster :)

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

Ещё рекомендую сделать api для внутреннего взаимодействия приложений, чтобы они не общались дру с другом, изменяя значения в «чужих» базах или таблицах.

Это вы, получается, вопрос про горизонтальное масштабирование задали.
Серверы приложений масштабируются с помощью балансировщика(HAproxy да или сам nginx). Они хранят только исполняемые файлы (грубо, говоря, их содержимое одинаково в любой момент времени и не содержит какого-нибудь UG-контента), поэтому тут зеркалирования данных не нужно — логгирование идет в бд или какой-нибудь централизованный сервис, статика в CDN. Серверы БД — репликация/шардинг, тут уже в зависимости от конкретной используемой СУБД, в той же Монго все из коробки, в PostgreSQL — PL/Proxy, PgPool.
Самое главное — максимально разделить и обособить части приложения, если оно прямо к себе на хост пишет логи, заливает юзерпики и еще что-то такое делает — будет весьма тяжело это все масштабировать потом.

Помимо использования memcached очень помогает отправлять «тяжёлые» задачи в очередь. например, rabbitMq

Наверно хороший способ узнать это — изучить архитектуру существующих highload проектов. Держите ссылку: www.insight-it.ru/highload/

От себя добавлю, что практически всегда необходимо предусмотреть возможность масштабирования в самом приложении (т.е. переписывать код). Нельзя просто так взять, поставить нгинкс, поменять MySQL на mongo и получить хайлоад проект (более того, поменяв mysql на mongo можно получить еще больше проблем).

Была похожая задача.

Решили просто периодической (каждую минуту) выгрузкой аккаунтов с основного сайта (Symfony 2) в базу форума (FluxBB). В последнем только поменяли алгоритм шифрования пароля (пара строчек).

Проблему требовалось решить быстро, данное решение в нашем случае оказалось оптимальным по соотношению время/качество.

Так к слову, писал месяц назад в ТП Hetzner на английском, ответили на русском!

Какую поло купить для программирования? Присмотрел Ralph Lauren, но говорят php лучше в Lacoste идет.

Эммм. В чем проблема, господа? Уверены в кодировке — вперед)

php -r 'var_dump(json_encode(«тест»));'
string(26) ""\u0442\u0435\u0441\u0442""

php -r 'var_dump(json_encode(«тест», JSON_UNESCAPED_UNICODE));'
string(10) "«тест»"