几周前，我参加了ThoughtWorks 技术雷达研讨会。 我在ThoughtWorks工作了多年，想想是否有人知道这些人在软件开发方面的发展趋势。 在技巧上带有上升箭头的数字中，第17位被称为“周到缓存”。 和斯科特·肖一起喝酒时，我问他是什么意思。
趋势是从响应缓存到新样式的转变。 所谓反应式，是指您发现系统在构建后无法运行或无法扩展，并且已经投入生产。 许多Ehcache用户都采用这种方式。 我很高兴看到这一趋势。
故意缓存
新技术是：
- 主动的
- 计划
- 在系统上线之前实施
- 商榷
- 不仅仅是在您的框架中打开缓存并希望达到最佳效果–这是考虑周到的部分
- 了解负载特征和数据访问模式
我们为此添加了一些名称，并提出了“ 故意缓存”来总结所有这些内容。
我们正在进行的标准化基于Java和JVM的语言JSR107的缓存的工作将仅有助于此过渡。 它会被包含在Java EE 7中，即使对于那些对遵循EE失去兴趣的人来说，它仍然会发出信号，表明这是一个体系结构决策，应慎重做出。
为什么花了这么长时间？
那么，为什么要等到Ehcache和Memcache以及其他许多人相继出现10年后，这种“新”趋势才出现？ 我认为有几个原因。
有人认为缓存很脏
我遇到了很多认为缓存很脏的开发人员。 缓存是作弊。 他们认为这表明某些架构设计失败，最好以其他方式解决。
造成这种情况的原因之一是，许多早期的开源缓存（包括Ehcache）限制了可以实现的数据安全性。 因此，通常的情况是缓存中的数据可能但不确定是正确的。 需要与业务分析师进行复杂的讨论，以确定这是否可以接受以及如何允许过时的数据。 诸如Enterprise Ehcache之类的企业缓存的出现已经克服了这一问题，之所以如此命名是因为它们具有丰富的功能并包含广泛的数据安全性选项，包括在Ehcache的情况下：弱一致性，最终一致性，强一致性，显式锁定，本地和XA交易和原子操作。 因此，即使数据必须正确，您也可以使用缓存。
跟随巨型互联网公司的领导
发生的另一件事是，作为巨型互联网公司，它无法逃脱任何人都使用大量缓存的注意。 而且如果缓存层出现故障，它们将无法工作。 如此之多，以至于如果您要构建大型的.com应用程序，那么显然需要在其中构建缓存层。
早期性能优化被视为一种反模式
在“敏捷”下，我们专注于可能可行的最简单的事物。 要求会不断变化。 您对将来的要求采取的任何批评都会被证明是错误的，并且您的工作被浪费了。 仅在明确需要时才添加它们。 性能和可伸缩性也倾向于通过这种方式完成。 按照此模型，在将应用程序投入生产后，您会发现有关要求的信息，但该要求失败了。 这种相同的思维方式导致构建具有单个数据存储的整体式系统，后来证明需要进行昂贵的重新架构。
我认为我们需要将其视为能力计划。 如果我们在项目开始时获得了有关用户数量，所需响应时间，数据量，访问模式等的估计数量，那么我们就可以对架构以及硬件进行容量规划。 在该体系结构规划中，我们可以计划使用缓存。 由于缓存会影响系统的架构方式和硬件要求，因此这样做很有意义。
参考：在Greg Luck的Blog上 ，我们的JCG合作伙伴 Greg Luck 介绍了故意缓存 。
相关文章 ：
- 新的Java缓存标准（javax.cache）
- 具有GlassFish和一致性的高性能JPA –第1部分
- Spring 3.1缓存抽象教程
- Spring 3.1和JPA的持久层
- JBoss 4.2.x Spring 3 JPA Hibernate教程
- GWT Spring和Hibernate进入数据网格世界
翻译自: https://www.javacodegeeks.com/2012/01/introducing-deliberate-caching.html
)
)
