快取算是各個網站、服務的標配了，如何才能設計出一套切合實際需求的快取方案，每個接觸過快取的Coder腦子裡都會有自己的答案。
**快取模組從無到有，要如何設計？
要考慮哪些因素？
如何方式設計不足？
如何防止設計過度？
如何滿足實際需求？
要明確哪些問題，才能逐步的完善出一套實現方案？ **
小弟才疏學淺，希望哪位高人能提點一二，不勝感激。

================都焦了，不如割了吧=====================
我的需求：
快，有些記錄後就不會變（很少變），但每次都用的信息，每次讀DB開銷太大。

（Redis的掌握程度只有初級，後面會抓時間惡補）
自己設計：
0、要考慮到快取逾時、命中率，依需求，逐級增加快取等級；
1、（一級快取）第一期，做本地記憶體層級的緩存，直接從記憶體讀取，如果沒有，再讀DB，同時更新快取物件（DB中用View來提高查詢速度）；
2、（二級快取）第二期，後期RQ增加到一定量，會需要Load Balance，此時會考慮使用Redis或Memcache方案作為二級緩存；當一級緩存未中，則讀取二級緩存，扔未中，則查詢資料庫（將存在的數據，反向全部更新）

問題：
1、如果記錄到DB中，配置參數不是單純的key-value形式，也有查詢匹配工作；並且隨著業務複雜度提升，還會有其他資料需要快取。
2、如果記錄到NoSQL/Redis中，如Redis，其資料存儲，是否只能用於“災備”，還是可以使用Redis的資料存儲，拋棄DB
3、對Redis的寫入操作，能否直接記錄到儲存上？ 因為那些需要快取的數據，有些是需要手動輸入的。

擔憂：
第二期時，設計一級、二級快取是否多餘？主要是考慮 讀取Redis中的快取資訊會涉及到網路傳輸

方案：
A、使用一級、二級快取方案，但分散式部署後，一級快取中的資料是否逾時無法準確判斷；
B、放棄一級緩存，直接讀取Redis（不知道讀取Redis的開銷與直接讀取記憶體的開銷，哪個高。

放棄方案A，因為，雖然直接讀取本地內存，效率高，但是命中率不好說；
使用方案B，雖然有了網絡傳輸的損耗，但後續的第三期、第四期。 。甚至會需要Redis配置主從或分片，這時之前所擔心的網路損耗根本不算什麼。