abstrakt：1.首先明確是不是一定要上緩存，當前架構的瓶頸在哪里，若瓶頸真是數(shù)據(jù)庫操作上，再繼續(xù)往下看。2.明確memcached和redis的區(qū)別，到底要使用哪個。前者終究是個緩存，不可能永久保存數(shù)據(jù)（LRU機制），支持分布式，后者除了緩存的同時也支持把數(shù)據(jù)持久化到磁盤等，redis要自己去實現(xiàn)分布式緩存（貌似最新版本的已集成），自己去實現(xiàn)一致性hash。因為不知道你們的應用場景，不好說一定要用memcac

1.首先明確是不是一定要上緩存，當前架構的瓶頸在哪里，若瓶頸真是數(shù)據(jù)庫操作上，再繼續(xù)往下看。

2.明確memcached和redis的區(qū)別，到底要使用哪個。前者終究是個緩存，不可能永久保存數(shù)據(jù)（LRU機制），支持分布式，后者除了緩存的同時也支持把數(shù)據(jù)持久化到磁盤等，redis要自己去實現(xiàn)分布式緩存（貌似最新版本的已集成），自己去實現(xiàn)一致性hash。因為不知道你們的應用場景，不好說一定要用memcache還是redis，說不定用mongodb會更好，比如在存儲日志方面。

3.緩存量大但又不常變化的數(shù)據(jù)，比如評論。

4.你的思路是對的，清晰明了，讀DB前，先讀緩存，如果有直接返回，如果沒有再讀DB，然后寫入緩存層并返回。

5.考慮是否需要主從，讀寫分離，考慮是否分布式部署，考慮是否后續(xù)水平伸縮。

6.想要一勞永逸，后續(xù)維護和擴展方便，那就將現(xiàn)有的代碼架構優(yōu)化，按你說的替換數(shù)據(jù)庫組件需要改動大量代碼，說明當前架構存在問題。可以利用現(xiàn)有的一些框架，比如SpringMVC，將你的應用層和業(yè)務層和數(shù)據(jù)庫層解耦。再上緩存之前把這些做好。

7.把讀取緩存等操作做成服務組件，對業(yè)務層提供服務，業(yè)務層對應用層提供服務。

8.保留原始數(shù)據(jù)庫組件，優(yōu)化成服務組件，方便后續(xù)業(yè)務層靈活調用緩存或者是數(shù)據(jù)庫。

9.不建議一次性全量上緩存，最開始不動核心業(yè)務，可以將邊緣業(yè)務先換成緩存組件，一步步換至核心業(yè)務。
10.

刷新內存，以memcached為例，新增，修改和刪除操作，一般采用lazy load的策略，即新增時只寫入數(shù)據(jù)庫，并不會馬上更新Memcached，而是等到再次讀取時才會加載到Memcached中，修改和刪除操作也是更新 數(shù)據(jù)庫，然后將Memcached中的數(shù)據(jù)標記為失效，等待下次讀取時再加載。