Архитектура веб-приложений: проверка будущего

Question

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

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

Это хорошая идея? Или есть лучший подход? Мне действительно нужна помощь, чтобы сделать это правильно, чтобы потом избавить себя от головной боли:)

Спасибо всем

Answer 1

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

Позже, если это станет узким местом, вы можете захотеть, чтобы отправка почты осуществлялась с другой машины, которая может даже не иметь доступа к БД, поэтому эти крошечные вложения заранее предоставят вам варианты позже.

Answer 2

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

Еще лучше, если вы делаете сжатие разумным и не используете сжатие при сжатии больших уже сжатых файлов (MP3, ZIP, DOCX, XLSX, JPG, GIF и т. Д.) И используете высокое сжатие при наличии простых текстовых файлов TXT, XML, DOC, XLS и т. Д.), Поскольку они будут очень быстро архивироваться даже при сильном сжатии.

Answer 3

Хороший подход. Некоторые уточнения:

1. Не используйте задание cron, вместо этого отправляйте запросы по таймеру.
2. Включите государственный флаг для сортировки нескольких читателей / писателей.
3. Считыватель должен истощить очередь - не блокировать, пока чтение не станет пустым.
4. Будьте проще. Вложите сложность и тонкость в разговор писателя / читателя.

По моему опыту, это будет хорошо масштабироваться.

Answer 4

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

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

Старайтесь не создавать ничего, что вы проектируете, в течение нескольких недель. Часто к вам приходят другие сценарии, прежде чем что-то заперто.

Answer 5

Хм. Мне не очень нравится идея, что cron запускает что-то каждую секунду. Это кажется слишком часто. Если ваше приложение действительно должно быть таким отзывчивым, то я думаю, что вы должны поддерживать его синхронность. То есть сохраняйте обработку в своем веб-приложении и ищите другие способы снижения уровня нагрузки на сервер.

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

Однако, несмотря на это, любой порядочный агент пересылки почты (sendmail, postfix, Exchange) будет иметь встроенную очередь. Это, вероятно, сделает лучшую работу, чем вы, чтобы убедиться, что доставка произойдет, когда произойдет неожиданное. При обработке электронной почты, находящейся в очереди, есть над чем подумать. Обычно я предпочитаю передавать исходящую электронную почту MTA как можно раньше.

-
BMB

Answer 6

Это хорошая идея? да

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

Answer 7

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

Одна из причин в том, что, как вы описываете сами, если многие пользователи запрашивают отправку электронных писем, а очередь накапливается, у одного cronjob не будет времени на финиш до статистики ext ext, и вы рискуете получить ваша система заполнена процессами.