Application-level Cache 调研问卷

应用程序级缓存(Application-level Cache)在当前互联网应用中承担了非常重要的角色。缓存的内容通常是应用程序后端被频繁调用的函数执行结果。这些函数通常需要访问数据库中的状态数据。由于数据库的访问代价高,应用程序级缓存可以有效减轻后端服务的压力,提升用户响应延迟。
然而,应用程序级缓存的使用并不是一个简单的问题。本次调研目的是明晰其在工业界真实应用中的使用情况,包括其部署和使用方式,以及开发人员遇到的棘手问题。

调研方为华东师范大学数据科学与工程学院,调研结果将被收集并用于学术研究,并发表在一篇公开的论文中。谢谢您的支持!

在这项研究中收集的所有信息都是保密的,在任何时候您的名字都不会被公开。您有权随时要求删除所提供的数据。

您有任何问题都可以随时联系我们(xzhou@dase.ecnu.edu.cn)。

*
您当前的主要身份是
软件开发者
系统架构师
运维人员
其他(请说明)
*
您在应用程序采用的开发语言是【多选题】
JAVA
Python
PHP
JavaScript
C#
其他(请说明)
*
您在应用程序端通常采用了哪些缓存管理框架【多选题】
Spring Cache
MyBatis Cache
Hibernate Cache
Django Cache
其他(请说明)
没有(请简要说明原因)
*
您采用了哪些缓存存储系统【多选题】
Redis
Memcache
Ehcache
其他(请说明)
*
您觉得哪些数据库查询结果可能有被缓存的必要?【多选题】
点查询
范围查询
Join查询
模糊匹配查询(like语句)
以上都不需要
*
您有没有遇到过一次数据库更新导致多条缓存被失效?
几乎所有的应用
大部分的应用
个别的应用
没有遇到过
*
您通常采用的缓存失效粒度是
行级别
(当一行数据被更新,仅失效与该行相关的缓存数据)
表级别
(当一行数据被更新,失效与整张表相关的所有缓存数据)
设置TTL
(Time To Live,即设定数据在缓存中的失效期限)
都会用到(请说明以什么为主?)
*
行级别的缓存失效(见7)显然更精确。如果您没有采用行级别失效,原因通常是:【多选题】
太麻烦,数据库中的一行数据跟多条缓存数据相关
被缓存结果的查询比较复杂,难以找到对应关系
更新语句过于复杂,难以找到对应关系
缓存的查询和更新语句用到不同的属性,难以找到对应关系
没有必要(请简要说明原因)
其他原因(请说明)
*
您在应用程序端采用的是什么缓存策略?
Write-around
(数据库更新完成后再失效缓存)
Write-through
(同时更新数据库和缓存,确保数据时刻一致)
Write-back
(先更新缓存然后异步更新数据库)
其他(请说明)
*
使用缓存时,以下问题是否曾给您带来困扰?【多选题】
缓存难以及时失效导致读到过时数据
缓存过早失效导致缓存命中率降低
TTL难以设置合理的数值
其他(请说明)
您希望在缓存管理框架中包含的其他功能(选填)
*
 您认为最终一致性在应用程序级缓存使用是否足够?
通常都够用
基本够用,有时候需要采取特殊手段保证数据的新鲜度
不够用,有时候需要保证缓存数据和数据库完全一致
*
您在应用程序中会用到的缓存替换策略有【多选题】
LRU
LFU
Random
TTL
FIFO
其他(请说明)
*
通常在什么情况下您会选择使用缓存?【多选题】
数据库性能跟不上
避免应用程序中的重复计算
减少后台服务之间的通讯延迟
如果可能影响用户体验,就先用了再说
其他(请说明)
*
当数据更新比较频繁时,您会如何确保缓存被及时更新?【多选题】
采取更精确更积极的缓存更新策略,让缓存的数据更及时
弃用缓存,提升数据库端的设计和配置以满足性能
更新业务逻辑,减少其对数据及时性的敏感度
其他(请说明)
*
您认为如果数据库性能足够好,是否可以不使用缓存?
是
否
您可以留下联系邮箱,我们会将调研结果分享给您(可选)
问卷星提供技术支持
举报