Event Sourcing — pattern, где current state derived из sequence immutable events, хранящихся в event log. Вместо UPDATE user SET balance = 100, пишем BalanceCredited {amount: 100}. Преимущества: full audit trail, time-travel queries, rebuild of state. Минусы: сложная схема migrations, eventual consistency, "upcasting" старых events при schema evolution.
Ниже: подробности, пример, смежные термины, FAQ.
Бесплатный онлайн-инструмент — проверка HTTP-заголовков: результат мгновенно, без регистрации.
// Events append
EventStore.append('order-123', [
OrderCreated { customerId, items }
OrderConfirmed { timestamp }
OrderShipped { trackingNumber }
])
// Rebuild state by replaying events
state = fold(events, initialState, applyEvent)Event Sourcing — это архитектурный паттерн, который сохраняет состояние системы в виде последовательности событий, а не текущего состояния. Это позволяет эффективно отслеживать изменения, восстанавливать состояние системы и обеспечивать высокую степень аудита. Вместо обновления записи в базе данных, каждое изменение сохраняется как отдельное событие, что обеспечивает полную историю изменений и возможность отката к предыдущим состояниям.
Использование Event Sourcing имеет несколько ключевых преимуществ:
Эти преимущества делают Event Sourcing особенно привлекательным для систем с высоким уровнем изменений и требований к аудиту.
Рассмотрим практический пример реализации Event Sourcing на языке программирования Java с использованием Spring Framework. Предположим, у нас есть приложение для управления заказами, и мы хотим реализовать Event Sourcing для обработки изменений статуса заказа.
import org.springframework.context.event.EventListener;
import org.springframework.stereotype.Component;
@Component
public class OrderEventHandler {
@EventListener
public void handleOrderCreated(OrderCreatedEvent event) {
// Логика обработки события создания заказа
}
@EventListener
public void handleOrderUpdated(OrderUpdatedEvent event) {
// Логика обработки события обновления заказа
}
}
В этом примере мы создаем обработчики событий, которые реагируют на события создания и обновления заказа. Эти события могут быть сохранены в хранилище событий, таком как Apache Kafka или Amazon Kinesis, что позволяет асинхронно обрабатывать их и обеспечивать высокую доступность.
Для хранения событий можно использовать следующий пример конфигурации в application.yml:
spring:
kafka:
bootstrap-servers: localhost:9092
consumer:
group-id: order-service
auto-offset-reset: earliest
С помощью этой конфигурации приложение будет подключаться к Kafka, чтобы получать события и обрабатывать их в порядке их создания.
Нет, но часто их combine. ES даёт write-side, CQRS разделяет read и write models.
Upcasters: at read time, old event versions transformed до new schema. Или versioned event types (OrderCreated_V1, V2).
Events накапливаются линейно. Для long-lived streams — snapshots каждые N events. Или archival старых events в cold storage.
Бесплатный тариф — 10 мониторов, проверки каждые 5 мин, без карты. Платные тарифы — интервал от 1 минуты и проверки из нескольких регионов.