js 引入 緩存

幾周前，我參加了ThoughtWorks 技術雷達研討會。 我在ThoughtWorks工作了多年，并認為如果有人知道這些人在軟件開發(fā)方面的發(fā)展趨勢如何。 在技??巧上帶有上升箭頭的數(shù)字中，第17位被稱為“周到緩存”。 和斯科特·肖一起喝酒時，我問他是什么意思。

趨勢是從響應式緩存過渡到新樣式。 所謂React式，是指您發(fā)現(xiàn)系統(tǒng)在構建后無法運行或無法擴展，并且已經(jīng)投入生產(chǎn)。 許多Ehcache用戶都采用這種方式。 我很高興看到這一趨勢。

故意緩存

新技術是：

• 主動的
• 計劃
• 在系統(tǒng)上線之前實施
• 商榷
• 不僅僅是在您的框架中打開緩存并希望獲得最佳效果–這是考慮周到的部分
• 了解負載特征和數(shù)據(jù)訪問模式

我們?yōu)榇颂砑恿艘恍┟Q，并提出了“ 故意緩存”來總結所有這些內(nèi)容。 我們正在為基于Java和JVM的語言JSR107標準化緩存所做的工作將僅有助于此過渡。 它會包含在Java EE 7中，即使對于那些對遵循EE失去興趣的人，它仍然會發(fā)出信號，表明這是一個體系結構決策，應謹慎制定。

為什么花了這么長時間？

那么，為什么要等到Ehcache和Memcache以及其他許多人相繼出現(xiàn)這種十年之后才出現(xiàn)這種“新”趨勢？ 我認為有幾個原因。

有人認為緩存很臟

我遇到了很多認為緩存很臟的開發(fā)人員。 緩存是作弊行為。 他們認為這表明某些架構設計失敗，最好以其他方式解決。 原因之一是許多早期和開源緩存（包括Ehcache）限制了可以實現(xiàn)的數(shù)據(jù)安全性。 因此，通常的情況是緩存中的數(shù)據(jù)可能但不確定是正確的。 需要與業(yè)務分析師進行復雜的討論，以確定這是否可以接受以及如何允許過時的數(shù)據(jù)。 諸如Enterprise Ehcache之類的企業(yè)緩存的出現(xiàn)已經(jīng)克服了這一問題，之所以如此命名是因為它們具有豐富的功能并包含廣泛的數(shù)據(jù)安全性選項，包括在Ehcache的情況下：弱一致性，最終一致性，強一致性，顯式鎖定，本地和XA交易和原子操作。 因此，即使數(shù)據(jù)必須正確，您也可以使用緩存。

跟隨巨型互聯(lián)網(wǎng)公司的領導

發(fā)生的另一件事是，作為巨型互聯(lián)網(wǎng)公司，它無法逃脫任何人注意到它們都使用大量緩存的注意。 而且如果緩存層出現(xiàn)故障，它們將無法工作。 如此之多，以至于如果您要構建大型的.com應用程序，那么顯然需要在其中構建緩存層。

早期性能優(yōu)化被視為一種反模式

在“敏捷”下，我們專注于可能可行的最簡單的事物。 要求會不斷變化。 您對將來的要求采取的任何批評都會被證明是錯誤的，并且浪費了您的精力。 僅在明確需要時才添加它們。 性能和可伸縮性也往往以這種方式完成。 按照此模型，在將應用程序投入生產(chǎn)后，您會發(fā)現(xiàn)有關要求的信息，但該要求失敗了。 這種相同的思維方式導致構建具有單個數(shù)據(jù)存儲的整體式系統(tǒng)，后來證明需要進行昂貴的重新架構。

我認為我們需要將其視為能力計劃。 如果我們在項目開始時獲得了估計的用戶數(shù)量，所需的響應時間，數(shù)據(jù)量，訪問模式等信息，那么我們就可以對架構以及硬件進行容量規(guī)劃。 在該體系結構規(guī)劃中，我們可以計劃使用緩存。 因為緩存會影響系統(tǒng)的架構方式和硬件要求，所以這樣做很有意義。

參考：在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進入數(shù)據(jù)網(wǎng)格世界

翻譯自: https://www.javacodegeeks.com/2012/01/introducing-deliberate-caching.html

js 引入 緩存

總結

以上是生活随笔為你收集整理的js 引入 缓存_引入故意缓存的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。