Web應用程序架構：未來打樣

Question

我有一個當前發送電子郵件的Web應用程序。 當我的Web應用程序發送電子郵件（發送電子郵件是基於用戶操作 - 不是自動的）時，它必須運行其他過程，如壓縮文件。

我正在努力使我的應用程序“面向未來” - 所以當有大量用戶時我不希望服務器緊張，所以我認為需要發送需要發送的電子郵件和需要壓縮的文件在隊列中。 將它們放在表中，然后使用cron作業檢查每一秒並執行它們（一次x行）。

以上是個好主意嗎？ 還是有更好的方法？ 我真的需要幫助才能正確完成這項工作，以便以后節省我的頭痛:)

謝謝大家

Answer 1

這是一個很好的方法，但你現在可以做的最重要的事情是有一個清晰的界面來排隊消息，一個用於消耗隊列。 不要將兩端的用法硬編碼到DB。

稍后，如果這成為瓶頸，您可能希望從另一台甚至無法訪問數據庫的計算機上完成郵件發送，因此這項微小的投資可以在以后為您提供選項。

Answer 2

您可能忽略的一個方面是您正在使用的壓縮速度，在您的zip過程中使用較輕的壓縮級別可能符合您的最佳利益，因為這可以大大改進拉鏈時間（輕松加倍），這可以增加到當你進入多個用戶的領域時很多。

如果你使用壓縮文件（MP3，ZIP，DOCX，XLSX，JPG，GIF等）並且在使用簡單文本文件時使用高壓縮（TXT，XML ，DOC，XLS等）因為它們即使在高壓縮下也會非常快速地拉鏈。

Answer 3

重要的一點是，不要讓cron作業每秒運行一次，而是讓一個始終運行的守護進程在退出時自動重啟 - 或類似的東西。

一個原因是，就像你自己描述的那樣，如果很多用戶要求發送電子郵件並且隊列建立起來，那么一個cronjob將沒有時間在ext ext stats之前進行芬蘭語，並且你冒着系統泛濫的風險與流程。

Answer 4

以上是個好主意嗎？ 是

有沒有更好的解決方案來處理數百萬用戶？ 可能......但那並不重要。 重要的是你已經構建了抽象層。 如果有一天你有瘋狂的流量，你的cron隊列沒有跟上，你可以替換該層的功能，而無需更改任何使用它的代碼。

Answer 5

嗯。 我真的不喜歡cron每秒運行一些東西的想法。 這似乎太頻繁了。 如果您的應用程序確實需要響應，那么我認為您應該保持同步。 也就是說，將處理保留在Web應用程序中，並尋找其他方法來降低服務器應變水平。

如果您可以在檢查之間等待更長時間，那么讓您的cron作業一次檢查1個項目的隊列會更好。 如果有，請對其進行處理，然后再次檢查下一個而不退出。 如果沒有，退出並且不要再試五分鍾左右。

但是，所有這一切，任何像樣的郵件傳輸代理（sendmail，postfix，Exchange）都將內置排隊。 它可能比確保在意外發生時確保交付時做得更好。 在處理排隊的電子郵件時需要考慮很多事情。 我通常喜歡盡可能早地將出站電子郵件發送到MTA。

-
BMB

Answer 6

構建分布式排隊的東西。 縮放卷時，您可以擴展層的不同層，從而可能出現瓶頸。

是否有理由每秒運行一次cron？ 音量那么高嗎？ 我會說盡力保持它是一個n層實現，因為你會交換進出的東西並重構位，因為它們會引起你的注意。

嘗試不要在幾周內構建任何你設計的東西。 在事情被鎖定之前，通常會遇到其他情況。

Answer 7

好方法。 一些改進：

1. 不要使用cron作業，而是在計時器上查詢。
2. 包含狀態標志以保持多個讀取器/寫入器的排序。
3. 讀取器應該排空隊列 - 在隊列讀取為空之前不要阻塞。
4. 把事情簡單化。 將復雜性和微妙性融入作家/讀者對話中。

根據我的經驗，這將很好地擴展。