用于运行 Zend Queue Receiver 的基础设施
我有一个简单的消息队列设置并使用 Zend_Queue 对象层次结构运行。我正在使用 Zend_Queue_Adapter_Db 后端。我有兴趣将其用作作业队列，以安排稍后处理的事情。这些工作不需要立即发生，但应该尽早发生。
是否有最佳实践/标准方法来设置基础设施来运行作业？我了解从队列接收消息的代码，但我不太清楚如何运行接收消息的程序。一个在命令行上接收 n 条消息的 cron，每分钟运行一次？一个 cron 会触发多个 Web 请求，每个 Web 请求都运行接收器脚本？还有别的事吗？
切向奖金问题。如果我使用 Zend_Db 运行其他查询，消息队列查询是否会被视为该事务的一部分？
I have a simple messaging queue setup and running using the Zend_Queue object heirarchy. I'm using a Zend_Queue_Adapter_Db back-end. I'm interested in using this as a job queue, to schedule things for processing at a later time. They're jobs that don't need to happen immediately, but should happen sooner rather than later.
Is there a best-practices/standard way to setup your infrastructure to run jobs? I understand the code for receiving a message from the queue, but what's not so clear to me is how run the program that does that receiving. A cron that receives n messages on the command-line, run once a minute? A cron that fires off multiple web requests, each web request running the receiver script? Something else?
Tangential bonus question. If I'm running other queries with Zend_Db, will the message queue queries be considered part of that transaction?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你可以像线程池一样做到这一点。创建一个命令行 php 脚本来处理接收。它应该由 shell 脚本启动，如果进程终止，该脚本会自动重新启动该进程。如果进程已在运行，则 shell 脚本不应启动该进程（使用 $pid.running 文件或类似文件）。让 cron 每 1-10 分钟运行几次。这应该可以很好地处理接收。
我不会让 cron 触发网络请求，除非你的 cron 由于某种奇怪的原因位于另一台服务器上。
使用它的另一种方法是让一些后台进程创建数据，并且网络用户在自然浏览网站时使用它。报告生成器可能会以这种方式工作。公司范围内的报告可供所有用户使用，但您不希望他们全部生成此数据库/时间密集型报告。因此，您创建一个队列并一次处理一个队列，可能会删除重复项。准备好后，所有用户都可以查看报告。
根据文档 看起来 zend db 甚至没有使用与其他 zend_db 查询相同的连接。但当然，找出答案的最佳方法是进行一个简单的测试。
编辑
cron 中的多行用于并发。每行代表池中的一个工作人员。我不清楚，你不希望 pid 作为标识符，你想将其作为参数传递。
如果发现 $process.running 文件退出，bash 脚本将检查该文件。
否则：
这允许 php 脚本终止，但不会导致池释放工作线程。
如果队列为空，则 php 脚本立即退出，并通过下一次调用 cron 再次启动。
You can do it like a thread pool. Create a command line php script to handle the receiving. It should be started by a shell script that automatically restarts the process if it dies. The shell script should not start the process if it is already running (use a $pid.running file or similar). Have cron run several of these every 1-10 minutes. That should handle the receiving nicely.
I wouldn't have the cron fire a web request unless your cron is on another server for some strange reason.
Another way to use this would be to have some backround process creating data, and a web user(s) consume it as they naturally browse the site. A report generator might work this way. Company-wide reports are available to all users but you don't want them all generating this db/time intensive report. So you create a queue and process one at a time possible removing duplicates. All users can view the report(s) when ready.
According to the docs it doens't look like the zend db is even using the same connection as your other zend_db queries. But of course the best way to find out is to make a simple test.
EDIT
The multiple lines in the cron are for concurrency. each line represents a worker for the pool. I was not clear, you don't want the pid as the identifier, you want to pass that as a parameter.
The bash script would check for the $process.running file if it finds it exit.
otherwise:
This allows for the php script to die but not cause the pool to loose a worker.
If the queue is empty the php script exits immediately and is started again by the nex invocation of cron.