redis - 缓存方案如何设计才能切合业务需求？
缓存算是各个网站、服务的标配了，如何才能设计出一套切合实际需求的缓存方案，每个接触过缓存的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配置主从或分片，这时之前所担心的网络损耗根本不算什么。
以上就是 我的思路，不知道是否可行，还有哪些未考虑到的。因为第一期和第二期间隔的时间可能不会太久，所以最好能在一开始的设计上就要考虑周全些。
