[quote ДохтаР]sphinx_mvпропущено...

Нормальная и правильная постановка задачи для автоматического контроля ДДОС .
Отсуюда и разный алгоритм , что бы ненапрягаясь отдавать дедосящим факоФФ или редирект наюх
ничего другого не делая.

Stinger03, угадал ?
Нет, совсем не угадал. К ддосу мы не имем никакого отношения, но сами испытывали что это такое. Так что тех кто занимается - очень-очень сильно не любим.
Под задачей сейчас стоит несколько серверов и так - само-собой ни один сервер в одиночку это не потянет.
И падение системы конечно недопустимо ни на минуту - ибо запросы идут, деньги теряются.
пока сделали подпорку через мемкешед как предлагали в самом начале. кой-как это работает :)
само-собой конечно это верно только для одного сервера в ферме, но пока устраивает хотя бы так.

Сейчас перевалило за 200кк входящих запросов в сутки (соответственно это около 500-600кк исходящих получается).

По поводу redis - сайчас нам мемкешед лучше подходит так как получается быстрее.

Теперь стал вопрос в обработке более подробной информации по трафику и соответсвенно нагрузка продолжает расти. К тому же сервера для устойчивости разнесены по разным ДЦ, поэтому задача имеет продолжение.

Так что кто обсуждает - всем спасибо большое. Помогаете смотреть на задачу со стороны и смотреть те варианты над которыми не задумывались или не знали.

Не вникнув в суть задачи делать заявления о п#$це по меньшей мере не красиво.
Тупой прокси-сервер ляжет через 0,1 секунду после включения и утянет за собой всю структуру.
За вчера обработано 1 017 929 064 запросов. Это где то 12к входящих запросов в секунду. И обрабатывать их надо в рилтайме. Перл/пхп банально не имеют многопоточности и впадают в ступор тут же, точнее сказать мгновенно, как собственно и студенты которые просто не поймут что делать.
Собственно по сути вопрос не решился - точность определения повторов сейчас страдает, но пока в допустимых пределах.

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

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

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

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

у клиентов нету куков :)
это не конечные пользователи

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