Что будет если транзакцию выполнили, а события не ушли в RabbitMQ?

Обзор проблемы

Когда транзакция базы данных успешно завершается, а события не попадают в RabbitMQ, возникает критическая проблема согласованности данных между системой и внешними потребителями событий. Это классический сценарий частичного отказа распределенной системы.

Основные причины проблемы

1. Неатомарность операций

// Проблемный код - транзакция БД и отправка в RabbitMQ разделены
$db->beginTransaction();
try {
    // 1. Сохраняем данные в БД
    $order->save();
    
    // 2. Фиксируем транзакцию
    $db->commit();
    
    // 3. Отправляем событие (может завершиться ошибкой)
    $rabbitmq->publish('order.created', $orderData);
    
} catch (Exception $e) {
    $db->rollback();
    throw $e;
}

В этом примере если commit() успешен, но publish() падает, данные будут сохранены, но события не отправятся.

2. Проблемы с сетью или RabbitMQ

• Сетевое соединение прервалось после коммита транзакции
• RabbitMQ временно недоступен или перезагружается
• Очередь не существует или права доступа недостаточны

3. Ошибки в коде публикации

• Неправильная сериализация данных
• Неверные настройки exchange/очереди
• Ошибки в обработчиках ошибок RabbitMQ

Последствия для системы

Непоследовательность данных:

• Потребители событий не узнают о изменениях
• Другие микросервисы останутся в неконсистентном состоянии
• Нарушаются бизнес-процессы, зависящие от событий

Бизнес-риски:

• Отсутствие нотификаций пользователям
• Несработавшие интеграции с внешними системами
• Некорректные отчеты и аналитика

Стратегии решения

1. Transactional Outbox Pattern

class OrderService {
    public function createOrder(array $data) {
        $db->beginTransaction();
        
        try {
            // 1. Сохраняем заказ
            $order = Order::create($data);
            
            // 2. Сохраняем событие в ту же транзакцию
            OutboxMessage::create([
                'topic' => 'order.created',
                'payload' => json_encode($order->toArray()),
                'status' => 'pending'
            ]);
            
            // 3. Коммитим вместе
            $db->commit();
            
        } catch (Exception $e) {
            $db->rollback();
            throw $e;
        }
        
        // 4. Отдельный процесс отправляет события
        $this->dispatchOutboxMessages();
    }
}

2. Паттерн Polling Publisher

// Отдельный воркер периодически проверяет outbox
class OutboxWorker {
    public function processPendingMessages() {
        $messages = OutboxMessage::where('status', 'pending')
            ->limit(100)
            ->get();
            
        foreach ($messages as $message) {
            try {
                $rabbitmq->publish(
                    $message->topic,
                    $message->payload
                );
                
                $message->update(['status' => 'sent']);
                
            } catch (Exception $e) {
                $message->increment('retry_count');
                // Логирование и алертинг
            }
        }
    }
}

3. Использование Change Data Capture (CDC)

// Использование Debezium или аналогичных инструментов
// для отслеживания изменений в binlog БД
// и автоматической публикации событий

4. Подход с двухфазным коммитом (2PC)

# Пример псевдокода для 2PC
try:
    # Фаза подготовки
    db.prepare_transaction()
    rabbitmq.prepare_publish()
    
    # Фаза коммита
    if all_prepared_successfully:
        db.commit()
        rabbitmq.commit_publish()
    else:
        db.rollback()
        rabbitmq.rollback_publish()
        
except Exception:
    # Координация отката
    db.rollback()
    rabbitmq.rollback_publish()

Практические рекомендации

Обязательные меры:

1. Мониторинг и алертинг за рассинхронизацией
2. Механизм повторных попыток с экспоненциальной задержкой
3. Ручное вмешательство через административный интерфейс
4. Компенсирующие транзакции для отката изменений

Архитектурные решения:

Преимущества Transactional Outbox:
✅ Гарантирует доставку хотя бы один раз (at-least-once)
✅ Хорошая производительность
✅ Простота реализации

Недостатки:
❌ Задержка доставки событий
❌ Дополнительная нагрузка на БД
❌ Необходимость отдельного воркера

Критические проверки:

# Мониторинг рассинхронизации
SELECT COUNT(*) FROM outbox_messages 
WHERE status = 'pending' 
AND created_at < NOW() - INTERVAL 5 MINUTE;

# Проверка здоровья RabbitMQ
rabbitmqctl list_queues messages ready

Заключение

Проблема отправки событий после коммита транзакции требует комплексного подхода, сочетающего:

• Паттерны обеспечения надежности (Outbox, CDC)
• Мониторинг и алертинг
• Процедуры восстановления

Наиболее надежным решением для PHP-приложений является Transactional Outbox Pattern, дополненный фоновым воркером и механизмом повторных попыток. Это обеспечивает баланс между надежностью, производительностью и сложностью реализации.