Кэш транзакций

Кэш транзакций обеспечивает управление активными транзакциями базы данных MongoDB и их распределение между экземплярами сервиса. Система использует Redis для хранения метаданных транзакций и координации работы между узлами кластера.
Важность управления транзакциями
Правильное управление кэшем транзакций критично для обеспечения целостности данных и предотвращения блокировок в базе данных.
Обзор архитектуры

Система управления транзакциями состоит из нескольких компонентов, работающих совместно для обеспечения надежной обработки транзакций в распределенной среде.
  • MongoDB транзакции - Управление ClientSession объектами и контроль жизненного цикла транзакций
  • Автоматическая очистка - Планировщики для удаления истекших и осиротевших транзакций
  • Redis кэш - Хранение метаданных транзакций и обеспечение маршрутизации между узлами
  • Мониторинг - Метрики производительности и состояния активных транзакций
Создание транзакции

Новые транзакции создаются через эндпоинт /sbrs-data/start-transaction. Каждая транзакция получает уникальный идентификатор и привязывается к конкретному экземпляру сервиса.

Пример запроса начала транзакции
curl -X POST "https://your-domain.com/sbrs-data/start-transaction" \
-H "Content-Type: application/json" \
-H "SBRS-API-Key: your-api-key-here" \
-H "SBRS-Correlation-Id: unique-correlation-id" \
-H "SBRS-Originator: your-application" \
-H "SBRS-Message-Id: unique-message-id"
Пример ответа
{
"transactionId": "550e8400-e29b-41d4-a716-446655440000",
"sbrsMessageType": "success",
"sbrsStatusMessage": "Transaction started successfully"
}
Процесс создания транзакции:
  1. Проверка лимита активных транзакций (по умолчанию 100)
  2. Генерация уникального UUID для транзакции
  3. Создание MongoDB ClientSession с активной транзакцией
  4. Регистрация метаданных в Redis с TTL
  5. Настройка маршрутизации к текущему экземпляру
  6. Активация системы отслеживания истечения времени
  7. Обновление метрик производительности
Завершение транзакции

Транзакции завершаются через эндпоинт /sbrs-data/finish-transactionс указанием действия: commit для фиксации изменений или rollback для отката.

Пример завершения транзакции
curl -X POST "https://your-domain.com/sbrs-data/finish-transaction" \
-H "Content-Type: application/json" \
-H "SBRS-API-Key: your-api-key-here" \
-H "SBRS-Correlation-Id: unique-correlation-id" \
-H "SBRS-Originator: your-application" \
-H "SBRS-Message-Id: unique-message-id" \
-H "SBRS-Transaction-Id: 550e8400-e29b-41d4-a716-446655440000" \
-d '{
"action": "commit"
}'
  • Commit (фиксация) - Сохраняет все изменения, сделанные в рамках транзакции, и делает их видимыми для других операций
  • Rollback (откат) - Отменяет все изменения в транзакции и возвращает базу данных к состоянию до начала транзакции
Структура данных в Redis

Каждая транзакция хранит следующие данные в Redis с различными префиксами ключей:
Структура метаданных транзакции
{
"transactionId": "550e8400-e29b-41d4-a716-446655440000",
"instanceId": "app-instance-8080",
"correlationId": "req-12345",
"originator": "api-client",
"messageId": "msg-67890",
"startTime": "2025-01-15T10:30:00",
"lastActivity": "2025-01-15T10:30:15",
"status": "ACTIVE",
"maxDurationMs": 300000
}
Автоматическая очистка

Система включает несколько механизмов автоматической очистки для предотвращения утечек ресурсов:
📅 Регулярная очистка
Выполняется каждые 30 секунд
  • Проверка истекших транзакций по TTL в Redis
  • Принудительный откат активных сессий
  • Удаление осиротевших транзакций
🔍 Глубокая проверка
Выполняется каждые 5 минут
  • Сканирование всех активных транзакций
  • Поиск неочищенных истекших транзакций
  • Принудительный запуск cleanup при обнаружении проблем
⚡ Redis expiration events
Мгновенная реакция на истечение TTL ключей в Redis
  • Подписка на события истечения ключей exp_track:*
  • Немедленная очистка при получении события
  • Дополнительная проверка активности транзакции
Маршрутизация транзакций

В кластерной среде транзакции привязываются к конкретным экземплярам сервиса для обеспечения консистентности. Система маршрутизации обеспечивает направление запросов к правильному узлу.
Принципы маршрутизации:
  1. Каждая транзакция создается и выполняется на одном экземпляре сервиса
  2. Идентификатор экземпляра сохраняется в Redis под ключом routing:{transactionId}
  3. Входящие запросы проверяют маршрутизацию перед обработкой
  4. При недоступности целевого экземпляра транзакция откатывается
Мониторинг и метрики

Система собирает детальные метрики для мониторинга производительности и состояния кэша транзакций:
  • Активные сессии - Количество транзакций в процессе выполнения
  • Всего закрыто - Количество успешно завершенных транзакций
  • Использование памяти - Объем памяти, занимаемый кэшем транзакций
  • Утечки сессий - Количество принудительно очищенных транзакций
  • Всего создано - Общее количество созданных транзакций
  • Время выполнения - Суммарная длительность всех транзакций
Получение метрик через API
curl -X GET "https://your-domain.com/transaction-cache/metrics" \
-H "Authorization: Bearer your-token"
Пример ответа с метриками
{
    "status": "healthy",
    "instances": [
        {
            "instanceId": "app-instance-8080",
            "status": "healthy",
            "activeTransactions": [
                {
                    "transactionId": "550e8400-e29b-41d4-a716-446655440000",
                    "hasActiveTransaction": true,
                    "startTime": "2025-01-15T10:30:00",
                    "lastActivity": "2025-01-15T10:32:15",
                    "correlationId": "req-12345",
                    "originator": "api-client",
                    "expired": false
                }
            ]
        }
    ],
    "metrics": {
        "totalactiveSessionCount": 5,
        "totalmemoryUsage": 5120,
        "totalSessionsCreated": 1247,
        "totalSessionsClosed": 1242,
        "sessionLeakCount": 3,
        "maxActiveTransactions": 100
    }
}
Обработка ошибок

Система обрабатывает различные сценарии ошибок для обеспечения надежности:
Специальные сценарии
🔄 Отказ Redis
При недоступности Redis система продолжает работу в ограниченном режиме:
  • Метаданные сохраняются только локально
  • Маршрутизация между экземплярами недоступна
  • Выполняется локальная очистка истекших транзакций
  • Автоматическое восстановление при возобновлении связи
💥 Аварийное завершение
При аварийном завершении экземпляра сервиса:
  • Активные транзакции автоматически истекают по TTL
  • MongoDB сессии закрываются автоматически
  • Redis ключи удаляются по истечении времени
  • Событие expiration инициирует очистку на других узлах
🔄 Орфанные транзакции
Транзакции, потерявшие связь с Redis:
  • Обнаруживаются при регулярной проверке
  • Автоматически откатываются системой
  • Засчитываются в метрику sessionLeakCount
  • Логируются как предупреждения
Лучшие практики
⚡ Производительность
  • Минимизируйте время жизни транзакций
  • Всегда явно завершайте транзакции (commit/rollback)
  • Избегайте долгих операций внутри транзакций
  • Мониторьте метрики активных сессий
  • Настройте алерты на превышение лимитов
🛡️ Надежность
  • Реализуйте retry логику для временных ошибок
  • Обрабатывайте исключения TransactionExpiredException
  • Используйте корреляционные ID для трассировки
  • Настройте мониторинг состояния Redis
  • Регулярно проверяйте логи на предмет утечек
Устранение неполадок
Проблема: Высокое потребление памяти
Возможные причины:
  • Накопление долгоживущих транзакций
  • Неправильная настройка cleanup интервалов
  • Проблемы с завершением транзакций в приложении
Решение: Проверьте метрики, сократите timeout, увеличьте частоту cleanup.
Проблема: Ошибки маршрутизации транзакций
Возможные причины:
  • Недоступность Redis
  • Отказ экземпляра, владеющего транзакцией
  • Проблемы с сетевой связностью
Решение: Проверьте доступность Redis и статус экземпляров сервиса.
Made on
Tilda