使用本地快取需要注意兩個問題：
1 記憶體管理，及時解除無用物件的引用。防止大量無用物件進入old區，引發full gc。
2 資料同步，如果應用是乙個集群，需要保持各台機器的資料一致性。
問題1的解決可以採用lru演算法，預先定好快取大小。達到最大值後，清除最近最少使用的物件。
問題2比較複雜，需要有乙個集中的地方控制快取一致，比如可以採用訊息中介軟體，寫時進行非同步複製。這種方式成本較大。
其實對於業務系統，使用者通過瀏覽器訪問的資料，不需要很強的一致性。只要在3秒內，各台機器能夠保持最終一致，使用者是感覺不大不同機器資料的不同步。
因此通過控制快取時間為3秒或其它很短的時間，就可以保證一定程度的資料一致，避免資料同步的開銷和複雜度。
快取時間短又會引發另外乙個問題，就是快取的命中率。在高併發訪問下，快取時間短可能會導致，大量的訪問剛好都沒有命中，快取穿透給系統帶來瞬間的高峰壓力。
綜合考慮以上幾個矛盾點，可以對快取資料進行封裝，使用有效失效次數的快取物件，保證在高併發情況下，大量的訪問都能命中快取，同時又能保證快取及時失效和更新。**如下
首先是lruhashmap。需要注意的是lruhashmap不是執行緒安全的，非執行緒安全訪問是否會帶來問題，取決於業務場景，對共享變數進行相互覆蓋的影響（參考
class lruhashmap extends linkedhashmap
protected boolean removeeldestentry(map.entryeldest)
}
public class cacheobject implements serializable
public long getcreatetime()
public void setcreatetime(long createtime)
public long getlifetime()
public void setlifetime(long lifetime)
public object getvalue()
// 保證在高併發下，快取失效也可以保證較高的命中率
if (system.currenttimemillis() - createtime > lifetime) else
} return value;
} public void setvalue(object value)
public atomicinteger getinvalidtimes()
public void setinvalidtimes(atomicinteger invalidtimes)
}
public class localcache
public void put(string key, object value, long lifetime)
}
Redis適用於高併發的遞增 遞減功能
遞增指令 incr 預設從0開始 遞減指令 decr 預設從0開始，遞減會出現負數，這點跟memcache不一樣,mc到0 如下 附上shardedjedispool和jediscluster的兩種實現方式 shardedjedispool override public long decr str...
Redis適用於高併發的遞增 遞減功能
遞增指令 incr 預設從0開始 遞減指令 decr 預設從0開始，遞減會出現負數，這點跟memcache不一樣,mc到0 如下 附上shardedjedispool和jediscluster的兩種實現方式 shardedjedispool override public long decr str...
企業是否適用於DCIM解決方案？
在考慮dcim解決方案之前，組織需要檢查和解決的主要考慮因素之一是評估自己組織的現有部門和部門間的做法，程式和痛點。由於企業的可見性不足，以及由於運營和管理領域歷史上不同文化的過程和觀點而導致出現問題？這也提出了一些問題 哪些利益相關方將作出評估和採購決策，其預算將支付dcim解決方案，哪些人員將負...