Высоко-нагруженные кластерные решения и хостинг тяжёлых проектов

суть в конкретном проекте и его бюджете.

kostich, не поспоришь :)

а будующее веб за инфинибенд. софт то еще лет пять раскачивать будут. мы в следующем году инвестируем в разработки под инфинибенд для решений по защите от ддос и попутно cdn там разгребаем + фреймворк под пехапе с dlm и прочими ништяками. и всё на фоне того что субд люди совсем не по назначению используют.

distributed lock ?

да, но это больше к фреймворку и уебсерверу чем к пехапе. там много идей, в т.ч. и стек полуобщий... т.е. ради возможности передачи сокета произвольной нодой на произвольную. сейчас же ресурсы хардварные утилизируются очень расточительно... балансеры как прокси работают, а надо всего-то... т.е. ставят люди там три-четыре ноды и сверху два балансера. зачем? ядер в нодах как обычно вагон незадействанный. я бы еще приемлил это, если бы балансеры на l3 уровне хтпп это разгребали и через них проходил бы только входящий трафик... а исходящий бы сразу с нод шел.

Ого, сколько людей оказывается бьются над проблемой. Искренне рад что не я один вынужден был изобретать велосипеды.

Поговорим о куках, сессиях и кешере.

Суть кешера проста и незамысловата - отдать динамический контент который не изменился с последнего запроса к странице по данному адресу.

Использование куков и сессий, в большинстве случаев, направлено на идентификацию пользователя для статистических или аунтификационных действий.

Я этих два процесса разделяю. Данные на которые влияет аунтификация не попадают в кешер.

Технологических решений тут несколько, и они общеизвестны. Насколько снижается нагрузка на ситему при использовании кешера зависит от конкретного проекта. В медийных проектах эта снижение может доходить до 70%. В системах знакомств, например, использование кешера практически бессмысленно.

Что же касается отдачи статического контента то один сервер из топовой линейки пролиантов способен отдавать 4+ Гигабит контента(2 гигабита тестировали сами, про 4 можно экстраполировать) и да, этого теоретически хватит, что бы обеспечить работоспособность при названных мной объёмах.

Это если рассуждать о сферических конях в вакуме и рассматривать работоспособность сервера в отрыве от комплекса в целом. И мы именно так же и рассуждали.

На практике это сервер завалился в течении 30 минут после публикации о смерти Турчинского. Был проведён анализ, разбор полётов, наказание виновных и разработано решение, которое совершенно спокойно выдержало пик при последних взрывах в метро.

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