Распределённые системы
Распределённая система — та, чьи части работают на разных машинах и общаются через сеть, которая медленна, может терять сообщения и может расколоться надвое. Задача аналитика редко в том, чтобы построить такую систему с нуля, — она в том, чтобы описать, как части масштабируются, обмениваются данными и продолжают работать при сбое, и затем защитить эти компромиссы в нефункциональных требованиях. Ошибитесь в модели — и пообещаете стейкхолдеру то, что запрещает теорема CAP, или заложите повтор, тихо списывающий с клиента дважды.
Тема идёт от хранилища наружу. Сначала — как масштабируется база: реплики для чтения, шардирование и выбор между консистентностью и доступностью. Затем — как сервисы надёжно обмениваются сообщениями: очереди, логи, гарантии доставки, идемпотентность. Затем — транспорты, которые несут вызовы: REST, gRPC, GraphQL, WebSockets. И наконец — как всё это спроектировано, чтобы продолжать обслуживать при падении части. Заранее назовём ловушки, на которых заканчиваются собеседования: считать exactly-once настройкой брокера, ждать всех трёх гарантий CAP разом, повторять неидемпотентную операцию.
Карта темы
- Масштабирование БД — вертикальное против горизонтального, реплики для чтения, шардирование и выбор ключа, синхронная и асинхронная репликация, кэширование и CQRS,
CAPдля хранилища. - Надёжность сообщений — очередь против лога, гарантии доставки, упорядочивание внутри партиции, consumer group и оффсеты, паттерн outbox, dead-letter queue, отставание потребителя.
- Realtime и RPC — синхронно против асинхронно, REST против gRPC против GraphQL, WebSockets/SSE/long-polling, повторы и идемпотентность, таймауты и circuit breaker, версионирование, заблуждения о распределённых вычислениях.
- Устойчивость — повторы с backoff и jitter, circuit breaker, bulkhead, таймауты, плавная деградация, health-check, резервирование, доступность против надёжности.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Обещать консистентность, доступность и устойчивость к разбиению разом | Описано невозможное хранилище; при разбиении CAP заставляет выбирать |
| Считать exactly-once флагом брокера | Дубли на проде; сквозная доставка требует at-least-once плюс идемпотентность |
| Повторять неидемпотентную запись | Повтор платежа списывает дважды |
| Ждать упорядочивания по всему топику | Kafka упорядочивает только внутри партиции, по ключу |
| Ждать, что синхронный вызов всегда ответит | Он может истечь по таймауту с неизвестным исходом; сеть не надёжна |
| Добавлять шарды, чтобы убрать hotspot | Перекошенный ключ всё равно шлёт тяжёлого клиента в один шард |
Значение для собеседований
Вопросы про распределённые системы проверяют, умеете ли вы точно рассуждать о масштабе и отказах, а не сыпать модными словами. Кандидат, который говорит «при разбиении хранилище держит либо консистентность, либо доступность, но не обе — для оформления заказа я выберу CP и обосную это в бизнес-терминах», сразу опережает того, кто перечисляет «Kafka, Redis, микросервисы».
Что обычно проверяют:
- Где масштабируется база и чем
CAPзаставляет жертвовать при разбиении. - Какую гарантию доставки реально даёт брокер и почему exactly-once — не флаг.
- Когда предпочесть синхронный RPC асинхронному обмену и какой вызов безопасно повторять.
- Какие паттерны устойчивости не дают одному сбою каскадировать и чем доступность отличается от надёжности.
Типичный неверный ответ: «возьмём брокер с exactly-once, и сообщения не потеряются и не задублируются». На деле exactly-once держится только внутри собственных транзакций брокера; как только потребитель пишет во внешнюю систему, он снова в at-least-once, а корректность даёт идемпотентный потребитель, а не настройка.