缓存算是各个网站、服务的标配了，如何才能设计出一套切合实际需求的缓存方案，每个接触过缓存的Coder脑子里都会有自己的答案。
**缓存模块从无到有，要如何设计？
要考虑哪些因素？
如何方式设计不足？
如何防止设计过度？
如何满足实际需求？
要明确哪些问题，才能逐步的完善出一套实现方案？**
小弟才疏学浅，希望哪位高人能提点一二，不胜感激。
================都焦了，不如割了吧=====================
我的需求：
快，一些记录后就不会变（很少变），但每次都用的信息，每次读DB开销太大。
（Redis的掌握水平只有初级，后面会抓时间恶补）
自己设计：
0、要考虑到 缓存超时、命中率，按需求，逐级增加缓存级别；
1、（一级缓存）第一期，做本地内存级别的缓存，直接从内存中读取，如果没有，再读DB，同时更新缓存对象（DB中用View来提高查询速度）；
2、（二级缓存）第二期，后期RQ增加到一定量，会需要Load Balance，此时会考虑使用Redis或Memcache方案作为二级缓存；当一级缓存未中，则读取二级缓存，扔未中，则查询数据库（将存在的数据，反向全部更新）
问题：
1、如果记录到DB中，配置参数不是单纯的key-value形式，也有查询匹配工作；并且随着业务复杂度提升，还会有其他数据需要缓存。
2、如果记录到NoSQL/Redis中，如Redis，其数据存储，是不是只能用于“灾备”，还是可以使用Redis的数据存储，抛弃DB
3、对Redis的写操作，能否直接记录到存储上？ 因为那些需要缓存的数据，有些是需要手动录入的。
担忧：
第二期时，设计一级、二级缓存是否多余？主要是考虑 读取Redis中的缓存信息会涉及到网络传输
方案：
A、使用一级、二级缓存方案，但分布式部署后，一级缓存中的数据是否超时无法准确判断；
B、放弃一级缓存，直接读取Redis（不知道读取Redis的开销与直接读内存的开销，哪个高。而且一级不命中，再去二级中读，反而绕远）
自问自答：
放弃方案A，因为，虽然直接读本地内存，效率高，但是命中率不好说；
使用方案B，虽然有了网络传输的损耗，但后续的第三期、第四期。。甚至会需要Redis配置主从或分片，这时之前所担心的网络损耗根本不算什么。
以上就是 我的思路，不知道是否可行，还有哪些未考虑到的。因为第一期和第二期间隔的时间可能不会太久，所以最好能在一开始的设计上就要考虑周全些。
1、不应该自己去内存中缓存，直接用memcache或者redis。
一个cpu多个核，一般来说一个核一个worker，是内存不共享的，如果8个核，你在应用中缓存，就相当于有8个缓存。当然你可以用共享内存，但是需要处理多个worker交互问题。因此让memcache,redis来做。
2、网络延时很小，对http响应时间来说可以忽略不计，一般在0.1ms以下。
3、不要搞多级缓存，不够用就加大memcache内存。
4、只做缓存，即写的时候只写数据库，然后把对应的memcache缓存删除。读的时候先memcache，失败再数据库，然后写memcache。
我说下我使用Redis的情况，
1.首先使用Redis缓存静态数据（即不变，或者很少变），那是完全OK的，而且也很合适，完全没必要再插入一个一级缓存，使得缓存查询复杂。
2.麻烦的是使用Redis缓存可变数据，即数据需要被修改，这时就会显得很麻烦，因为目前Redis还不能完全取代DB的存储作用，即最终的数据还是要入DB，进行持久化，这样就涉及到redis与db同步的问题。我在项目的解决方案是先修改Redis，然后异步修改DB，最后DB同步到Redis，因为我缓存的数据一致性要求很严格。
3.项目中会根据key查询一个hash数据，但是一次请求会分开请求hash中的部分key数据，这样为了必要每次请求去Redis获取同一个Key多次，所以引入了一个JVM内存缓存，也就是题主说的一级缓存，目的是减少访问Redis的次数，但是这个一级缓存的主要目的是合并多个请求同一个key的请求，最终缓存还是要以Redis为准，毕竟JVM内存很有限。
1.只做适合的缓存
2.不要为了用一些技术而用