Как решается проблема дубликата входящих запросов?

Решение проблемы дубликата входящих запросов в Go

Проблема дубликата входящих запросов возникает, когда клиент отправляет несколько идентичных запросов одновременно или почти одновременно (например, при быстрых повторных нажатиях кнопки или из-за сетевых повторных отправок). Это может привести к критическим побочным эффектам: двойным платежам, повторному созданию сущностей, рассинхронизации данных или чрезмерной нагрузке на систему.

Основные стратегии решения

Для решения применяется комбинация идентификации, дедупликации и контроля состояния запросов.

1. Идентификация дубликатов: Ключ дедупликации

Каждый запрос должен иметь уникальный идентификатор. Часто используются:

• Client-generated ID: UUID от клиента в заголовке или теле запроса.
• Совокупность параметров: Хэш от метода, пути, тела и критичных заголовков.
• Идентификатор бизнес-операции: Например, order_id для платежей.

// Пример ключа из заголовка X-Request-ID
func getDeduplicationKey(req *http.Request) string {
    key := req.Header.Get("X-Request-ID")
    if key == "" {
        // Fallback: хэш основных параметров
        bodyHash := sha256.Sum256([]byte(req.URL.Path + req.Method))
        key = hex.EncodeToString(bodyHash[:])
    }
    return key
}

2. Механизмы дедупликации

А. Локальный in-memory кэш (для одного инстанса)

Используется sync.Map или map с мьютексами для краткосрочного хранения ключей.

type Deduplicator struct {
    seenRequests sync.Map // map[string]time.Time
    ttl          time.Duration
}

func (d *Deduplicator) IsDuplicate(key string) bool {
    if _, found := d.seenRequests.Load(key); found {
        return true
    }
    d.seenRequests.Store(key, time.Now())
    // Асинхронная очистка старых ключей (можно через горутину с таймером)
    return false
}

Б. Распределенные системы (для кластера)

Для нескольких серверов необходим централизованный хранилище:

• Redis с командами SETNX (Set if Not Exists) и TTL.
• Memcached или распределенный кэш.
• База данных с уникальными индексами для ключа операции.

Пример с Redis:

func checkDuplicateRedis(redisClient *redis.Client, key string, ttlSeconds int) (bool, error) {
    // SETNX возвращает 1, если ключ установлен, 0 если уже существовал
    result, err := redisClient.SetNX(context.Background(), key, "processed", time.Duration(ttlSeconds)*time.Second).Result()
    if err != nil {
        return false, err
    }
    return !result, nil // result == false означает дубликат
}

В. Блокировки и механизмы контроля состояния

Если запрос уже обрабатывается, можно заблокировать повторное выполнение.

func processRequestWithLock(mutex *sync.Mutex, key string, fn func()) {
    mutex.Lock()
    defer mutex.Unlock()
    
    // Проверка состояния в общем хранилище (например, Redis)
    if isAlreadyProcessed(key) {
        return // Или возвращаем ранее полученный результат
    }
    fn()
}

3. Паттерны обработки на уровне бизнес-логики

• Idempotency Keys (Ключи идемпотентности): Сервер гарантирует, что при одинаковом ключе результат будет один, даже если запросов много. Реализуется через сохранение результата первого запроса и его возврат для последующих дубликатов.

func handlePaymentWithIdempotency(db *sql.DB, idempotencyKey string, paymentReq PaymentRequest) (*PaymentResponse, error) {
    // 1. Проверяем, есть ли уже сохраненный ответ для этого ключа
    var existingResponse PaymentResponse
    err := db.QueryRow("SELECT response_data FROM idempotency_log WHERE key = ?", idempotencyKey).Scan(&existingResponse)
    if err == nil {
        return &existingResponse, nil // Возвращаем сохраненный результат
    }
    
    // 2. Если нет — выполняем операцию, сохраняем результат и ключ
    response := processPayment(paymentReq)
    _, err = db.Exec("INSERT INTO idempotency_log (key, response_data) VALUES (?, ?)", idempotencyKey, response)
    return &response, err
}

• Последовательность операций (Sequencing): Использование возрастающих номеров операций (sequence numbers) от клиента. Сервер принимает только запросы с номером больше последнего принятого.

Практическая архитектура в Go-приложении

Часто решение строится как мидлварь или декоратор обработчика запросов.

func deduplicationMiddleware(redisClient *redis.Client, next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        dedupKey := getDeduplicationKey(r)
        
        isDuplicate, err := checkDuplicateRedis(redisClient, dedupKey, 30)
        if err != nil {
            http.Error(w, "Internal deduplication error", http.StatusInternalServerError)
            return
        }
        if isDuplicate {
            // Можно возвращать 409 Conflict или специальный статус
            http.Error(w, "Duplicate request detected", http.StatusTooManyRequests)
            return
        }
        
        next(w, r) // Передаем запрос дальше
    }
}

// Использование
http.Handle("/api/payment", deduplicationMiddleware(redisClient, paymentHandler))

Ключевые рекомендации

• TTL (Time to Live): Все ключи дедупликации должны иметь ограниченное время жизни (например, 30 секунд или 1 минуту), чтобы не засорять хранилище.
• Дифференциация по методам: GET запросы обычно идемпотентны по природе, дедупликация наиболее важна для POST, PUT, DELETE.
• Гранулярность ключа: Ключ должен быть достаточно уникальным, но не мешать параллельной обработке разных запросов.
• Обработка ошибок и retry: Если первый запрос завершился ошибкой, клиент может повторно отправить его с тем же ключом — система должна это корректно обрабатывать (возможно, разрешать повтор после определенного времени).

Выбор решения

• Для монолита/одного сервера: Локальный sync.Map с горутиной для очистки.
• Для микросервисов/кластера: Redis как стандартное решение.
• Для финансовых операций: Идемпотентные ключи в базе данных с сохранением результатов.
• Для высоконагруженных API: Комбинация быстрого in-memory кэша на edge-сервере (nginx) и проверки на уровне бизнес-логики.

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