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

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

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

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

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

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

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

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

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

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

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

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

-
bmb

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

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

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

Хороший подход. Некоторые доработки:

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

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