使用cache api時，乙個最重要的問題就是潛在的資料載入。因為imdg提供的分布式集合也都是實現的jdk的map、set等介面，以jdk的map為例，它介面規定put和remove返回被替換的物件或刪除掉的物件，所以這會導致我們操作快取時導致與後端儲存的通訊。所以我們要呼叫其它版本的api，例如gridgain提供了putx等介面，其返回值是乙個布林值而非舊的物件。
現今的imdg雖然已經比較成熟，但仍有一些問題需要解決：
ø冷啟動問題：即便是能夠並行還原，從後端資料庫還原數tb的資料依然需要很久，這段時間是會導致資料庫的過載，可能無法為其他應用提供服務。
ø缺少cdc能力：還沒有一款imdg產品提供cdc(change data capture)能力，即資料庫資料的變化如何反映到imdg中。現在一般都需要觸發器或第三方產品來實現cdc，例如hazelcast通過第三方speedment能夠監控資料庫中的資料變化。
ø分布式計算容錯：像impala分布式計算平台直接不提供容錯。
1 hazelcast's maploader pitfalls
2 jags ramnarayan on in-memory data grids
發現問題和陷阱
oct 14,2015 pitfall on notify lvn itemchanged,idc list 列表控制項,cdlgfbdesign onlvnitemchangedlistfbp 與 on notify lvn beginlabeledit,idc list 列表控制項,cdlgfb...
singleton中的陷阱
單件模式應該是設計模式中運用得最多的模式之一，對於全域性性的復用性的物件我們通常會採用單件模式，正是因為單件這種頻繁運用的看似簡單的模式前段時間在我們的專案中卻引發了乙個致命性的崩潰bug，因此在這裡總結一下，希望能給大家有所幫助。所謂單件模式就是在整個程序執行期間只需要例項化一次為所有執行執行緒公...
Method Swizzling中的陷阱
這篇文章不是介紹什麼是方法交換，這類文章很多，如果你不知道什麼是方法交換可以看這篇文章 method swizzling 方法交換是很危險的東西，會產生一些未知的錯誤，最近在使用方法交換時就遇到了這樣的問題，在我交換了乙個系統方法後，在呼叫這個方法時會在我交換的方法中迴圈無法跳出。最終我找到了問題的...