想要使用 swift mailer 为大约 18000 个电子邮件收件人开发一个新闻通讯发送系统
我想使用 Swiftmailer 开发一个新闻通讯发送系统。我想知道:
1)我需要为此设置一个 cron 作业吗?
2) Batchsend()
或带有 loop
的 Send()
,哪个更好(我希望每个地址都在“To”字段中)?
I would like to develop a newsletter sending system using Swiftmailer. I would like to know:
1) Do I require to set a cron job for this ?
2) Batchsend()
or Send()
with a loop
, which one is better ( I want each address to be in To field ) ?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
关于第一个问题;最好创建脚本来发送收件人列表中的下 x 封电子邮件,并重复调用它,直到处理完所有收件人为止。您需要跟踪数据库中处理的对象,并在失败时引入错误处理;对于每个用户来说,一个好的策略是:
这样您就可以看到最终有多少人失败了(即那些仍然被标记为“正在处理”的人)。
为了重复这个过程,你可以使用 CRON 并每分钟重复一次;但是,如果发送时间超过 1 分钟(例如,由于 SMTP 连接速度较慢),那么您将有两个进程一起运行,因此您要么需要阻止这种情况,要么引入某种锁定(上面将用户标记为“的示例”)处理”将阻止脚本的两个并发实例处理同一个人)。
每分钟 CRON 的另一个问题是,您可能需要很长时间才能发送所有电子邮件。我遇到了这个问题,所以我写了 The Fat Controller 来为你处理并行处理和重复。我制作了一个简单的 shell 脚本,每天由 CRON 启动并运行 Fat Controller,然后运行 PHP 发送脚本的许多实例。以下是一些用例和更多信息:
http://fat-controller.sourceforge.net/ use-cases.html
关于你的第二个问题;我不确定 Swift 邮件程序的内部结构,但您需要打开 SMTP 连接,发送电子邮件,然后关闭它 - 这样您就不会为每封电子邮件打开和关闭连接。检查文档,我以前使用过 Swift,它运行得很好并且有非常清晰的文档。
With regards to the first question; it's best to create the script to send the next x emails from the recipients list and call it repetitively until all the recipients have been processed. You'll need to keep track of who's been processed in the db and introduce error handling in case it fails; a good strategy is for each user:
This way you can see how many people failed at the end (i.e. those who still are marked as "processing").
In order to repeat the process you could use CRON and repeat every minute; but what if the sending takes over 1 minute (e.g. due to slow SMTP connection) then you'll have two processes running together so you'll either need to prevent this or introduce some sort of locking (the above example of marking users as "processing" will prevent two concurrent instances of the script from processing the same people).
The other problem with CRON every minute is that it might take you ages to send all your emails. I had this exact problem and so I wrote The Fat Controller which handles parallel processing and repeating for you. I made a simple shell script which is started every day by CRON and runs The Fat Controller which then runs many instances of the PHP sending script. Here are some use cases and more information:
http://fat-controller.sourceforge.net/use-cases.html
With regards to your second question; I'm not sure of the internals of Swift mailer, but you'll want to open an SMTP connection, send emails, then close it - so you're not opening and closing a connection for each email. Check the documentation, I've used Swift before and it worked very well and had very clear documentation.
我知道离题,但可能有用:
您是否考虑过使用电子邮件通讯提供商,例如 http://mailchimp.com/?显然涉及成本,但您必须将其与自己开发、运行和维护它的成本进行比较。
如果您的一些用户认为您的邮件是垃圾邮件(无论您多么彻底地获得同意,这种情况肯定会发生),那么您很容易进入黑名单,这将严重阻碍您的邮件。大型提供商被列入黑名单的可能性要小得多,因为它们是公认的合法群发邮件发送者。他们还将负责取消订阅管理。
编辑:我与 MailChimp 没有任何关系。这只是我用过的一款。
Off topic I know, but possibly useful:
Have you considered using an email newsletter provider such as http://mailchimp.com/? There's a cost involved obviously, but you have to compare that to the cost of developing and running it yourself, and maintaining it.
If a few of your users decide that your mail is spam, which is guaranteed to happen, regardless of how thoroughly you have obtained consent, then you could easily get onto blacklists, which will seriously impede your mail. The big providers are much less likely to get blacklisted, as they're recognised legitimate mass mailers. They'll also take care of unsubscribe management.
Edit: I am in no way affiliated with MailChimp. It's just the one I've used.
send()
是首选。事实上,batchSend()
已被删除。构建一个循环并手动发送它们。send()
is preferred. In fact,batchSend()
has been removed. Construct a loop and send them all manually.我对 ERP 应用程序中的通知执行类似的操作,基本上是自定义电子邮件。
我这样做的方法是使用 Gearman,并将所有要发送的电子邮件排队,然后让 Gearman 工作人员执行实际发送。这样,您就可以让多个工作人员发送电子邮件,并且前端不会锁定等待每封电子邮件的发送。
I do a similar thing for notifications in an ERP application, customised emails basically.
The way I do this is to use Gearman, and queue all the emails to be sent, then have a Gearman worker to do the actual sending. That way you can have multiple workers sending the emails and the front-end doesn't lock up waiting for each email to be sent.