預設的序列化/反序列化器會消耗大量cpu，尤其是對於比較複雜的資料型別。針對你的開發語言和程式設計環境使用更合適的序列化/反序列化機制是有必要的。
由於對大物件進行序列化和反序列化的cpu代價非常高昂，在高負載情況下，大量的訪問大物件快取可以很快耗盡伺服器cpu。相反，我們應該將大物件分解成更小的物件，並且單獨快取。（譯者補充：比如redis hash就是處理這種問題的乙個很好解決方案）
當程式中的某部分同時寫相同的快取項時，會引發競態條件。這時需要外部鎖機制來保障。
永遠不要假設某個快取項一定會出現在快取中，即使它才剛剛被寫入快取。因為快取伺服器在記憶體緊張時會將一些快取項驅逐出去。**始終應該對快取中取得的值做null檢查。
這樣做將導致效能低下，因為它會帶來比較大的序列化/反序列化開銷。將單獨的項各自快取，這樣它們可以被單獨獲取。
有時候乙個物件可能同時被多個父物件包含。為了不在不同的地方快取多份相同的資料，將子物件單獨快取。父物件在需要的時候再去取出子物件。
一旦快取物件從快取中清除，那麼它對應的資源將不會被**，從而導致系統資源洩露
通過key和索引序號訪問某資料項非常方便。這對於本地記憶體（in-memory）可以奏效，因為如果引用相同的物件，那麼意味著一旦改變物件，多個訪問路徑都能觀察到物件的變化。但是當使用遠端快取時，就不是這樣了，物件狀態可能因此而不同步（多份）。
翻譯自：10 program busting caching mistakes
資料庫設計中的9大常見錯誤
作為資料庫設計人員，當我們負責資料庫專案時，在資料庫設計以及把資料庫部署到生產環境的過程中可能會遇到一些挑戰。其中一些問題不可避免，也無法控制。但是，其中相當一部分可以追溯到資料庫設計本身的質量。我們在初步階段所做的決定會對資料庫最終的工作情況有深遠的影響。如果我們要建一所房子，我們不會聘請一位工程...
資料庫設計中的9大常見錯誤
作為資料庫設計人員，當我們負責資料庫專案時，在資料庫設計以及把資料庫部署到生產環境的過程中可能會遇到一些挑戰。其中一些問題不可避免，也無法控制。但是，其中相當一部分可以追溯到資料庫設計本身的質量。我們在初步階段所做的決定會對資料庫最終的工作情況有深遠的影響。如果我們要建一所房子，我們不會聘請一位工程...
資料庫設計中的9大常見錯誤
作為資料庫設計人員，當我們負責資料庫專案時，在資料庫設計以及把資料庫部署到生產環境的過程中可能會遇到一些挑戰。其中一些問題不可避免，也無法控制。但是，其中相當一部分可以追溯到資料庫設計本身的質量。我們在初步階段所做的決定會對資料庫最終的工作情況有深遠的影響。如果我們要建一所房子，我們不會聘請一位工程...