幾周前，我參加了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
)
)
