сеньорчикОткрыть в Telegram
← все вопросывопросы для собеседований · Распределённые системы

Вопросы по распределённым системам на собеседовании

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

56 вопросов в банке·5 подтем·ниже разбор 9

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

Примеры вопросов с разбором

  1. #cap_consistency1 / 9
    Что утверждает CAP-теорема?
    A)При сетевом разделении система выбирает между согласованностью и доступностью
    B)Распределённая система при хорошем проектировании обеспечивает согласованность, доступность и устойчивость к разделению разом
    C)Число реплик данных должно быть строго нечётным для корректной работы кластера
    D)Теорема ограничивает латентность системы в зависимости от числа её узлов
    показать ответ и разбор
    +A)При сетевом разделении система выбирает между согласованностью и доступностью

    // разбор: CAP: при сетевом разделении (P) распределённая система не может одновременно давать и согласованность (C — все видят одни и те же свежие данные), и доступность (A — каждый запрос получает ответ). Приходится выбирать: отказать в ответе ради консистентности (CP) или ответить, рискуя устаревшими данными (AP). Без разделения оба свойства достижимы.

  2. #consensus_coordination2 / 9
    Зачем распределённой системе нужен алгоритм консенсуса (например, Raft)?
    A)Чтобы узлы принимали решения независимо, не согласуя их между собой
    B)Согласие узлов о едином значении/порядке при отказах части узлов
    C)Чтобы исключить репликацию данных между узлами системы
    D)Чтобы ускорить одиночные запросы, распараллелив их выполнение сразу по всем узлам кластера
    показать ответ и разбор
    +B)Согласие узлов о едином значении/порядке при отказах части узлов

    // разбор: Консенсус позволяет группе узлов прийти к единому решению (кто лидер, какая следующая запись в реплицированном логе, зафиксирована ли транзакция) даже когда часть узлов падает или сеть подтормаживает. Raft/Paxos гарантируют, что все живые узлы согласуют одну и ту же последовательность решений, пока живо большинство (кворум). На консенсусе строят выбор лидера, реплицированные логи, распределённые блокировки и метаданные кластера (etcd, ZooKeeper).

  3. #partitioning_sharding3 / 9
    Что такое шардирование (sharding)?
    A)Регулярное создание нескольких точных полных копий одной таблицы на разных серверах
    B)Разбиение данных на части (шарды) по разным узлам ради масштаба записи и объёма
    C)Сжатие данных на диске для экономии места в одной большой таблице
    D)Полное дублирование всей базы данных в резервное хранилище раз в сутки
    показать ответ и разбор
    +B)Разбиение данных на части (шарды) по разным узлам ради масштаба записи и объёма

    // разбор: Шардирование — горизонтальное разбиение данных на непересекающиеся части (шарды) по разным узлам, чтобы снять лимит одной машины по объёму и пропускной способности записи. Это не то же, что репликация: шардинг делит данные (масштаб), репликация их копирует (надёжность и масштаб чтения). Часто применяют вместе.

  4. #replication_faults4 / 9
    Зачем нужна репликация данных в распределённой системе?
    A)Чтобы разбить данные на непересекающиеся части по разным узлам
    B)Чтобы удалять устаревшие данные с основного сервера базы данных
    C)Отказоустойчивость и близость к читателю: копии переживут падение узла и разгрузят чтение
    D)Чтобы сжать данные и уменьшить занимаемое ими место на диске
    показать ответ и разбор
    +C)Отказоустойчивость и близость к читателю: копии переживут падение узла и разгрузят чтение

    // разбор: Репликация — хранение копий одних и тех же данных на нескольких узлах. Это даёт отказоустойчивость (упал узел — реплика продолжает), масштаб чтения (запросы распределяются по репликам) и близость к пользователю (реплика в его регионе). Плата — сложность согласованности: копии надо синхронизировать, и возникает лаг. Цель отличается от шардинга, который данные делит.

  5. #storage_internals5 / 9
    Почему БД пишут в write-ahead log (WAL) перед изменением самих данных?
    A)Чтобы экономить место: журнал WAL заменяет собой хранение основных данных таблиц
    B)Сперва в лог → после сбоя по WAL восстановят состояние
    C)Чтобы ускорить чтения: WAL — это кэш часто читаемых страниц данных в памяти
    D)Порядок не важен: данные и журнал можно писать в разной последовательности
    показать ответ и разбор
    +B)Сперва в лог → после сбоя по WAL восстановят состояние

    // разбор: WAL — журнал, куда изменение записывается (и сбрасывается на диск) до того, как применяется к основным данным. Если система падает, при старте она проигрывает WAL: повторяет подтверждённые, но не дозаписанные изменения (redo) и откатывает незавершённые (undo) — так гарантируется durability коммита и целостность без дорогой синхронной записи страниц данных на каждый коммит. WAL также основа репликации (реплики применяют его записи) и CDC (читают WAL). Последовательная запись в лог быстрее случайной записи страниц.

  6. #cap_consistency6 / 9
    Чем отличается выбор CP от AP при сетевом разделении?
    A)Система в режиме CP при разделении жертвует именно согласованностью данных ради доступности, а AP наоборот
    B)CP жертвует доступностью ради согласованности; AP отвечает, рискуя устаревшими данными
    C)CP и AP — это два синонимичных названия одного и того же режима работы
    D)AP отклоняет запросы на обеих сторонах раздела до восстановления связи между узлами
    показать ответ и разбор
    +B)CP жертвует доступностью ради согласованности; AP отвечает, рискуя устаревшими данными

    // разбор: При разделении CP-система предпочитает согласованность: отказывает в операции, если не может гарантировать свежесть данных (нужно для платежей, остатков на складе). AP-система предпочитает доступность: отвечает всегда, но данные могут быть устаревшими (лента соцсети, лайки). Выбор диктует цена ошибки: показать неверный баланс vs показать чуть старый лайк.

  7. #consensus_coordination7 / 9
    Почему распределённой транзакции на два узла нужен two-phase commit (2PC), а не просто два коммита?
    A)Чтобы просто выполнить два коммита побыстрее, распараллелив их между узлами для скорости
    B)Чтобы снять блокировки: 2PC работает без удержания ресурсов участниками
    C)Фаза голосования + фаза коммита дают атомарность обеих сторон
    D)Чтобы один узел мог единолично коммитить за оба, не спрашивая согласия второго участника
    показать ответ и разбор
    +C)Фаза голосования + фаза коммита дают атомарность обеих сторон

    // разбор: Два независимых коммита могут дать частичный результат: один узел зафиксировал, второй упал — рассинхрон. 2PC вводит координатора и две фазы: prepare (все участники готовятся и голосуют «готов/нет», обещая суметь закоммитить) и commit (если все «готов» — координатор велит фиксировать, иначе все откатывают). Так достигается атомарность на нескольких узлах. Цена — блокировки на время протокола и уязвимость к падению координатора (участники зависают in-doubt); отсюда популярность saga как альтернативы.

  8. #partitioning_sharding8 / 9
    Чем hash-партиционирование отличается от range-партиционирования?
    A)Партиционирование hash и по диапазону range — это два совершенно синонимичных названия одного способа
    B)Range распределяет данные равномерно, а hash склонен создавать горячие точки
    C)Hash равномерно размазывает ключи, но ломает диапазонные запросы; range — наоборот
    D)Hash-партиционирование работает с числовыми ключами, а range — с текстовыми
    показать ответ и разбор
    +C)Hash равномерно размазывает ключи, но ломает диапазонные запросы; range — наоборот

    // разбор: Hash-партиционирование берёт хеш ключа — данные ложатся равномерно, но диапазонные запросы (за период) бьют по всем шардам. Range кладёт рядом соседние ключи — диапазонные запросы эффективны, но по «горячему» диапазону (свежие даты) копится нагрузка. Выбор зависит от паттерна запросов: точечные — hash, диапазонные — range.

  9. #replication_faults9 / 9
    Как работает репликация leader-follower (master-replica)?
    A)Записи можно свободно слать в реплику, и они сами договариваются о едином порядке
    B)Реплики равноправны, и выделенного лидера среди них нет
    C)Followers принимают записи, а leader раздаёт данные на чтение
    D)Записи идут в leader и реплицируются на followers; чтение масштабируется по репликам
    показать ответ и разбор
    +D)Записи идут в leader и реплицируются на followers; чтение масштабируется по репликам

    // разбор: В leader-follower все записи идут через одного лидера, который реплицирует изменения на followers; чтение можно распределить по followers, масштабируя нагрузку чтения. Модель проста и избегает конфликтов записи, но у неё есть лаг реплик (чтение с follower может быть устаревшим) и вопрос failover — кого назначить лидером при его падении.

это 9 из 56

Ещё 47 вопросов по теме — в тренажёре, с движком повторения

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

Открыть тренажёрДругие темы

Частые вопросы

куда дальше