[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-arkhitektura-prilozheniy-chto-takoe-saga-pattern-v-raspredelyonnykh-sistemakh":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":20,"progress":21,"seo":22},146,"chto-takoe-saga-pattern-v-raspredelyonnykh-sistemakh",3,"arkhitektura-prilozheniy","Архитектура приложений","🏗️","Что такое Saga-паттерн в распределённых системах?","Saga -- паттерн управления распределёнными транзакциями, при котором длинная бизнес-транзакция разбивается на последовательность локальных транзакций. Каждая локальная транзакция обновляет данные в своём сервисе и публикует событие, запускающее следующий шаг; при ошибке выполняются компенсирующие транзакции для отмены уже выполненных шагов. Это как бронирование путёвки: если отель забронирован, но билеты на самолёт закончились -- отменяем бронь отеля.\n\n### Почему нужна Saga\n\nВ микросервисной архитектуре каждый сервис имеет свою БД. Обычная ACID-транзакция через несколько БД невозможна (или крайне дорогая -- двухфазный коммит, 2PC). Saga обеспечивает согласованность в конечном счёте (eventual consistency).\n\n### Пример: перевод между счетами в разных сервисах\n\n\u003Cdetails>\u003Csummary>Пример кода\u003C\u002Fsummary>\n\n```\nУспешный сценарий:\n\n  Сервис Платежей           Сервис Счетов         Сервис Уведомлений\n       │                         │                        │\n  1. Создать платёж (PENDING)    │                        │\n       │────── DebitAccount ────▶│                        │\n       │                    2. Списать со счёта           │\n       │◀──── AccountDebited ────│                        │\n  3. Подтвердить платёж          │                        │\n       │─── PaymentCompleted ───▶│───── Notify ──────────▶│\n       │                         │               4. Уведомить клиента\n\nОшибка на шаге 2 (недостаточно средств):\n\n  Сервис Платежей           Сервис Счетов\n       │                         │\n  1. Создать платёж (PENDING)    │\n       │────── DebitAccount ────▶│\n       │                    2. ОШИБКА: недостаточно средств\n       │◀──── DebitFailed ───────│\n  3. Компенсация: отменить платёж (CANCELLED)\n```\n\n\u003C\u002Fdetails>\n\n### Два подхода к реализации\n\n### Оркестрация (Orchestration)\n\nЦентральный Saga Orchestrator управляет последовательностью шагов. Он знает весь процесс и явно вызывает каждый шаг:\n\n\u003Cdetails>\u003Csummary>Пример кода\u003C\u002Fsummary>\n\n```java\n@Service\npublic class TransferSagaOrchestrator {\n\n    public void execute(TransferCommand cmd) {\n        try {\n            \u002F\u002F Шаг 1: списание\n            accountService.debit(cmd.getFromAccountId(), cmd.getAmount());\n            \u002F\u002F Шаг 2: зачисление\n            accountService.credit(cmd.getToAccountId(), cmd.getAmount());\n            \u002F\u002F Шаг 3: уведомление\n            notificationService.notify(cmd);\n        } catch (CreditFailedException e) {\n            \u002F\u002F Компенсация шага 1\n            accountService.reverseDebit(cmd.getFromAccountId(), cmd.getAmount());\n            throw new TransferFailedException(e);\n        }\n    }\n}\n```\n\n\u003C\u002Fdetails>\n\n### Хореография (Choreography)\n\nКаждый сервис слушает события и сам решает, что делать. Нет центрального координатора:\n\n```\nPaymentCreated → Сервис Счетов слушает → списывает → AccountDebited\nAccountDebited → Сервис Платежей слушает → подтверждает → PaymentCompleted\nPaymentCompleted → Сервис Уведомлений слушает → уведомляет\n```\n\n### Сравнение подходов\n\n| Аспект | Оркестрация | Хореография |\n|--------|-------------|-------------|\n| Управление | Центральный координатор | Децентрализованное |\n| Сложность | Логика в одном месте | Размазана по сервисам |\n| Связанность | Orchestrator знает все шаги | Сервисы знают только свои события |\n| Отладка | Проще (один поток) | Сложнее (нужна распределённая трассировка) |\n| Масштабирование | Orchestrator -- потенциальное узкое место | Лучше масштабируется |\n\n### Когда что выбирать\n\n- **Оркестрация** предпочтительна, когда процесс линейный, шагов немного (3-5), и важна наглядность потока. Проще для отладки и мониторинга.\n- **Хореография** предпочтительна, когда много независимых реакций на одно событие, и сервисы должны быть максимально автономны.\n\n### Итог\n\nSaga -- обязательный паттерн для распределённых систем, где нужна согласованность данных между сервисами. Ключевое правило: каждый шаг саги должен иметь компенсирующую операцию. Если шаг нельзя компенсировать (например, отправка email), его ставят последним в цепочке.\n\n> **На собеседовании:** Интервьюер ожидает знание обоих подходов (оркестрация vs хореография) и понимание компенсирующих транзакций. Частая ошибка -- не упоминать eventual consistency и предполагать, что Saga обеспечивает ACID-гарантии.","","senior",[15,16,17,18,19],"distributed-systems","transactions","saga","architecture","microservices",[],null,{"title":23,"description":24,"ogTitle":23,"ogDescription":25,"keywords":26,"schemaAnswer":34,"featuredSnippetReady":35},"Saga-паттерн: распределённые транзакции в микросервисах — Gymterview","Что такое Saga-паттерн? Оркестрация vs хореография, компенсирующие транзакции, eventual consistency. Примеры реализации на Java для микросервисов.","Разбор Saga-паттерна: оркестрация и хореография, компенсирующие транзакции в распределённых системах.",[27,28,29,30,31,32,33],"Saga паттерн","распределённые транзакции","оркестрация","хореография","компенсирующие транзакции","eventual consistency","микросервисы","Saga — паттерн управления распределёнными транзакциями, при котором длинная бизнес-транзакция разбивается на последовательность локальных транзакций. Каждая обновляет данные в своём сервисе и публикует событие для следующего шага, а при ошибке выполняются компенсирующие транзакции. Два подхода: оркестрация (центральный координатор управляет шагами) и хореография (каждый сервис слушает события и сам решает, что делать). Saga обеспечивает eventual consistency в микросервисной архитектуре, где ACID-транзакция через несколько БД невозможна.",true]