如何在App Engine上实现轻量级的发布订阅服务？
在他的 Google I/O 2009“App Engine 离线处理：展望”演讲中（视频< /a>、幻灯片），Brett Slatkin 介绍任务队列服务。
他指出
发布-订阅系统最大化交易，解耦：
- 每秒处理大量小事务
- 一对多扇出并更换接收器
- 保证排序、过滤、两阶段提交
并且特别强调
我们的新 API 实现了队列，而不是发布-订阅
我只对这些功能的一个子集感兴趣：
更改选定/固定内部的一对多扇出接收处理程序保证排序、过滤、两阶段
提交 目标是简化同一 Web 应用程序的不同模块之间通知/消息的发布。示例使用场景如下：
- 使支付模块了解账单的接收。
- 使用户能够跟踪他决定关注/加注星标的特定域对象的更改。
在任务队列服务之上实现这些的正确方法是什么？
During his Google I/O 2009 "Offline processing on App Engine: A look ahead" presentation (video, slides), Brett Slatkin presents the Task Queue service.
He states that
Pub-sub systems maximize transactions, decoupling:
- Large numbers of small transactions per second
- One-to-many fan-out with changing receivers
- Guaranteed ordering, filtering, two-phase commit
And specifically emphasises
Our new API implements queueing, not pub-sub
I'm interested in only a subset of those functionalities:
- One-to-many fan-out with
changingselected/fixed internal receiver handlers Guaranteed ordering, filtering, two-phase commit
Targeted goal would be to ease publishing of notifications/messages between different modules of the same web application. Sample usage scenarios cases would be:
- Making the payment module aware of receivals of bills.
- Making a user able to track changes of a particular domain object he has decided to follow/star.
What would be the correct way to implement these on top of the Task Queue service ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
考虑使用Cloud Pub/Sub。它是内部 Pub/Sub 技术的外部化版本，该技术已在 Google 内部广泛使用了大约 7 年，并被证明具有可扩展性和稳健性。截至今天，它仍处于测试阶段，但我们很快就会推出 GA（几个月后）。
Consider using Cloud Pub/Sub. It's the externalized version of the internal Pub/Sub technology, which has been used extensively within google for about 7 years and proven to be scalable and robust. As of today it's still beta, but we're going to GA soon (in few months).