Strange proxy или неправильное кэширование.

Любое кэширование это спор между выдачей реальных данных и выдачей немного устаревших данных. Если выдавать реальные данные то мы тратим ресурсы на получение результата, который уже был ранее посчитан и выдачей немного старых данных. Пользователь получит данные созданные 5 минут назад или полчаса назад - так ли это существенно? Иногда да, иногда нет.. Но не в этом суть - метод определения нужно ли запрашивать заново результат или подойдет уже закешированный - сейчас (для стандартного протокола кэширования http) - может указывать время которое можно считать результат валидным после запроса и дает возможность уточнить валидны ли данные в кэше (если нет получить все данные). Как следствие - прокси вне зависимости от загруженности ресурсов (пропускной канал и сервер) будет спрашивать: а валидны ли данные?

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

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

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