Я работаю над проектом API, который должен отправлять электронные письма и сохранять статистику после (или до того, как это будет зависеть от реализации) ответа, который будет возвращен клиенту. В обоих случаях я рассматриваю компонент EventDispatcher Symfony (я не использую Symfony в качестве платформы), поэтому каждое действие контроллера будет отправлять событие, чтобы добавить сообщение электронной почты в очередь или вставить данные в таблицу базы данных статистики.
Так что вещь будет выглядеть примерно так
Controller
=> Send Response to client
=> Dispatch Event email => EmailEventListener => Mail queue
=> Dispatch Event stats => StatsEventLister => Database
Я рассматриваю это, потому что я хочу, чтобы эти внутренние действия были как можно более асинхронными. Это подходящее решение для этого случая?
РЕДАКТИРОВАТЬ: Как Йован Перович предположил, что я добавляю больше информации. API — это REST API, с которым пользователи общаются через него через веб-интерфейс или мобильные приложения, и я хочу регистрировать, хранить статистику и отправлять уведомления (в первую очередь, электронные письма) без ущерба для производительности API. Первой идеей было использование чего-то, что запускается после возврата. ответ клиенту, но я не знаю, возможно ли это с помощью EventDispatcher. Даже если очередь используется для обработки статистики или уведомлений, мне нужно централизованное место, куда все контроллеры могут отправлять информацию, чтобы можно было записывать журналы и сохранять статистику.
Я надеюсь, что моя цель теперь более ясна. Сожалею.
Я думаю, что вы могли бы использовать Фильтры запроса (After
будет подходящим для вас), хотя, я никогда не пытался использовать их за пределами Symfony2
фреймворк.
Что касается асинхронных операций, в общем, сокеты — ваш друг. Вы можете вывести логику из внешнего источника, отправив данные в некоторый сокет, который, в свою очередь, обработает данные соответствующим образом. Если эта обработка не является необходимой (например, электронная почта и статистика), ваш запрос может быть завершен, даже если ваш внешний механизм не работает.
Я читал некоторое время назад о Gearman
Вот (просто пример), который может помочь вывести это на внешний вид путем создания отдельных рабочих мест.
Надеюсь, что это проливает свет здесь 🙂
Других решений пока нет …