Кеш вернул старое после обновления
Кеш вернул старое после обновления Коммит завершён, ключ удалён, а кеш снова отдаёт старое. Вымышленный cache-aside: два потока, один ключ; псевдокод: B: CACHE.get(key) // промах B: v = DB.get(key) // версия 7 A: DB.set(key, version=8) // коммит завершён A: CACHE.delete(key) B: CACHE.set(key, v) // снова версия 7 B прочитал старое до коммита A, но записал после удаления ключа. Delete эту запись не запрещает. Развилка: сравните версии в кеше и источнике, найдите автора set и момент чтения. Старое прочитано до коммита и записано после delete? Это показанная гонка. Если нет — проверьте «коммит → delete» и источник чтения. Время set не доказывает свежесть. Ошибка — считать delete гарантией. Повторный delete тоже может пройти до позднего set. Если нужна актуальность чтения после записи, нужен согласованный протокол: например, отметка версии/инвалидации при отсутствующем ключе и атомарные проверка заполнения и запись. Обычный CAS не проверяет актуальность БД. Атомарность кеша не объединяет его с БД в одну транзакцию; полный протокол — отдельная задача. TTL без продления ограничивает срок одного заполнения, не гарантирует свежесть и не предотвращает повторное устаревшее заполнение. Сохраните проверку для практического разбора backend-разработки при подготовке обучения в УЦ ФОРС. #Backend #Кеширование #УЦФОРС VK | Телеграм | Сайт