Redis: кэш, очереди, счётчики

«Один товар стоит 100 в регионе A и 120 в регионе B; выдача разделена по категориям и страницам. Предложи ключи, чтобы ответы не смешивались, и сценарий обновления цены». Попросите таблицу запросов и ожидаемых попаданий. Такой пример проверяет семантику ключа; простая проверка существования записи в Redis не обнаружит ответ, сохранённый для чужого региона.

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

Опишите число параллельных клиентов и допустимость кратковременной выдачи старого значения. Возможны координация обновления, разброс сроков и предварительное восстановление, но каждый вариант имеет свою цену. Для учебного теста сто обращений к одному отсутствующему ключу не должны бесконтрольно запускать сто дорогих запросов. Проверьте также ошибку обновляющего процесса и освобождение права на повторную попытку.

Это требует осознанного разделения требований к сохранности и политике памяти. То, что допустимо вытеснить для каталога, может быть недопустимо для задания очереди. Попросите описать последствия выбранной политики для каждого типа данных. Чат не знает текущей конфигурации сервера; изменение настроек сначала проверяют на стенде, наблюдая ошибки записи, потребление памяти и восстановление после перезапуска.