Сохранение работоспособности приложения при отказе кэша

Введение

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

Сначала пройдите Add a Cache to a Product Lookup. Эта новая VM предоставляет собственные приложение, DynamoDB и Valkey. Используйте Terminal и AWS View. Подготовленный контроль сбоя приостанавливает только процесс кэша этой работы; создавать инструмент внесения сбоев не нужно.

Связь с сертификацией

Наблюдение реального тайм-аута

Тайм-аут ограничивает ожидание приложения. Приостановленный процесс сохраняет endpoint, но не отвечает. Это отличается от отсутствующего ключа.

Проверьте идентификацию и конфигурацию:

cd /home/labex/project
aws sts \
  get-caller-identity
cat app.json

ARN оканчивается на labex-ca03-operator. Начальные настройки: timeout_seconds: 2, fallback_on_error: false. Дважды запросите товар при исправном кэше:

curl -sS http://127.0.0.1:8080/api/products/101
curl -sS http://127.0.0.1:8080/api/products/101

Первое чтение использует источник, второе — кэш. Активируйте подготовленный сбой:

curl -sS -X POST \
  -H 'Content-Type: application/json' \
  --data '{"action":"pause"}' \
  http://127.0.0.1:8080/api/fault

Запросите товар с выводом HTTP-статуса:

curl -sS -w '\nHTTP %{http_code}\n' \
  http://127.0.0.1:8080/api/products/101

Ошибка преднамеренная: примерно через две секунды приложение возвращает HTTP 503 и failure: TimeoutError, хотя база содержит товар. Отказ кэша не должен автоматически отключать каталог.

Ограничение ожидания и обращение к источнику

Fallback — намеренный альтернативный путь после ошибки кэша. Обычный промах означает лишь отсутствие копии.

Для контролируемого упражнения установите 0.2 секунды и включите fallback:

jq '.timeout_seconds = 0.2 | .fallback_on_error = true' \
  app.json > app.next.json
mv app.next.json app.json

Оставьте кэш приостановленным, запросите товар и выведите длительность:

curl -sS -w '\nHTTP %{http_code}; elapsed %{time_total}s\n' \
  http://127.0.0.1:8080/api/products/101

HTTP 200 содержит актуальные 20.00, served_from: source, cache_error: TimeoutError. Ожидание кэша теперь около 0.2 секунды. Каждый запрос при сбое добавляет чтение DynamoDB: функциональность сохраняется, но нагрузка на базу растёт.

В AWS View сравните тайм-аут, приостановленное состояние и счётчик. Одна учебная среда не определяет производственный тайм-аут, допустимую нагрузку или гарантии доступности AWS.

Восстановление кэша и попаданий

Исправный кэш и успешный fallback — разные результаты. Возобновите процесс:

curl -sS -X POST \
  -H 'Content-Type: application/json' \
  --data '{"action":"resume"}' \
  http://127.0.0.1:8080/api/fault

Дважды запросите товар:

curl -sS http://127.0.0.1:8080/api/products/101
curl -sS http://127.0.0.1:8080/api/products/101

Наблюдайте served_from: cache, cache_error: null. Если исходный TTL истёк, первый запрос заполнит ключ из базы, следующий попадёт в кэш. При последовательных попаданиях счётчик базы перестаёт расти.

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

Итоги

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

Подробнее см. в документации AWS: Выбор тайм-аутов клиента под рабочую нагрузку.