Azure 表存储 API 是否缓存结果？
当我对 Azure 表存储多次运行相同的查询时，它是否使用缓存并加速后续查询？
换句话说，它是否缓存 HTTP 响应？
When I run the same query multiple times against the Azure table storage, is it using caching and speeding up the subsequent queries?
In other words, is it caching the HTTP response?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Azure 存储明确使用缓存： http://www.scribd.com/doc/73458371/Windows-Azure-Storage-at-23rd-ACM-Symposium-on-Operating-Systems-Principles-SOSP-Paper
请注意，写入实际上保存在内存中，直到正确复制为止，并且我认为可以安全地假设任何读取也都被缓存，以便从内存中提供对同一数据的多次读取。
Azure storage definitly use caching: http://www.scribd.com/doc/73458371/Windows-Azure-Storage-at-23rd-ACM-Symposium-on-Operating-Systems-Principles-SOSP-Paper
Note that writes are actually kept in memory until correctly replicated and I think it's safe to assume that any reads are cached too so that multiple reads to the same data are served from memory.
虽然我显然不了解内部情况：
当您发送作用于或返回单个实体的请求时，Azure 存储将根据 ETag 标头发出 HTTP 304。不过，根据您所在的学校，这可以被视为正式缓存。除此之外，Azure 提倡即时（或更准确地说是“乐观”）并发，因此更积极的缓存是不明智的。 （缓存验证等开销将使乐观并发几乎不可能）。
在 ETag/HTTP 交换之外，我假设开发人员的意图是在消费数据的客户端中实现更积极的缓存/
While I am obviously not privy to the internals:
Azure Storage will issue HTTP 304 based on the ETag headers when you send requests that act upon or return a single entity. Depending on your school of though, that can been seen as formal caching. Outside of that, Azure promotes instant (or more correctly "Optimistic") concurrency, so more aggressive caching would not be prudent. (Cache validation,etc overhead would make optimistic concurrency near impossible).
Outside of the ETag/HTTP exchange, I would assume the intent to be that the developer implement more aggressive caching in the client(s) that are consuming the data/