【发布时间】:2011-03-09 21:37:06
【问题描述】:
我今天读到了sharded counters in Google App Engine。文章说,您应该期望数据存储中每个实体每秒最多更新约 5 次。但在我看来,除非您有某种方式知道您每秒进行了多少更新,否则该解决方案不会“扩展”。例如,您可以分配 10 个分片,但随后会以每秒 50 次更新开始阻塞。
那么您如何知道更新的速度有多快,以及如何将该数字反馈到分片数量中?
我的猜测是,与计数器一起,您可以保留一些最近活动的记录,如果您检测到峰值,您可以增加分片的数量。一般是这样处理的吗?如果是这样,为什么不在示例代码中完成? (最后一个问题可能无法回答。)是否更常见的做法是监控网站活动并在流量增加时更新分片计数,而不是在代码中自动执行?
更新:碎片太少和窒息的实际后果是什么?这是否仅仅意味着网站变得无响应,或者是否有可能因为超时而丢失计数器更新?
顺便说一句,this question 谈到了在没有分片的情况下实现计数器,但其中一个答案暗示如果流量很高,即使 memcache 也需要分片。所以这个分片分配和调整问题似乎很重要。
【问题讨论】:
-
看看 memcache 方法在没有分片的情况下每秒可以处理多少更新会很有趣。 (目前,我似乎无法找到任何关于您可以多快更新给定内存缓存键的数字。)
-
我只是在学习这方面的知识,但从某种意义上说,memcache 是否不可靠,它可能随时会失效。
-
是的,memcache 值确实可以随时被驱逐。这通常是由于内存压力而发生的(尽管它可能由于其他原因而发生 - 例如 memcache 服务器出现故障)。这就是为什么基于 memcache 的解决方案可能会被低估的原因之一。
-
我认为更相关的问题是,如果有的话,选择太多分片有什么缺点?尝试实际获取当前总数时性能变慢?
-
@Peter Recore:我的理解是读快,写慢。此外,计数器值被 memcached 用于检索(但不更新)。
标签: google-app-engine sharding