Follow along with the video below to see how to install our site as a web app on your home screen.
Примечание: This feature may not be available in some browsers.
id, created_date, state, try, last_try_date, event_type, client_id, service_id, data_to_sent, data_received, success_callback
Deffered Queue - это паттерн проектирования, не какая-то конкретная реализация, а принцип "как надо делать подобные вещи". В чем он заключается, давай на твоем примере предствим:
1. куча клиентов посылают ajax на сервер
2. сервер дергает курл, передает их данные на какой-то сервис
3. клиент получает результат
что плохо? Пока пункт 2 висит - клиент бездействует. Свяжь между сервером и сервисом оборвалась - клиент потерян (а представь что это у тебя заказы в CRM падают, ты потерял заказ, потерял клиента, потерял статистику продаж). А представь что речь идет об уведомлениях об оплате? Клиент оплатил - а ты не получил уведомления об этом, потому что сервер был недоступен. Сколько разбирательств и геммора?
Как надо реализовать такие вещи:
создаешь, к примеру, таблицу в БД (это и есть твоя queue
на пункте 2, вместо того чтобы вызвать CURL, добавляешь строчку в таблицу и уведомляешь клиента что ваши данные получены, ждите ответа.Код:id, created_date, state, try, last_try_date, event_type, client_id, service_id, data_to_sent, data_received, success_callback
Далее, независимо от клиента, cron скрипт вызывается 1 раз в минуту и проверяет, есть ли новые события (это state = 1, к примеру), забирает все новые события, пытается вызвать curl, если он прошел успешно - ставит data_received от сервиса, устанавливает state = 9 (исполнено) и дату. После этого вызывается success_callback (это имя функции для конкретного event_type, если у тебя их несколько) и отправляет письмо клиенту: "ваши данные отправлены на такой-то сервер, вы зарегистрированы". Ну или же при следующем посещении, или ajax'ом со страницы отправки, если юзер еще на ней - получаешь успешное событие и уведомляешь клиента.
Если curl по каким-то причинам отвалился - добавляет try+1 (это чтобы ты при ревизии знал, сколько раз это событие пыталось уйти), не изменяет статус (через минуту снова событие попробует отправиться), можно записать информацию в data_received, тогда, если у тебя есть какая-то серьезная проблема, ты получишь какое-нибудь try=10000, state=1, data_received = fatal error, your server in FBI department. И сразу понятно, что клиент уведомление не получил, что в скрипте есть ошибка или сервер не доступен и прочее.
В случае, если у тебя вопрос приема оплат идет - в data_received при успехе ты можешь хранить ID транзакции. Тогда, если платеж потеряется, сможешь предъявить яндексу: "Да как же так, вот же ваш ID транзакции, у меня все записано, ищите!".