目前公司的一个项目，数据库用的是Mysql，正在考虑用redis/memcached做数据库的缓存层，目前的想法就是在读DB前，先读缓存层，如果有直接返回，如果没有再读DB，然后写入缓存层并返回。 不过，要是直接在应用层加入缓存的代码，感觉修改量大，修改维护也麻烦，因此想把应用层和缓存层的代码分开。不知道这种想法正确否？
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中的数据标记为失效，等待下次读取时再加载。
