摘要：1.首先明確是不是一定要上緩存，當(dāng)前架構(gòu)的瓶頸在哪里，若瓶頸真是數(shù)據(jù)庫(kù)操作上，再繼續(xù)往下看。2.明確memcached和redis的區(qū)別，到底要使用哪個(gè)。前者終究是個(gè)緩存，不可能永久保存數(shù)據(jù)（LRU機(jī)制），支持分布式，后者除了緩存的同時(shí)也支持把數(shù)據(jù)持久化到磁盤(pán)等，redis要自己去實(shí)現(xiàn)分布式緩存（貌似最新版本的已集成），自己去實(shí)現(xiàn)一致性hash。因?yàn)椴恢滥銈兊膽?yīng)用場(chǎng)景，不好說(shuō)一定要用memcac

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

2.明確memcached和redis的區(qū)別，到底要使用哪個(gè)。前者終究是個(gè)緩存，不可能永久保存數(shù)據(jù)（LRU機(jī)制），支持分布式，后者除了緩存的同時(shí)也支持把數(shù)據(jù)持久化到磁盤(pán)等，redis要自己去實(shí)現(xiàn)分布式緩存（貌似最新版本的已集成），自己去實(shí)現(xiàn)一致性hash。因?yàn)椴恢滥銈兊膽?yīng)用場(chǎng)景，不好說(shuō)一定要用memcache還是redis，說(shuō)不定用mongodb會(huì)更好，比如在存儲(chǔ)日志方面。

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

4.你的思路是對(duì)的，清晰明了，讀DB前，先讀緩存，如果有直接返回，如果沒(méi)有再讀DB，然后寫(xiě)入緩存層并返回。

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

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

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

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

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

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