Как обработать 2 одновременных запроса со стороннего сервера?

Question

[Вечно Крайний]

Здравствуйте! Столкнулся с такой проблемой!
Пользователь кидает некий запрос на мой сервер (на handler.php например)
В теле запроса есть какие-то параметры какие мне нужны например

$_REQUEST = [
    'auth' => '123412341234',
    'member_id' => 'asdfasdfasdf'
];

И мне нужно на этот запрос ответить,

Проблема в том что в моменте мне приходят два полностью идентичных запроса в одно и тоже время.
Под капотом я обращаюсь по ресту к стороннему сервису и дублирование мною запросов приводит там к ошибке.

Что пробовал.
1. Вставлял рандомную задержку в hadler.php и потом проверял есть уже такой запущенный процесс (реализовывал что блокировку потока к файлу fopen flock)
2 Складировал запросы в редис, потом из handler.php делал exec(php worker.php) и разбирал то что есть в очереди, но проблема в том что все равно запускается 2 процесса worker.php
3. Пытался на уровне сервера настроить (Centos стоит) но там только кол-во запросов в секунду, а мне приходят прям одновременно.

Подскажите, пожалуйста, как можно решить эту проблему.

Comments

[Ипатьев]

А зачем вы запускаете 2 процесса worker.php?

[alexalexes]

1. Вставлял рандомную задержку в hadler.php и потом проверял есть уже такой запущенный процесс (реализовывал что блокировку потока к файлу fopen flock)

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

if(flock($lock_file_handler, LOCK_EX | LOCK_NB))
{
  // делать то, что может только один поток в один момент времени
}

Насчет других способов, подсказать не могу. Они должны обладать механизмом семафора, чтобы можно было одной транзакцией делать операции "проверил состояние - тут же закрыл критическую секцию". Если выбранный способ не отвечает этому требованию, то работать не будет.

[Вечно Крайний]

Ипатьев, я не запускаю их сам. Ну если кратко вот что пробовал
handler.php

$oRedis->set('uniq_id', json_encode($_REQUEST));
exec('php worker.php');

worker.php

$arRequest = $oRedis->get('uniq_id');
run($arRequest);

Проблема в том что приходит 2 запроса на handler.php. Каждый из них выполняет exec() и по итогу запускается 2 worker.php.

[Ипатьев]

А чем тогда смысл выносить в воркер? :D

Воркер должен запускаться как отдельный процесс и читать из редиса по очереди. а handler.php только в него класть

[alexalexes]

$oRedis->set('uniq_id', json_encode($_REQUEST));
exec('php worker.php');

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

[Вечно Крайний]

alexalexes, да реализовывал иммено так, Не работает((

public function open()
    {
        if (!$this->fp) {
            $this->fp = fopen($this->sPath, 'w+');
        }
        if (!flock($this->fp, LOCK_EX | LOCK_NB)) {
            return false;
        }
        ftruncate($this->fp, 0);
        fwrite($this->fp, getmypid());
        fflush($this->fp);
        return true;
    }

[Вечно Крайний]

Ипатьев, да я хз в чем смысл. Говорю же что не работает это способ.
Я пытался в вокрер вынести блокировку файла и пробовал искать такой же процесс.
И из-за того что они оба запускается одновременно они видят друг друга и проверка не работает.
Я хочу типа такого

if(какой-то условие) {
    die();
}

и чтобы один процесс это условие прошел, а другой нет.
А они либо оба проходят, либо оба не проходят.

[alexalexes]

Вам еще нужен механизм в handler.php

if(проверить, что в очереди нет сообщения с таким же телом запроса, отправленное не более x секунд назад) // x секунд рассчитывается от времени бана за одинаковые запросы к стороннему API
{
  // положить сообщение в очередь
}

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

[Вечно Крайний]

alexalexes,

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

Это все есть, проблема в том что два worker.php запускаются, они и метки времени сверяют и т.д.
Нужно чтобы один из этих worker.php на каком-то этапе сдох. А вот это я реализовать пока не могу.

[alexalexes]

Вечно Крайний, тогда другой вопрос, какие границы критической секции?
Когда вы снимаете блокировку с файла?

[Вечно Крайний]

alexalexes,

тогда другой вопрос, какие границы критической секции?
Когда вы снимаете блокировку с файла?

блокировку снимаю при окончании работы воркера, т.е. когда прошла вся логика.
Если очень просто я регистрирую клиента на стороннем сервисе и должен вернуть ему "ОК зарегистрирован"
Вот когда все процессы закончились на стороннем сервисе (сек 5-7 обычно) я отправляю клиенту ответ и закрываю поток к файлу

[alexalexes]

В каждом файле сделайте свойство некого уникального идентификатора процесса, которое присваивается при запуске скрипта:
$this->proc_unid = rand(100000, 999999);
Прологируйте в файл места:
Перед блокировкой критической секции
После блокировки
Отправка запроса к стороннему API
После снятия блокировки.

Также сделайте логирования скрипта, который выставляет задание для воркера.

Везде пишите идентификатор proc_unid.

После анализа логов будет понятно, что не так работает.

[Wispik]

Вечно Крайний, на главный вопрос так и нет ответа. Зачем каждый раз запускать worker из handler.php? worker должен быть запущен просто как отдельный процесс и выполнять свою работу

[Вечно Крайний]

Wispik, благодарю что зашли чтобы попытаться помочь, но прочитайте пожалуйста сообщения выше. Я уже давал ответ этот вопрос.
Вариант работы через воркеры это просто попытка решить проблему.
Она как раз в этом и заключается как запустить один worker.php, при условии что запускается 2 handler.php

[Ипатьев]

Вы давали не ответ, а беспомощное блеяние.
Вам сказали запускать воркер отдельно от хендлера, как запускают все воркеры.
А вы всё лепечете что "запускается 2 handler.php". ДА ХОТЬ ДЕСЯТЬ. Воркер должен запускаться ОТДЕЛЬНО, ОДИН. А не через этот нелепый exec(). И работать всё время.

[Ипатьев]

alexalexes, зачем тут какие-то блокировки? А, главное - ЗАЧЕМ ДВА воркера?

[Виктор Кожухарь]

Вечно Крайний, Если вы хотите именно такой подход, то тут будет всё намного сложнее.
handler.php должен запускаться вебсервером как обычно.
handler.php должен просто складывать сообщения с телом запроса в очередь.
worker.php должен быть отдельным процессом и только читать по очереди те сообщения, что в неё пуляют handler.php. Он должен сам проверять, было ли уже такое сообщение или нет и принимать решение о том, отправлять ли данные дальше или игнорировать их.
worker.php должен быть единственным, запускаться самой операционной системой и находиться под наблюдением supervisor, чтобы тот его перезапускал, ежели он упадёт.

Проблема с этим асинхронным подходом в том, что handler.php не знает результата работы worker.php, т.к. они живут в разных вселенных.
Я обычно решаю эту проблему установкой специального сервиса Mercure (mercure.rocks), к которому браузер клиента коннектится и ждёт сообщения от бэкенда по каналу SSE (Server Sent Events). И мы из worker.php будем кидать сообщения обычным http запросом в этот самый Mercure, а он будет раскидывать эти сообщения всем подключённым к нему браузерам.

Сложно? Да, сложно. Но с отдельным и единственным долгоживущим worker.php только так...

Answer 1

[Виктор Кожухарь]

Охх... Никогда не думал, что столкнусь с race condition в PHP )))
В других языках такое решают общим хранилищем данных для всех параллельных потоков и использованием мьютекса.

Мы же можем воспользоваться инструментами Redis, которые сделали специально для решения таких вещей. У Redis есть специальные флаги, позволяющие использовать атомарные операции. Команда SET с параметрами NX и EX.

• SET key value NX — установить ключ, только если он Not eXists (не существует).

  
• SET key value EX seconds — установить ключ с временем жизни (eXpire) в секундах.
  

Комбинация этих двух флагов позволяет создать атомарную операцию "захватить блокировку на N секунд".

handler.php

<?php

$redis = new Redis();
$redis->connect('127.0.0.1', 6379);

// 1. Создаем уникальный ключ для этого конкретного запроса
$lockKey = 'request_lock:' . md5(json_encode($_REQUEST));

// 2. Пытаемся захватить ключ на 10 секунд
// Эта команда атомарная: только один процесс из двух победит.
$isLockAcquired = $redis->set($lockKey, '1', ['nx', 'ex' => 10]);

if ($isLockAcquired) {
    // КЛЮЧ НАШ! Делаем свою работу
    try {
        // ... обращаемся к стороннему сервису, запускаем worker.php или ваще что угодно ...
        
        // отвечаем клиенту об успехе операции
        http_response_code(200);
        echo json_encode(['status' => 'success']);

    } catch(\Throwable $e) {
        // Освобождаем ключ для будущих запросов в случае ошибки, чтобы не ждать 10с для переотправки.
        $redis->del($lockKey);
        // отвечаем клиенту, что произошла ошибка
        http_response_code(500);
        echo json_encode(['status' => 'error']);
    }

} else {
    // КЛЮЧ УЖЕ КЕМ-ТО ЗАНЯТ. Ничего не делаем.
    // Просто отвечаем клиенту, что все ок или что запрос дублируется.
    http_response_code(429); // Too Many Requests
    echo json_encode(['status' => 'error', 'message' => 'Request already in progress']);
    exit;
}

Comments

[Алексей Уколов]

// Освобождаем ключ для будущих запросов в случае ошибки, чтобы не ждать 10с для переотправки.
$redis->del($lockKey);

Только это лучше в finally вынести :)

[Виктор Кожухарь]

Алексей Уколов, Ага, точно. Ща поправим

[Виктор Кожухарь]

Алексей Уколов, С другой стороны, если оно слишком быстро отработает, то мы снова столкнёмся с этой проблемой. Если у автора проблема именно с повторяющимися запросами, то лучше пусть эти 10 секунд так и пройдут, и Redis сам удалит ключ. В этом случае лучше озаботиться генерацией вот этого самого уникального ключа, чтобы он отлавливал именно те запросы, которые точно дубли с точки зрения автора, и пропускал другие. А для этого не стоит удалять ключ в случае успеха.
Зато в случае ошибки как раз и надо удалить ключ, ведь ошибка может быть вызвана не только неверными данными, но и сбоем сети и т.д. И тут ждать 10с будет неверно.