Memcached для страниц, Redis для lock
В стеке уже было два хранилища в памяти. У каждого теперь одна работа. HTML живёт в Memcached. Очереди, сессии и lock на пересборку живут в Redis.
CACHE_STORE смотрел в Memcached. QUEUE_CONNECTION и SESSION_DRIVER смотрели в Redis. Если считать их взаимозаменяемыми, блобы страниц смешиваются с reserved job в одной политике вытеснения. Когда Redis упирается в maxmemory, список новостей и lock Horizon могут уйти вместе. Это stampede и застрявшая очередь в один день.
Memcached быстр на get/set HTML и плох на lock. GET с промахом не обещает, что пересобирать будет один вызывающий. Redis обещает. SET key NX EX 5 это lock с TTL, и тот же инстанс уже крутит очередь.
Путь пересборки
При промахе воркер берёт lock в Redis. Если взял, читает MySQL, пишет Memcached, снимает lock. Если нет, отдаёт предыдущий HTML из парного ключа, который живёт до следующей успешной записи. Две секунды устаревшего HTML лучше стада запросов списка.
Ключи кэша несут ресурс, локаль и сегмент версии. Инкремент версии сбрасывает группу без удаления по маске. Публичные списки живут минуты. Всё, что зависит от одной записи, умирает этой записью.
nginx спереди
Анонимные хиты ещё проходят короткий microcache в nginx. Ключ это scheme, host, uri и локаль. Запросы с auth_token этот кэш обходят, поэтому вошедший пользователь не получает публичный фрагмент.
Разделение теперь правило этого сайта. Новое кэшированное чтение получает Memcached для блоба и Redis для lock. Redis не второе хранилище страниц. Memcached не хранилище сессий. В этом и обновление.