我在Google App Engine上构建了一些内容,作为iPhone应用的后端。在应用程序中,有些交互通过其API推送到社交网络。所以典型的工作流程是这样的:
那么处理这个问题的好方法是什么?根据问题的性质,我喜欢将它包装在“交易”中,但是没有办法回滚发送到社交网络的内容。那么,我正在考虑如何处理DatastoreTimeException?我应该将它包装在try块中再给它一次吗?向用户显示错误是一个更好的主意,然后当他们再次尝试时,“跳过”社交网络交互,以便它不被推出两次?还有另一个想法,我没想到这里吗?
答案 0 :(得分:1)
“当您尝试放置,获取或删除太多实体或具有太多属性的实体,或者数据存储过载或出现问题时,可能会发生这种情况。”
如果您经常看到异常,我预计这是因为数据存储区操作太大,因此重试并不会对您有所帮助。如果您只是针对可能引发异常的风险进行防御性编码,那么您可以再次尝试(可能通过排队将执行此操作的任务。但如果您无法访问数据存储区,那么可以说您可以排队任务?)
如果你想要坚固耐用,并且你可以确保你在社交网络上执行的操作是幂等的(可以重复),那么:
当然,您必须对回馈给iPhone客户端的响应代码保持谨慎,因为成功可能需要长时间 - 比iPhone的请求持续时间更长应用程序。所以你希望你的应用引擎请求也是幂等的,你可能想要某种取消。
如果您从社交网络获得的是成功或失败,并且如果成功,则不得重复操作,那么您就遇到了麻烦。这是在网络上提供的垃圾API,因为只是因为Web服务器向您发送成功的响应并不意味着您已收到它,因此即使成功创建了责任,调用者也无法知道他们已成功。但它确实发生了。
答案 1 :(得分:0)
我觉得这句话令人担忧: 在实践中,重试通常是成功的;即使是小型操作,您也会定期获得数据存储区超时。 - Wooble 1月23日14:59
如果有可靠性问题,如何认真对待GAE?通常你发现数据存储区很慢吗?您对这些例外频率的估计是什么?
答案 2 :(得分:0)
这是任何分布式系统的基本问题。一般来说,没有简单的“防弹”解决方案。如果可能,最好的选择是确保您的一个或两个操作都是幂等的 - 也就是说,多次执行它们都没有效果。对于数据存储区,这非常简单:如果指定键名,则多个puts将简单地相互覆盖。如果可能的话,你也应该在社交API中使用幂等性,这样你就可以在失败的情况下安全地重新执行。