Реализация уведомления по электронной почте

Question

У меня есть веб-приложение, в котором пользователи могут создавать темы, а также комментировать другие темы (аналогично тому, что мы имеем здесь в stackoverflow).Я хочу иметь возможность отправлять уведомления участвующим пользователям обсуждения.

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

Другая известная мне альтернатива - это планирование выполнения скрипта уведомления с помощью cronjob.Чтобы уведомление было релевантным, сценарий будет запускаться каждые 3–7 минут, чтобы пользователи могли получать уведомления в разумные сроки.

Теперь меня беспокоит то, будет ли установка cronjob назапускать скрипт каждые 3 минуты потребляя разумный системный ресурс, учитывая, что мое приложение все еще работает на платформе общего хостинга?

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

Большое спасибо за ваше время.

Answer 1

IMO, добавление «крючка» к каждому «взаимодействию обсуждений» является безусловно самым чистым подходом, и один из приемов, чтобы не заставлять пользователей ждать, - это отправить обратно заголовок Content-Length в HTTP-ответе. HTTP-клиенты с хорошим поведением должны считывать указанное количество октетов и затем закрывать соединение, поэтому, если вы отправите ответ «status» с правильным HTTP-заголовком Content-Length (и установите ignore_user_abort), то конечный пользователь не будет обратите внимание, что ваш серверный скрипт на самом деле продолжает свой веселый путь, генерируя уведомления по электронной почте (возможно, даже в течение нескольких минут) перед выходом.

Answer 2

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

Лично я бы создал скрипт, который периодически запускается в фоновом режиме и проверяет все потоки на наличие новых действий. Если у потока есть новое действие, тогда сценарий может отправлять уведомления по электронной почте всем участникам. Это отделяет вашу логику отправки электронных писем от логики, используемой для обслуживания запросов, а также физически разделяет их - например, если ваш SMTP-сервер внезапно начинает отвечать на запросы, это не окажет сдерживающего влияния на время ответа на ваш запрос. Кроме того, если в часы пиковой нагрузки ваш сервер слишком загружен, вы можете просто прекратить запуск этого сценария и позволить серверу сосредоточиться на обслуживании запросов.

Чтобы запустить этот скрипт, вы, конечно, можете просто использовать CRON, и, как предлагается, запускать его раз в 4 минуты. Однако что делать, если сценарий занимает больше 4 минут? В конечном итоге вы получите два сценария, выполняющихся одновременно, что может привести к тому, что некоторые пользователи отправят одно и то же письмо дважды. Одним из решений этой проблемы было бы использование Fat Controller - демона, который я написал на C, который может периодически запускать любой скрипт (PHP, Python, что угодно) - это в основном демонизатор для всего. Важно отметить, что он может запустить новый экземпляр через x секунд после окончания предыдущего, поэтому вам не придется беспокоиться о нескольких экземплярах.

Fat Controller очень настраивается и может работать во всех режимах и даже обрабатывать несколько параллельных процессов. Вы можете прочитать больше об этом и некоторых случаях использования на сайте:

http://www.4pmp.com/fatcontroller/

Answer 3

Если ваш сценарий уведомлений не требует значительных ресурсов и отправляет десятки или сотни сообщений при каждом запуске, я бы не стал беспокоиться о его планировании каждые 3-7 минут на общем хосте. Действительно, если вы запланировали это на 3 минуты и обнаружили снижение производительности на своем сайте, то увеличьте его до 4 минут для сокращения ресурсов на 25%. Хотя вряд ли это будет проблемой.

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