我有一个web应用程序，用户可以创建主题，也可以评论其他主题(类似于我们在这里的stackoverflow)。我希望能够向参与讨论的用户发送通知。
我知道最简单的方法是将通知挂钩到用户与讨论交互时执行的脚本。虽然这看起来很简单，但我认为这不是最合适的方式，因为用户需要等待所有的电子邮件通知(通知脚本完成执行)发送，直到他得到他的操作状态。
我知道的另一种方法是使用cronjob调度通知脚本的执行。为了使通知具有相关性，脚本将被安排每3到7分钟执行一次，以确保用户在合理的时间内获得通知。
现在我担心的是，设置cronjob每3分钟运行一个脚本是否会消耗合理的系统资源，考虑到我的应用程序仍然运行在共享主机平台上?
另外，我认为是否有可能有一个场景，其中由评论脚本将触发或通知通知脚本发送通知到指定的电子邮件地址，而评论脚本继续它的执行，而不必等待通知脚本的完成。如果这是可以实现的，那么我想这将是我最好的选择。
非常感谢您的宝贵时间。除非您的通知脚本非常占用资源，并且每次运行时发送数十或数百条消息，否则我不会担心在共享主机上每3-7分钟调度一次。实际上，如果您将其安排为3分钟，并且发现站点上的性能下降，那么将其增加到4分钟，以减少25%的资源。不过这不大可能是个问题。
至于启动后台进程，您可以通过对exec()的系统调用来实现。我建议你直接问这个问题，你会得到一个很好的答案。
在每个"讨论交互"中添加一个"钩子"是迄今为止最干净的方法，避免让用户等待的一个技巧是在HTTP响应中发回一个Content-Length头。行为良好的HTTP客户端应该读取指定的字节数，然后关闭连接，所以如果您发送回带有适当的Content-Length HTTP头(并设置ignore_user_abort)的"状态"响应，那么最终用户不会注意到您的服务器端脚本实际上继续它的快乐方式，在退出之前生成电子邮件通知(可能甚至几分钟)。