2016-04-29 4 views
1

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

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

Возможные решения:

  • Я использую Laravel, и решение я обдумывал толкает запаздывающих заданий в очереди. Хотя вначале я думал, что это будет идеальное решение, я думаю, что он не может быть масштабируемым, так как частота этих запросов может стать слишком высокой, и слишком много заданий будет поставлено в очередь. Кроме того, задания очереди не гарантируются, как только после достижения задержки, и могут быть разрешены слишком поздно.

  • Другое решение, о котором я думал, занималось всем этим в работе cron, работающей каждую минуту, но также имеет ту же проблему, когда объем запросов высок. С точки зрения производительности это может быть чрезмерным, чтобы делать это каждую минуту, особенно в периоды, когда активность нечастая.

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

ответ

1

Я думаю, что вам нужно определить запросы пользователей, требующие действия, которые должны выполняться с помощью базы данных/приложения (то есть области видимости по столбцу expires), а не демоном очереди. Но вы хотите, чтобы это определение происходило с динамической скоростью.

Одно из возможных решений в Laravel:

Создание мета-задания, добавляется в очередь при запуске и сам повторных очередей в динамической скорости. Другими словами, у вас есть только одно задание в очереди, и он оценивает все ожидающие запросы пользователя. Когда это будет сделано, он снова вернется в очередь, с задержкой, которая зависит от количества ожидающих запросов (более ожидающие запросы = более короткая задержка, менее ожидающие запросы = более длительная задержка). Запросы пользователя никогда не помещаются в очередь, просто обрабатываются метаданной с динамической задержкой.

Кроме того, подобно тому, как FYI, то Laravel queue:work --daemon использует sleep() задержать его очереди проверки петли, которые, вероятно, более эффективны, чем использования хрон (или queue:listen процесса), который перегружает все приложения каждый раз, когда это называется , но при компромиссе с необходимостью повторного запуска вручную для внесения любых изменений, которые вы могли бы внести в приложение.

+0

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

Смежные вопросы