Кэширование, очереди и фоновые задачи — бесплатный тест онлайн

Вопрос 1 из 30

Что такое cache-aside?

function profile(int $id, Cache $cache, UserRepository $users): User
{
    $key = "profile:$id";
    $user = $cache->get($key);
    if ($user === null) {
        $user = $users->get($id);
        $cache->set($key, $user, 300);
    }
    return $user;
}

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

Вопрос 2 из 30

Почему нельзя считать кэш источником истины без специального дизайна?

$user = $repository->get($id);
$cache->set("user:$id", $user, 60);

TTL запрещает чтение Кэш всегда readonly Redis не хранит строки Запись может истечь или быть вытеснена PHP очищает кэш каждый echo

Вопрос 3 из 30

Что такое cache stampede?

$value = $cache->get($key);
if ($value === null && $lock->acquire("rebuild:$key", 10)) {
    try {
        $value = rebuildExpensiveValue();
        $cache->set($key, $value, 300);
    } finally {
        $lock->release("rebuild:$key");
    }
}

Ключ истекает, но старое значение остаётся доступным до ручного удаления Одновременный промах и пересчёт множества запросов Один запрос последовательно читает несколько связанных ключей Разные процессы создают ключи с неодинаковым порядком полей Кэш возвращает зашифрованное значение, которое приходится пересчитывать

Вопрос 4 из 30

Что неверно в ключе profile:42 для локализованного профиля?

Не учтена локаль и, возможно, версия представления Ключ слишком короткий и обязательно столкнётся с записью другого типа Не учтён идентификатор пользователя, хотя профиль никогда не бывает общим Числовой идентификатор нельзя использовать без предварительного хеширования Двоеточие усложняет чтение ключа, поэтому его следует заменить подчёркиванием

Вопрос 5 из 30

Как избежать вечного одинакового истечения тысяч ключей?

Поставить TTL=0 всем Добавить случайный jitter к TTL Использовать один общий ключ Удалять ключи при каждом чтении Увеличить PHP memory_limit

Вопрос 6 из 30

Что должно быть в сообщении задания?

final readonly class GenerateInvoice
{
    public function __construct(
        public int $invoiceId,
        public string $operationId,
    ) {}
}

Полный снимок пользовательской сессии и текущего HTTP-запроса Замыкание, которое сохраняет контекст producer и выполняется на worker Открытое соединение с базой, чтобы worker не создавал его повторно Сериализованный объект сервиса вместе со всеми его зависимостями Минимальные сериализуемые данные и идентификаторы

Вопрос 7 из 30

Когда producer может считать сообщение надёжно поставленным?

$pdo->beginTransaction();
$outbox->add($event);
$orders->save($order);
$pdo->commit();

Только после того, как worker успешно выполнит задание и отправит результат Сразу после создания PHP-объекта сообщения, ещё до обращения к брокеру После записи строки «queued» в журнал независимо от ответа транспорта После подтверждения брокера или транзакционной записи После завершения сетевого вызова без проверки подтверждения или транзакции

Вопрос 8 из 30

Что означает visibility timeout?

$message = $queue->reserve(visibilityTimeout: 60);
try {
    handle($message);
    $queue->ack($message);
} catch (Throwable $error) {
    $queue->releaseAfter($message, 30);
}

Срок хранения результата задания в кэше после успешного выполнения Пауза между повторными попытками после временной ошибки обработчика Интервал, в течение которого producer ждёт подтверждения брокера Максимальное время жизни сообщения в очереди до окончательного удаления Срок сокрытия взятого сообщения до ack или возврата

Вопрос 9 из 30

Почему ack выполняют после успешного эффекта?

Ack нужен только для сообщений, завершившихся ошибкой и отправленных в DLQ Ack запускает обработчик повторно, если внешний эффект вернул пустой ответ До подтверждения worker не имеет доступа к payload и не может выполнить действие Ранний ack потеряет задание при падении до выполнения Подтверждение до эффекта безопасно, если handler объявлен идемпотентным

Вопрос 10 из 30

Как graceful shutdown помогает worker?

Завершить текущий процесс немедленно, вернув взятое сообщение без cleanup Перезапустить базу и брокер перед остановкой текущего worker Не брать новые задания и корректно завершить текущее Удалить очередь после завершения задания, чтобы не осталось старых сообщений Сбросить счётчики retry всех сообщений, чтобы новый worker начал с нуля

Вопрос 11 из 30

Что значит идемпотентный handler?

function handle(PaymentRequested $message, PaymentStore $store): void
{
    if ($store->exists($message->operationId)) {
        return;
    }
    $store->createOnce($message->operationId, $message->amount);
}

Повтор сообщения не создаёт второго результата Handler гарантированно будет физически вызван брокером ровно один раз При повторе handler пропускает все проверки и сразу отправляет ack Идемпотентность означает, что handler никогда не выбрасывает исключений Повтор допустим только для операций чтения, которые не используют хранилище

Вопрос 12 из 30

Как защитить создание выплаты?

$stmt = $pdo->prepare(
    'INSERT INTO payouts (operation_id, amount) VALUES (?, ?)'
);
$stmt->execute([$operationId, $amount]);

Хранить обработанные operation_id только в памяти одного worker Считать ack доказательством отсутствия повторной доставки сообщения Создавать новый operation_id при каждой повторной попытке того же сообщения Уникальный operation_id в базе и атомарная запись результата Сначала проверить существование выплаты отдельным SELECT, затем вставить без ограничения

Вопрос 13 из 30

Почему SELECT «ещё не обработано» затем INSERT без ограничения недостаточен?

$exists = $pdo->prepare('SELECT 1 FROM payouts WHERE operation_id = ?');
$exists->execute([$operationId]);
if (!$exists->fetchColumn()) {
    $pdo->prepare('INSERT INTO payouts VALUES (?, ?)')
        ->execute([$operationId, $amount]);
}

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

Вопрос 14 из 30

Что делать при неизвестном исходе внешнего API?

Создавать новый idempotency key при каждом retry после timeout Считать любой timeout окончательным отказом без сверки статуса Отправить два параллельных запроса с разными ключами и принять первый ответ Удалить локальную запись операции и начать новый платёж с другим id Повторять с тем же idempotency key или сверять статус операции

Вопрос 15 из 30

Какая операция естественно идемпотентна?

Отправить письмо Установить статус в заданное значение Создать новую строку без ключа Увеличить счётчик Прибавить 100 к балансу

Вопрос 16 из 30

Что означает at-least-once?

$message = $broker->receive();
$handler->handle($message);
$broker->ack($message);

Очередь не требует ack Сообщение может никогда не прийти Worker выполняет два job одновременно Доставка не теряется, но возможны повторы Доставка строго один раз без условий

Вопрос 17 из 30

Какие ошибки повторять?

try {
    $api->send($request);
} catch (TimeoutException|ServiceUnavailable $error) {
    $queue->retryWithBackoff($message);
} catch (InvalidPayload $error) {
    $queue->reject($message);
}

Синтаксическая ошибка кода Ошибка схемы payload Нарушение инварианта данных Временные ошибки — с ограниченным backoff Запрещённый адрес email навсегда

Вопрос 18 из 30

Для чего dead-letter queue?

if ($message->attempts >= 5) {
    $deadLetterQueue->publish($message, reason: $lastError::class);
    $queue->ack($message);
}

Повторно запускать сообщения без ограничения числа попыток и анализа причины Изолировать сообщения после исчерпания попыток Ускорять каждое новое задание, минуя обычную очередь и механизм retry Заменять журналирование ошибок worker компактным архивом payload Хранить успешные ответы кэша после истечения их обычного TTL

Вопрос 19 из 30

Почему backoff с jitter лучше фиксированной паузы?

Jitter делает каждую ошибку постоянной, поэтому retry быстрее прекращаются Фиксированная пауза безопаснее: все worker повторяют запрос в предсказуемый момент Backoff с jitter обеспечивает exactly-once без идемпотентности обработчика Случайная задержка шифрует payload и защищает его от других потребителей Jitter не даёт worker повторить запросы одновременно

Вопрос 20 из 30

Что записать в retry metadata?

Случайный новый идентификатор, не связанный с исходным сообщением Число попыток, вид ошибки и время следующего запуска Только отметку failed без класса ошибки и номера попытки Полный payload вместе с токенами, чтобы не искать исходное сообщение Пароль брокера и строку соединения, использованные текущим worker

Вопрос 21 из 30

Как unit-тестировать producer?

$queue = new FakeQueue();
$service = new InvoiceService($queue);
$service->requestInvoice(42);

assert($queue->lastMessage() instanceof GenerateInvoice);
assert($queue->lastMessage()->invoiceId === 42);

Подключаться к рабочему брокеру для каждого unit-теста и очищать очередь вручную Ограничиться проверкой return true, не наблюдая созданное сообщение Подменить тестируемый producer мок-объектом и проверить вызов его же метода Прочитать сообщение из production-очереди после выполнения тестовой команды Fake queue проверяет тип сообщения и payload после команды

Вопрос 22 из 30

Как проверить идемпотентность?

$handler($message);
$handler($message);

assert($payments->countByOperationId($message->operationId) === 1);

На втором вызове создать новый operation_id, сохранив остальные данные Сравнить размер payload до и после сериализации вместо внешнего эффекта Выполнить handler один раз и проверить только отсутствие исключения Повторить вызов с тем же id, но очистить хранилище результатов между попытками Дважды выполнить один operation_id и проверить один эффект

Вопрос 23 из 30

Как тестировать TTL без sleep?

$clock = new FrozenClock('2026-07-14T10:00:00Z');
$cache = new InMemoryCache($clock);
$cache->set('report', $value, 60);
$clock->advance('+61 seconds');
assert($cache->get('report') === null);

Изменять системные часы сервера в процессе теста и возвращать их обратно Использовать реальный sleep на полный срок жизни ключа в каждом запуске CI Сравнивать строковые даты, не выполняя операции чтения и истечения ключа Использовать управляемые Clock и cache fake Отключить expiry в тестовой конфигурации и считать TTL проверенным

Вопрос 24 из 30

Что связывает producer и worker в трассировке?

Размер payload и номер очереди, записанные отдельными событиями Пароль брокера, добавленный в оба журнала для поиска соединения Новый случайный идентификатор на каждом этапе обработки correlation_id и родительский trace context Одинаковое имя PHP-процесса на producer и worker

Вопрос 25 из 30

Как воспроизвести падение после внешнего эффекта до ack?

Отключить исключения, чтобы падение превратилось в успешный результат Выполнить эффект, упасть до ack и повторить сообщение Подтвердить сообщение до внешнего эффекта и затем искусственно завершить worker Повторить сообщение с новым operation_id, чтобы избежать второго эффекта Удалить очередь после первого вызова и проверить отсутствие повторной доставки

Вопрос 26 из 30

Почему не стоит класть access token в payload?

$queue->publish([
    'user_id' => $userId,
    'access_token' => $accessToken,
]);

Короткоживущий токен гарантированно истечёт до любого запуска worker Брокер автоматически преобразует секрет в SQL и теряет исходное значение Токен надолго останется в очереди, DLQ или журналах Токен нельзя сериализовать стандартными форматами сообщения Worker принимает только числовые идентификаторы и не умеет читать строки

Вопрос 27 из 30

Как выпускать новую схему сообщения?

$queue->publish([
    'type' => 'InvoiceRequested',
    'version' => 2,
    'invoice_id' => $invoiceId,
    'locale' => $locale,
]);

Поменять класс без version Остановить все worker навсегда Очистить очередь Сначала producer с обязательным новым полем Сначала совместимые consumers, затем новый producer

Вопрос 28 из 30

Какие метрики важны?

$metrics->gauge('queue_oldest_message_seconds', $queue->oldestAge());
$metrics->counter('queue_retry_total')->add($retryCount);
$metrics->counter('queue_dead_letter_total')->add($deadLetterCount);
$metrics->counter('queue_duplicate_total')->add($duplicateCount);

Общий объём памяти процесса без связи с очередью и временем обработки Количество запущенных worker без пропускной способности и backlog Возраст очереди, задержка, retry, DLQ и дубли Только число обработанных сообщений без возраста и времени ожидания Средний размер payload без ошибок, повторов и состояния DLQ

Вопрос 29 из 30

Что делать worker при SIGTERM?

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

Вопрос 30 из 30

Как ограничить права worker?

Доступ лишь к нужным очередям, таблицам и операциям Запускать от имени web-пользователя с полными правами Использовать root для удобства Дать все секреты всем job Хранить ключи в payload