1.首先明確是不是一定要上快取，當前架構的瓶頸在哪裡，若瓶頸真是資料庫操作上，再繼續往下看。

2.明確memcached和redis的區別，到底要使用哪個。前者終究是個快取，不可能永久儲存資料（LRU機制），支援分散式，後者除了快取的同時也支援把資料持久化到磁碟等，redis要自己去實現分散式快取（貌似最新版本的已整合），自己去實現一致性hash。因為不知道你們的應用場景，不好說一定要用memcache還是redis，說不定用mongodb會更好，比如在儲存日誌方面。

3.快取量大但又不常變化的資料，比如評論。

4.你的思路是對的，清晰明瞭，讀DB前，先讀快取，如果有直接返回，如果沒有再讀DB，然後寫入快取層並返回。

5.考慮是否需要主從，讀寫分離，考慮是否分散式部署，考慮是否後續水平伸縮。

6.想要一勞永逸，後續維護和擴充套件方便，那就將現有的程式碼架構優化，按你說的替換資料庫元件需要改動大量程式碼，說明當前架構存在問題。可以利用現有的一些框架，比如SpringMVC，將你的應用層和業務層和資料庫層解耦。再上快取之前把這些做好。

7.把讀取快取等操作做成服務元件，對業務層提供服務，業務層對應用層提供服務。

8.保留原始資料庫元件，優化成服務元件，方便後續業務層靈活呼叫快取或者是資料庫。

9.不建議一次性全量上快取，最開始不動核心業務，可以將邊緣業務先換成快取元件，一步步換至核心業務。

10.重新整理記憶體，以memcached為例，新增，修改和刪除操作，一般採用lazy load的策略，即新增時只寫入資料庫，並不會馬上更新Memcached，而是等到再次讀取時才會載入到Memcached中，修改和刪除操作也是更新 資料庫，然後將Memcached中的資料標記為失效，等待下次讀取時再載入。