Перейти к основному содержимому

BASE

BASE (Basically Available, Soft state, Eventually consistent) — подход к проектированию распределённых систем
Жертвует строгой согласованностью (ACID) ради доступности, масштабируемости и гибкости. У систем BASE может не быть четкого состояния, в отличие от ACID

Когда используют​

  • NoSQL-системы (Cassandra, MongoDB, DynamoDB)
  • Высоконагруженные сервисы (соцсети, аналитика)
  • Системы, где важнее скорость ответа и отказоустойчивость, чем мгновенная актуальность данных

Три принципа​

Basically Available (базовая доступность)​

Система всегда отвечает, даже при частичных сбоях
Данные могут быть неактуальными, но запросы не блокируются

Как достигается:

Soft State (гибкое состояние)​

Данные могут меняться со временем без внешних запросов
И могут временно находиться в несогласованном состоянии из-за асинхронных обновлений

  • Асинхронная синхронизация
  • TTL (время жизни данных, например кэш обновляется раз в 5 минут)
  • Фоновые процессы согласования

Eventually Consistent (окончательная согласованность)​

Система придет к согласованности, но не мгновенно

  • Конфликт-разрешающие алгоритмы (Conflict-free Replicated Data Types, Last-Write-Win)
  • Подтверждение записи от большинства узлов (например, в Cassandra)
  • Исправление устаревших данных при последующих чтениях
  • Kafka или RabbitMQ с отложенной синхронизацией

BASE vs ACID vs CAP​

ACID — как банковский перевод: либо деньги ушли и пришли полностью, либо операция отменена
Для систем, где важна точность (платежи, бухгалтерия)

BASE — как почта: письмо точно ушло, но когда дойдёт — неизвестно

БД не может быть и ACID, и BASE одновременно. Это противоположные подходы
Но некоторые гибридные СУБД (например, MongoDB) позволяют гибко настраивать уровень согласованности

  • CAP — определяет фундаментальные ограничения распределённых систем
  • BASE — практический подход в рамках этих ограничений

CAP-теорема говорит, что система может гарантировать только 2 из 3 свойств:

  • Согласованность (Consistency)
  • Доступность (Availability)
  • Устойчивость к разделению (Partition tolerance)

ACID выбирает CP (согласованность + устойчивость)
BASE - AP (доступность + устойчивость)
CA-системы (консистентность и доступность) возможны только в нераспределенных системах

Пример реализации BASE​

Онлайн-магазин с высокой нагрузкой

B: Пользователь добавляет товар в корзину → система сразу подтверждает действие, даже если часть серверов перегружена
Товар мгновенно появляется в корзине у пользователя, но остатки на складе могут обновиться с небольшой задержкой

  • Отправка запроса → API сразу возвращает успех (202 Accepted)

S: Данные о корзине и об остатках лежат в разных сервисах
Если два покупателя одновременно добавляют последний товар → оба увидят его в корзине, но физически доступен только 1

  • Сервис корзин (Redis) временно сохраняет изменения
  • Сервис склада (Kafka + PostgreSQL) асинхронно проверяет остатки

E: Через несколько сек система проверяет остатки и синхронизирует данные

  • Если товара нет, система убирает его из корзины и отправляет уведомление

В ACID система заблокировала бы остатки при добавлении в корзину -> очереди и ошибки под нагрузкой
BASE позволяет сначала принять действие, потом проверить ограничения. Это критично для высоконагруженных сценариев

BASE в EDA (Event-Driven Architecture)​

Возможен из-за асинхронного типа событий

Механизмы реализации​

  1. Event Sourcing (Хранение событий как источника истины)
    Сохраняется вся последовательность событий, а не текущее состояние

Пример: для заказа хранится не просто "статус: оплачен", а цепочка: "создан" → "передан в оплату" → "оплата подтверждена"

  • Можно легко восстанавливать состояние после сбоев и анализировать историю изменений
  • Реализуется через специальные БД (EventStoreDB) или через обычные (Kafka+PostgreSQL)
  1. CQRS (Command Query Responsibility Segregation)
    Разделение на 2 независимых компонента:

Командная часть (Write Model):

  • Принимает команды изменения состояния
  • Генерирует события
  • Оптимизирована для записи

Чтение (Read Model):

  • Строит проекции данных для быстрого чтения
  • Может отставать от командной части (eventual consistency)
  • Оптимизирована под конкретные запросы UI
  1. Saga Pattern (Оркестрация длительных процессов)
    Механизм для управления распределенными транзакциями

Хореография:

  • Каждый сервис самостоятельно реагирует на события
  • Нет центральной точки управления
    Пример: Сервис оплаты сам решает, когда проводить транзакцию после получения OrderCreated

Оркестрация (через центральный координатор):

  • Координатор отправляет команды сервисам
  • Легче отслеживать, но есть зависимость от координатора
  1. Outbox Pattern (Надежная публикация событий)
    Решение проблемы "двойной записи":
  • Сначала изменения сохраняются в локальную БД вместе с событием в таблицу Outbox
  • Отдельный процесс забирает события из Outbox и публикует в брокер
  • Только после успешной публикации событие помечается как отправленное

BASE-транзакционность в EDA​

Напомним, атомарное изменение - операция, которая выполняется как единое целое: либо полностью успешно, либо полностью откатывается, без промежуточных состояний. Ключевое свойство ACID-транзакций.

В BASE-транзакционности:

  • Нет единой блокирующей транзакции
  • Вместо атомарного изменения компромисс: каждый сервис фиксирует его локально, затем согласованность достигается через события
    Это позволяет строить высоконагруженные отказоустойчивые системы

Плюсы и минусы BASE​

Плюсы:

  • Легко добавлять узлы (например, серверы)
  • Система работает при сбоях (YouTube показывает видео при аварии дата-центра)
  • Не нужно ждать подтверждения от всех узлов (лайки в соцсетях ставятся мгновенно)

Минусы:

  • Нужно учитывать временные нестыковки (корзина в интернет-магазине может показывать устаревший остаток)
  • При аварии возможна потеря последних данных (неподтверждённые данные могут исчезнуть)
  • Не подходит для операций, где важна точность

Материалы​

  1. BASE
  2. Как бы я сейчас объяснил молодому себе… зачем существуют требования ACID для баз данных?
  3. Требования ACID. BASE модель. CAP теорема
  4. БАЗОВАЯ модель разработки баз данных
  5. Что такое BASE в разработке баз данных?
  6. NoSQL: что это такое, отличие от других баз данных, BASE
  7. Почему базы данных NoSQL — плохое решение для современных приложений, Архитектура BASE
  8. Всё, что вы не знали о CAP теореме
  9. Чем плоха CAP-теорема: критика и альтернативы для NoSQL и других Big Data систем
  10. Распределенные данные. Конкурентные операции
  11. CRDT: Conflict-free Replicated Data Types

Видео​

  1. Все про ACID & BASE. Подготовка к собесу в IT (тотальный гайд по вопросу на базы данных)
  2. Топ вопросов на собеседовании по Базам Данных - ACID, BASE, Уровни изоляций (Аномалии)
  3. BASE-архитектура вычислительных систем
  4. Паттерн Saga
  5. Паттерн «Saga» в бронировании отелей · Антон Цитульский
  6. Распределенные транзакции / Что выбрать? Saga или 2pc? / Как подружить микросервисы
  7. Введение в транзакции, ACID и BASE транзакции (Владимир Кузнецов)
  8. Что такое СОБЫТИЙНО-ОРИЕНТИРОВАННАЯ АРХИТЕКТУРА за 9 минут
  9. Паттерн "Transactional Outbox"
  10. TRANSACTIONAL OUTBOX | Главный Паттерн Микросервисной Архитектуры
  11. Филипп Вагнер «Распределенные транзакции в условиях микросервисной архитектуры»

Книги​

  1. Базы данных. Инжиниринг надежности - Кэмпбелл Лейн, Мейджорс Черити (Глава 11. BASE)