我有一个当前正在发送电子邮件的Web应用程序。当时我的web应用程序发送电子邮件（发送电子邮件是基于用户操作 - 不是自动的），它必须运行其他过程，如压缩文件。Web应用程序体系结构：未来打样
我试图让我的应用程序“未来证明” - 所以当有大量的用户我不希望服务器紧张，所以我认为把需要发送的电子邮件和文件需要在队列中压缩。将它们放在表格中，然后使用cron作业检查每一秒并执行它们（一次一行x行）。
以上是一个好主意吗？还是有更好的方法？我真的需要帮助，得到这个得当，保存以后自己头疼的:)
感谢所有
这是一个很好的方法，但你现在所能做的最重要的事情是有排队界面清晰消息，以及消耗队列的消息。不要将两端的用法硬编码到数据库。
稍后，如果这成为一个瓶颈，您可能希望邮件发送是从另一台机器完成的，而这台机器甚至可能无法访问数据库，所以这个小小的投资将在稍后为您提供选项。
您可能忽略的一个方面是您正在使用的压缩速度，在压缩过程中使用较低的压缩级别可能会使您的利益最大化，因为这可以大幅改进压缩时间（容易加倍）当你进入多个用户的领域时，总计很多。
如果您在压缩大型已压缩文件（MP3，ZIP，DOCX，XLSX，JPG，GIF等）时使用智能压缩并且不使用压缩，并且在使用简单文本文件时使用高压缩（TXT，XML，DOC，XLS等），因为即使压缩比较大，它们的压缩速度也非常快。
啊，谢谢你，伟大的洞察力。我会研究这个！ – Abs 2009-01-22 18:58:10
重要的一点可能是，不是每秒钟运行一次cron作业，而是有一个始终运行的守护进程，它会在退出时自动重启 - 或者类似的情况。
其中一个原因是，就像你自己描述的那样，如果很多用户请求发送邮件并建立队列，一个cronjob在分机之前没有时间来芬兰语，让系统充斥着进程。
以上是一个好主意吗？是的
有没有更好的解决方案来处理数以百万计的用户？可能......但那不重要。重要的是你已经建立了抽象层。如果有一天你有疯狂的流量，并且你的cron队列没有跟上，你可以替换该层的功能而不用改变任何使用它的代码。
嗯。我不太喜欢cron每秒钟运行一些东西的想法。这似乎太频繁。如果你的应用程序真的需要这种响应，那么我认为你应该保持它的同步。也就是说，将处理保留在您的Web应用程序中，并寻找其他方法来保持服务器应变级别下降。
如果您可以在检查之间等待更长时间，那么最好让您的cron作业一次检查一个项目的队列。如果有，处理它，然后再检查下一个没有退出。如果没有，退出并且不要再等五分钟左右。
然而，所有的说法，任何体面的邮件传输代理（sendmail，postfix，Exchange）都会有内置的队列。如果发生意外情况时确保交货，它可能会做得更好。在处理排队的电子邮件时有很多事情要考虑。我一般都希望尽早将流出的电子邮件转交给MTA。
-
BMB
建立的东西，它的分布式队列。当您扩展卷时，可以缩放可能出现瓶颈的层的不同层。
是否有理由每秒运行cron？音量高吗？我会说尽力保持它是一个n层实现，因为你会交换事物，并重新构造它们，因为它们争取你的注意力。
尽量不要构建你设计了几周的任何东西。通常情况下，其他情况会在你锁定之前找到你。
好的方法。一些改进：
以我的经验，这将很好地扩展。
我看到，保持松散的界面非常重要，除了数据库之外，当您谈论让另一台服务器发送邮件时，我可以使用哪些其他内容？ – Abs 2009-01-22 18:57:38
你可以使用一个消息队列系统，你可以追加到一个_different_ DB，该插件被优化用于这种插入/删除行为，而不会增加你的其他数据库的负担，你可以将它缓存在内存中并刷新到随后消耗的文件 - 真的，你只是保持你的选择开放。 – orip 2009-01-22 19:01:58
好的，谢谢你的澄清。真的很感谢你:) – Abs 2009-01-22 19:07:04