У меня есть веб-приложение, где пользователи могут создавать темы, а также комментировать другие темы (похожие на то, что мы имеем здесь, в stackoverflow). Я хочу иметь возможность отправлять уведомления участвующим пользователям обсуждения.
Я знаю, что самый простой способ – связать уведомление с скриптом, выполняемым, когда пользователь взаимодействует с обсуждением. Насколько мне кажется, это очень просто, я считаю, что это не самый подходящий способ, так как пользователю нужно будет дождаться отправки всех уведомлений по электронной почте (завершение оформления уведомления), пока он не получит статус своего действия.
Другая альтернатива, о которой я знаю, – запланировать выполнение скрипта уведомления с помощью cronjob. Для того, чтобы уведомление было релевантным, сценарий планируется выполнить каждые 3-7 минут, чтобы пользователи получали уведомление в разумные сроки.
Теперь я беспокоюсь, будет ли cronjob запускать скрипт каждые 3 минуты, чтобы разумно использовать системный ресурс, учитывая, что мое приложение все еще работает на платформе общего хостинга?
Кроме того, я думаю, возможно, есть сценарий, в котором сценарий комментария запускает или уведомляет скрипт уведомления для отправки уведомлений указанным адресам электронной почты, в то время как сценарий комментариев продолжает выполнение, не дожидаясь завершения сценария уведомления. Если это может быть достижимо, то я думаю, что это будет лучший выбор для меня.
Спасибо вам большое за ваше время.
Если ваш сценарий уведомлений чрезвычайно ресурсоемкий и не отправляет десятки или сотни сообщений в каждом прогоне, я бы не стал беспокоиться о планировании его каждые 3-7 минут на общем хосте. Действительно, если вы запланировали его на 3 минуты и обнаружили проседание производительности на вашем сайте, увеличьте его до 4 минут для сокращения ресурсов на 25%. Однако это вряд ли будет проблемой.
Что касается начального фонового процесса, вы можете добиться этого с помощью системного вызова exec() . Я бы направить вас на этот вопрос для отличного ответа.
ИМО, добавляющая «крючок» к каждому «дискуссионному взаимодействию», на сегодняшний день является самым чистым подходом, и один трюк, чтобы не допустить, чтобы пользователи подождали, – это отправить заголовок Content-Length в ответе HTTP. Хорошие клиенты HTTP должны считывать указанное количество октетов, а затем закрывать соединение, поэтому, если вы отправляете ответ «статус» с соответствующим HTTP-заголовком Content-Length (и устанавливаете ignore_user_abort), то конечный пользователь не будет обратите внимание, что ваш серверный скрипт фактически продолжает свой веский путь, генерируя уведомления по электронной почте (возможно, даже несколько минут) перед выходом.
Я не уверен, что соглашусь с тем, что отправка электронной почты в том же процессе, который служит для запроса, – это путь. Как правило, лучше всего держать вещи простыми; подавайте запрос как можно быстрее и позволяйте фоновым процессам выполнять все задания. Когда трафик увеличивается, и ваши серверы становятся занятыми, этот подход будет продолжать ждать, и пользователи станут более счастливыми. Это также поможет разделить ваши проблемы, которые помогут вам с исправлением ошибок и рефакторингом позже.
Лично я создавал бы скрипт, который периодически запускается в фоновом режиме и проверяет все потоки для новой активности. Если поток имеет новую активность, скрипт может отправлять уведомления всем участникам. Это отделяет вашу логику отправки писем от логики, используемой для обслуживания запросов, а также физически разделяет их – например, если ваш SMTP-сервер внезапно начинает принимать возрасты, чтобы ответить, он не будет влиять на время ответа на запрос. Кроме того, если во время пиков ваш сервер становится слишком занятым, вы можете просто прекратить выполнение этого сценария и позволить серверу сконцентрироваться на обслуживании запросов.
Для запуска этого скрипта вы, конечно, можете просто использовать CRON, и, как было предложено, установите его каждые 4 минуты. Однако, что, если сценарий занимает больше 4 минут? В итоге вы получите два сценария одновременно, что может привести к тому, что несколько пользователей отправят один и тот же адрес электронной почты дважды. Одним из решений для этого было бы использование Fat Controller, который является демоном, который я написал на C, который может периодически запускать любой скрипт (PHP, Python, что угодно) – это в основном демононист для чего-либо. Реально, он может запустить новый экземпляр через несколько секунд после окончания предыдущего экземпляра, поэтому вам не придется беспокоиться о нескольких экземплярах.
Fat Controller очень настраивается и может работать во всех режимах и даже обрабатывать несколько параллельных процессов. Вы можете узнать больше об этом и некоторых вариантах использования на веб-сайте: