实施电子邮件通知
我有一个 Web 应用程序，用户可以在其中创建主题并对其他主题发表评论（类似于我们在 stackoverflow 上的内容）。我希望能够向参与讨论的用户发送通知。
我知道最简单的方法是将通知挂接到用户与讨论交互时执行的脚本。尽管这看起来很简单，但我相信这不是最合适的方式，因为用户需要等待所有电子邮件通知（通知脚本完成执行）发送，直到他获得操作的状态。
我知道的另一种选择是使用 cronjob 安排通知脚本的执行。为了使通知具有相关性，脚本将被安排每 3 到 7 分钟执行一次，以确保用户在合理的时间内收到通知。
现在我担心的是，考虑到我的应用程序仍在共享托管平台上运行，设置 cronjob 每 3 分钟运行一个脚本是否会消耗合理的系统资源？
另外，我认为是否有可能出现这样的情况：评论脚本将触发或通知通知脚本，以将通知发送到指定的电子邮件地址，同时评论脚本继续执行，而不必等待通知脚本完成。如果这可以实现，那么我想这对我来说将是最好的选择。
非常感谢您抽出时间。
I have a web application where users can create topics and also comment on other topics (similar to what we have here on stackoverflow). I want to be able to send notifications to participating users of a discussion.
I know the easiest way to go about it is to hook the notification to the script executed when a user interacts with a discussion. In as much as that seems very easy, I believe its not the most appropriate way as the user will need to wait till all the emails notifications (notification script finishes execution) are sent till he gets the status of his action.
Another alternative I know of is to schedule the execution of the notification script using cronjob. In order for the notification to be relevant, the script will be scheduled to execute every 3 to 7 minutes so as to make sure the users get notification in a reasonable time.
Now my concern is, will setting cronjob to run a script every 3 minutes consume reasonable system resource putting into consideration my application is still running on a shared hosting platform?
Also, am thinking is it possible to have a scenario where by the comment script will trigger or notify a notification script to send notifications to specified email addresses while the comment script continues it's execution without having to wait for the completion of the notification script. If this can be achievable, then I think it will be the best choice for me.
Thank you very much for your time.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除非您的通知脚本非常消耗资源，并且每次运行时都会发送数十或数百条消息，否则我不会担心在共享主机上每 3-7 分钟安排一次。事实上，如果您将其安排为 3 分钟，但发现网站性能下降，请将其增加到 4 分钟，以减少 25% 的资源。但这不太可能成为问题。
至于启动后台进程，您可以通过系统调用
exec()来实现。我会引导您访问这个问题以获得一个很好的答案。Unless your notification script is enormously resource-intensive and sends dozens or hundreds of messages out on each run, I would not worry about scheduling it every 3-7min on a shared host. Indeed, if you scheduled it for 3 minutes and found performance sagging on your site, then increase it to 4min for a 25% reduction in resources. It's pretty unlikely to be a problem though.
As far as starting a background process, you can achieve that with a system call to
exec(). I would direct you to this question for an excellent answer.IMO 为每个“讨论交互”添加一个“钩子”是迄今为止最简洁的方法，避免让用户等待的一个技巧是在 HTTP 响应中发回 Content-Length 标头。行为良好的 HTTP 客户端应该读取指定数量的八位字节，然后关闭连接，因此，如果您使用正确的 Content-Length HTTP 标头发回“状态”响应（并设置ignore_user_abort），那么最终用户将不会请注意，您的服务器端脚本实际上仍在继续其愉快的方式，在退出之前生成电子邮件通知（甚至可能持续几分钟）。
IMO adding a "hook" to each "discussion interaction" is by far the cleanest approach, and one trick to avoid making users wait is to send back a Content-Length header in the HTTP response. Well-behaved HTTP clients are supposed to read the specified number of octets and then close the connection, so if you send back your "status" response with the proper Content-Length HTTP header (and set ignore_user_abort) then the end user won't notice that your server-side script actually continues on its merry way, generating email notifcations (perhaps even for several minutes) before exiting.