引入故意缓存

趋势是从响应缓存到新样式的转变。 所谓反应式&＃xff0c;是指您发现系统在构建后无法运行或无法扩展&＃xff0c;并且已经投入生产。 许多Ehcache用户都采用这种方式。 我很高兴看到这一趋势。

故意缓存

新技术是&＃xff1a;

• 主动的
• 计划
• 在系统上线之前实施
• 商榷
• 不仅仅是在您的框架中打开缓存并希望达到最佳效果–这是考虑周到的部分
• 了解负载特征和数据访问模式

为什么花了这么长时间&＃xff1f;

有人认为缓存很脏

跟随巨型互联网公司的领导

早期性能优化被视为一种反模式

在“敏捷”下&＃xff0c;我们专注于可能可行的最简单的事物。 要求会不断变化。 您对将来的要求采取的任何批评都会被证明是错误的&＃xff0c;并且您的工作被浪费了。 仅在明确需要时才添加它们。 性能和可伸缩性也倾向于通过这种方式完成。 按照此模型&＃xff0c;在将应用程序投入生产后&＃xff0c;您会发现有关要求的信息&＃xff0c;但该要求失败了。 这种相同的思维方式导致构建具有单个数据存储的整体式系统&＃xff0c;后来证明需要进行昂贵的重新架构。

我认为我们需要将其视为能力计划。 如果我们在项目开始时获得了有关用户数量&＃xff0c;所需响应时间&＃xff0c;数据量&＃xff0c;访问模式等的估计数量&＃xff0c;那么我们就可以对架构以及硬件进行容量规划。 在该体系结构规划中&＃xff0c;我们可以计划使用缓存。 由于缓存会影响系统的架构方式和硬件要求&＃xff0c;因此这样做很有意义。

参考&＃xff1a;在Greg Luck的Blog上 &＃xff0c;我们的JCG合作伙伴 Greg Luck 介绍了故意缓存 。

相关文章 &＃xff1a;

• 新的Java缓存标准&＃xff08;javax.cache&＃xff09;
• 具有GlassFish和一致性的高性能JPA –第1部分
• Spring 3.1缓存抽象教程
• Spring 3.1和JPA的持久层
• JBoss 4.2.x Spring 3 JPA Hibernate教程
• GWT Spring和Hibernate进入数据网格世界