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

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

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

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

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

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

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

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

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

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

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

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

--
bmb

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

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

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

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

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

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