Google App Engine：Memcache 还是静态变量？
好吧，我想我在这里有一个非常基本的疑问：
我正在 GAE (Java) 上开发一个应用程序并对返回很多数据的数据存储执行查询 实体，所以我需要缓存它。 我使用的是 memcache，它工作得很好，但如果我将实体列表保存在静态变量中，整个请求的速度比使用 memcache 快两倍。 我认为这是因为我没有一直反序列化实体。
在内存缓存上使用静态变量有什么缺点？ 我不知道云中是否有我的应用程序的多个实例，因此我的静态变量也有多个实例？
我尝试缓存的实体列表是上周最好的（得分较高）帖子。 我从该列表中随机选择 5 个帖子，并将它们显示在几页中。
谢谢您的帮助！
Well, I think I have a very basic doubt here:
I'm developing an app on GAE (Java) and performing a query to the datastore that returns a lot
of entities, so I need to cache it. I was using memcache and it was working great, but if I keep the list of entities in a static variable, the whole request goes as twice as fast than using memcache. I think that's because I'm not deserializing the entities all the time.
What would be the drawback of using a static variable instead on memcache? I don't know if there could be several instances of my application in the cloud, and thus several instances of my static variable?
The list of entities I'm trying to cache are the best (greater score) posts of the last week. I take that list and choose 5 random posts and show them in a couple of pages.
Thanks for the help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
随着点击应用程序的用户数量的增加，App Engine 通过创建应用程序的新实例来进行扩展。 正如 drudru 所说，不同的用户可能由不同的实例提供服务。 一般来说，memcache 是存储您想要全局一致的内容的最快位置。 但是，就您的情况而言，可能还有一些改进的空间。
您提到您有一个帖子列表，并且您随机选择 5 个帖子向用户显示。 如果 2 个不同的用户看到不同的 5 个组，这有什么关系吗？ 如果您无论如何选择随机的，也许这并不重要。 然后，您可以将完整的帖子列表存储在 memcache 中，并从 memcache 中随机抽取 5 个帖子并将它们存储在静态变量中。
其次，您到底在内存缓存什么，以及如何将其取出？ 您是否将一大堆完整的帖子存储在内存缓存中，获取所有帖子，然后选择 5 个？ 也许您可以只下载帖子列表，选择 5 个，然后只获取您需要的 5 个？ 如果您认为反序列化会减慢您的速度，这可能会有所帮助。 收到帖子后你们会做一些处理吗？ 如果是这样，处理结果可以被缓存吗？
App Engine scales by creating new instances of your application as the number of users hitting it increases. As drudru said, different users might be served by different instances. In general, memcache is the fastest place to store something you want to be globally consistent. However, in your case there may be some room for improvement.
You mention you have a list of posts and you randomly choose 5 to show to users. Does it matter if 2 different users see a different set of 5? If you're choosing random ones anyway, maybe it doesn't matter. Then you could store the full list of posts in memcache, and pull 5 random ones out of memcache and store them in a static variable.
Second, what exactly are you memcaching, and how are you pulling it out? Are you storing a whole bunch of full posts in memcache, getting them all, then choosing 5? Maybe you could just download the list of posts, choose 5, and only get the 5 you need? If you think it's the deserializing that's slowing you down, this might help. Are you doing any processing on the posts after you get them? If so, could the results of that processing be cached?
当下一个请求到来时，你不能依赖静态变量（或 JVM 内存中的其他任何东西），因为 Google 可以在需要时自由地启动和停止虚拟机。 从表面上看，他们似乎更喜欢启动额外的 JVM，而不是在同一个 JVM 中启动额外的线程，这使得这个问题变得更加复杂。
但是，您应该能够使用静态变量作为缓存层，前提是您有办法在数据消失时从其他地方加载数据。
我也不会尝试过度使用内存，必须有一个可以使用多少内存的配额。
You cannot rely on static variables (or anything else in JVM memory) to be around when the next request hits, because Google is free to start and stop virtual machines when they feel like it. From the looks of it, they seem to prefer to start additional JVMs instead of additional threads in the same JVM, which compounds this issue.
But, you should be able to use static variables as a cache layer, provided you have a way to load the data from somewhere else if it went away.
I would also not try to go overboard with memory usage there, there must be a quota on how much memory you can use.
是的，不能保证您的实例对于互联网上的各个用户来说都是相同的。 在最坏的情况下，你最终可能会不断地将其读入静态。 memcache的可用保证更高。 我只会使用内存缓存，并且您的应用程序将来应该不会出现任何规模问题。
Yeah, there is no guarantee that your instance will be the same for various users on the internet. You could end up constantly reading this into a static in the worst case. The memcache has a higher guarantee of being available. I would just use the memcache, and your app should not have any scale issues in the future.