1、首先明確是不是一定要上快取，當前架構的瓶頸在哪裡，若瓶頸真是資料庫操作上，再繼續往下看。
2、明確memcached和redis的區別，到底要使用哪個。前者終究是個快取，不可能永久儲存資料（LRU機制），支援分散式，後者除了快取的同時也支援把資料持久化到磁碟等，redis要自己去實現分散式快取（貌似最新版本的已整合），自己去實現一致性hash。因為不知道應用場景，不好說一定要用memcache還是redis，說不定用mongodb會更好，比如在儲存日誌方面。
4、思路是對的，清晰明瞭，讀DB前，先讀快取，如果有直接返回，如果沒有再讀DB，然後寫入快取層並返回。
5、考慮是否需要主從，讀寫分離，考慮是否分散式部署，考慮是否後續水平伸縮。
6、想要一勞永逸，後續維護和擴充套件方便，那就將現有的程式碼架構最佳化，按你說的替換資料庫元件需要改動大量程式碼，說明當前架構存在問題。可以利用現有的一些框架，比如SpringMVC，將應用層和業務層和資料庫層解耦。再上快取之前把這些做好。
7、把讀取快取等操作做成服務元件，對業務層提供服務，業務層對應用層提供服務。
8、保留原始資料庫元件，最佳化成服務元件，方便後續業務層靈活呼叫快取或者是資料庫。
9、不建議一次性全量上快取，最開始不動核心業務，可以將邊緣業務先換成快取元件，一步步換至核心業務。
10、重新整理記憶體，以memcached為例，新增，修改和刪除操作，一般採用lazy load的策略，即新增時只寫入資料庫，並不會馬上更新Memcached，而是等到再次讀取時才會載入到Memcached中，修改和刪除操作也是更新 資料庫，然後將Memcached中的資料標記為失效，等待下次讀取時再載入。
大方向兩種方案：
1、指令碼同步：
自己寫指令碼將資料庫資料寫入到redis/memcached。
這就涉及到實時資料變更的問題（mysql row binlog的實時分析），binlog增量訂閱Alibaba 的canal ，以及快取層資料 丟失/失效 後的資料同步恢復問題。
2、業務層實現：
先讀取nosql快取層，沒有資料再讀取mysql層，並寫入資料到nosql。
nosql層做好多節點分散式（一致性hash），以及節點失效後替代方案（多層hash尋找相鄰替代節點），和資料震盪恢復了。
1、首先明確是不是一定要上快取，當前架構的瓶頸在哪裡，若瓶頸真是資料庫操作上，再繼續往下看。
2、明確memcached和redis的區別，到底要使用哪個。前者終究是個快取，不可能永久儲存資料（LRU機制），支援分散式，後者除了快取的同時也支援把資料持久化到磁碟等，redis要自己去實現分散式快取（貌似最新版本的已整合），自己去實現一致性hash。因為不知道應用場景，不好說一定要用memcache還是redis，說不定用mongodb會更好，比如在儲存日誌方面。
4、思路是對的，清晰明瞭，讀DB前，先讀快取，如果有直接返回，如果沒有再讀DB，然後寫入快取層並返回。
5、考慮是否需要主從，讀寫分離，考慮是否分散式部署，考慮是否後續水平伸縮。
6、想要一勞永逸，後續維護和擴充套件方便，那就將現有的程式碼架構最佳化，按你說的替換資料庫元件需要改動大量程式碼，說明當前架構存在問題。可以利用現有的一些框架，比如SpringMVC，將應用層和業務層和資料庫層解耦。再上快取之前把這些做好。
7、把讀取快取等操作做成服務元件，對業務層提供服務，業務層對應用層提供服務。
8、保留原始資料庫元件，最佳化成服務元件，方便後續業務層靈活呼叫快取或者是資料庫。
9、不建議一次性全量上快取，最開始不動核心業務，可以將邊緣業務先換成快取元件，一步步換至核心業務。
10、重新整理記憶體，以memcached為例，新增，修改和刪除操作，一般採用lazy load的策略，即新增時只寫入資料庫，並不會馬上更新Memcached，而是等到再次讀取時才會載入到Memcached中，修改和刪除操作也是更新 資料庫，然後將Memcached中的資料標記為失效，等待下次讀取時再載入。
大方向兩種方案：
1、指令碼同步：
自己寫指令碼將資料庫資料寫入到redis/memcached。
這就涉及到實時資料變更的問題（mysql row binlog的實時分析），binlog增量訂閱Alibaba 的canal ，以及快取層資料 丟失/失效 後的資料同步恢復問題。
2、業務層實現：
先讀取nosql快取層，沒有資料再讀取mysql層，並寫入資料到nosql。
nosql層做好多節點分散式（一致性hash），以及節點失效後替代方案（多層hash尋找相鄰替代節點），和資料震盪恢復了。