我有一个当前发送电子邮件的 Web 应用程序。在我的 Web 应用程序发送电子邮件时（发送电子邮件是基于用户操作 - 不是自动的），它必须运行其他进程，例如压缩文件。
我正在尝试使我的应用程序“面向未来” - 所以当有大量用户时，我不希望服务器紧张，所以我认为放置需要发送的电子邮件和需要压缩的文件在队列中。将它们放在表中，然后使用 cron 作业每秒检查一次并执行它们（一次 x 行）。
以上是个好主意吗？还是有更好的方法？我真的需要帮助才能正确完成这项工作，以免以后让自己头疼:)
谢谢大家
7 回答
6
这是一个很好的方法，但是您现在可以做的最重要的事情是有一个用于排队消息的清晰界面，以及一个用于消费队列的界面。不要将两端的用法硬编码到数据库中。
稍后，如果这成为瓶颈，您可能希望从甚至可能无法访问数据库的不同机器上完成邮件发送，因此前期的这笔小额投资将为您提供以后的选择。
于 2009-01-22T18:20:09.303 回答
2
您可能忽略的一个方面是您使用的压缩速度，在压缩过程中使用较轻的压缩级别可能符合您的最大利益，因为这可以大大改善压缩时间（很容易加倍），这可以加起来当您进入多个用户的领域时会很多。
如果您在压缩已压缩的大型文件（MP3、ZIP、DOCX、XLSX、JPG、GIF 等）时使压缩变得智能并且不使用压缩，而当您有简单的文本文件（TXT、XML 、DOC、XLS 等），因为即使是重度压缩，它们也会很快压缩。
于 2009-01-22T18:28:11.923 回答
1
重要的一点可能是，与其让 cron 作业每秒运行一次，不如让一个始终运行的守护进程在退出时自动重新启动 - 或类似的东西。
一个原因是，正如您自己描述的那样，如果很多用户要求发送电子邮件并且队列建立起来，那么一个 cronjob 将没有时间在 ext one 统计之前完成，并且您有可能让您的系统被淹没与流程。
于 2009-01-22T18:48:10.247 回答
1
以上是个好主意吗？是的
是否有更好的解决方案来处理未来数百万用户？可能..但这不是重要的。重要的是您已经构建了抽象层。如果有一天你有疯狂的交通并且你的 cron 队列没有跟上你可以替换该层的功能而不更改任何使用它的代码。
于 2009-01-22T19:16:39.580 回答
1
唔。我真的不喜欢 cron 每秒运行一些东西的想法。这似乎太频繁了。如果您的应用程序确实需要响应，那么我认为您应该保持同步。也就是说，将处理保留在您的 Web 应用程序中，并寻找其他方法来降低服务器压力。
如果您可以在检查之间等待更长的时间，那么最好让您的 cron 作业一次检查队列中的 1 个项目。如果有，则处理它，然后在不退出的情况下再次检查下一个。如果没有，请退出，五分钟左右不要再试一次。
然而，话虽如此，任何体面的邮件传输代理（sendmail、postfix、Exchange）都将内置队列。它可能会比您确保在意外发生时进行交付做得更好。在处理排队的电子邮件时需要考虑很多事情。我通常更愿意在此过程中尽早将出站电子邮件移交给 MTA。
--
bmb
于 2009-01-27T02:26:25.287 回答
1
构建一些可以进行分布式排队的东西。当您扩展卷时，您可以扩展可能出现瓶颈的层的不同层。
有理由每秒运行 cron 吗？音量有那么大吗？我想说尽你最大的努力让它保持一个 n 层的实现，因为你会在它们争夺你的注意力时交换东西和重构比特。
在几周内尽量不要构建任何你设计的东西。通常，在事情被锁定之前，您会遇到其他情况。
于 2009-01-27T02:31:00.127 回答
1
好办法。一些改进：
- 不要使用 cron 作业，而是在计时器上查询。
- 包括一个状态标志以保持多个读取器/写入器排序。
- 读者应该排空队列 - 在队列读取为空之前不要阻塞。
- 把事情简单化。将复杂性和微妙性放入作者/读者的对话中。
根据我的经验，这将很好地扩展。
于 2009-01-27T02:38:48.600 回答