Google App Engine 数据库不一致答案

【问题标题】：Google App Engine database inconsistencyGoogle App Engine 数据库不一致
【发布时间】：2010-10-16 20:53:27
【问题描述】：

我正在 Google App Engine 中编写一个 twitter 应用程序。它接受命令作为直接消息，因此我设置了第三方 cronjob 服务来调用定期处理 DM 的处理程序。我有一个只有一个条目的模型“信息”，它存储了一些在应用程序的许多地方使用的通用数据（在这种情况下，是最近处理消息的时间）。我的处理程序的一般模式是这样的：

class Info(db.Model):
    msg_polled = db.DateTimeProperty(auto_now_add = True)
    .... More Properties ....

    @classmethod
    def get_info(cls):
        info = cls.all().get()
        if not info:
            info = cls()
            info.put()
        return info
---------------------------------------------------------
info = Info.get_info()
msgs = api.GetDirectMessages(since = info.msg_polled)
if not msgs:
    return
logging.info('Processing Messages since %s ' % str(info.msg_polled))
for msg in msgs:

    ...process commands...

    logging.info('Processed Message :- @%s : %s' % (msg.sender_screen_name, msg.text))

info.msg_polled = datetime.datetime.now()
info.put()

但有时我会得到这样的日志：

I 03-30 07:50AM 10.973
Processing Messages since Sun, 29 Mar 2009 11:41:59 GMT 
I 03-30 07:50AM 11.122
Processed Message :- @foo : Foo_Bar
-------------------------------------------------------
I 03-30 07:46AM 08.014
Processing Messages since Sun, 29 Mar 2009 11:41:59 GMT 
I 03-30 07:46AM 08.130
Processed Message :- @foo : Foo_Bar

在这里，似乎信息没有提交到数据库。消息被多次处理，有时在 msg_polled 值更改之前多达 10 次以上。但我没有收到任何数据存储异常。这种情况只会偶尔发生一次。

感谢任何帮助。

【问题讨论】：

您没有在示例中显示您最初是如何检索信息的。你能把它包括进去吗？
另外，第二组日志条目的日期早于第一组 - 这是故意的吗？
对不起，我也将其包括在内.. 是的，日志是按时间倒序排列的..
您的脚本是否可能在最后到达 put() 之前超时？我没有看到任何日志条目来确认情况并非如此。
no.. 我没有得到任何超时异常，这些是我得到的唯一日志

标签： google-app-engine twitter

【解决方案1】：

Google AppEngine 数据存储在后台使用 BigTable，这是一个分布式数据库系统。因此，更新可能不会立即可见，因为新数据尚未到达每个分布式表（亚马逊在其 SimpleDB 中称其为“最终一致性”）。几分钟后你应该就好了。

【讨论】：

但是文档没有提到任何这样的延迟。那么，减少 cronjob 的频率会解决问题吗？
我知道，我搜索了一些链接来支持我的故事，但可以找到任何链接。不过，我确定我在某处读过它。确实，降低频率会有所帮助。我建议你试一试，看看会发生什么。告诉我！
cronjob 当前每 4 分钟运行一次。你可以在日志时间戳中看到这一点。你不认为 4 分钟对于那种延迟来说有点太长了，即使是 SimpleDB 的最终一致性' 延迟是在几秒钟的顺序吧？
4 分钟听起来有点陡峭。不知道还有什么可能......对不起。

【解决方案2】：

以下是有关 GAE 数据存储区一致性的优秀文档：

https://cloud.google.com/developers/articles/balancing-strong-and-eventual-consistency-with-google-cloud-datastore

结论：

最终一致性是非关系型数据库的基本要素，它允许开发人员在可扩展性、性能和一致性之间找到最佳平衡。重要的是要了解如何处理最终一致性和强一致性之间的平衡，以便为您的应用程序设计最佳数据模型。在 Google Cloud Datastore 中，使用实体组和祖先查询是保证实体范围内高度一致性的最佳方式。如果您的应用程序由于前面描述的限制而无法合并实体组，您可以考虑其他选项，例如使用仅键查询或 Memcache。对于大型应用程序，应用最佳实践，例如使用分散的 ID 和减少索引以减少一致性所需的时间。将 Google Cloud Datastore 与 BigQuery 结合起来以满足复杂查询的业务需求并尽可能减少 Google Cloud Datastore 索引的使用可能也很重要。

【讨论】：