proxy cache stampede

[Gena Makhomed]

On 23.09.2011 2:41, Maxim Dounin wrote:

> Собственно, limit_req/limit_conn именно на rbtree и работают. И
> там не "пяток переменных", там ограничения по произвольному ключу.

> С shmem совсем другая проблема: нет нормального способа быстро и с
> малыми затратами сообщать в соседние воркеры о новых событиях
> (i.e. "файл такой-то появился наконец в кеше, забирайте кому
> надо").

но ведь кроме shmem есть ведь и другие способы IPC, например, tcp/ip.

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

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

затраты вроде бы небольшие. по крайней мере, меньше, чем в случае,
когда каждый worker будет тянуть с backend`а копию большого файла.

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

-- 
Best regards,
  Gena