redis - 缓存方案如何设计才能切合业务需求？

Question

缓存算是各个网站、服务的标配了，如何才能设计出一套切合实际需求的缓存方案，每个接触过缓存的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配置主从或分片，这时之前所担心的网络损耗根本不算什么。

以上就是 我的思路，不知道是否可行，还有哪些未考虑到的。因为第一期和第二期间隔的时间可能不会太久，所以最好能在一开始的设计上就要考虑周全些。

Answer 1

1. 적절한 캐싱만 수행하세요
2. 기술만을 목적으로 사용하지 마세요

Answer 2

Redis 사용에 대해 이야기하겠습니다.
먼저 Redis를 사용하여 정적 데이터(즉, 변경되지 않았거나 거의 변경되지 않음)를 다시 삽입할 필요가 없습니다. 첫 번째 수준 캐시는 캐시 쿼리를 복잡하게 만듭니다.
2. 문제는 Redis를 사용하여 변수 데이터, 즉 수정이 필요한 데이터를 캐시하는 것은 현재로서는 매우 번거롭다는 것입니다. 왜냐하면 현재 Redis는 DB의 저장 기능, 즉 데이터를 완전히 대체할 수 없기 때문입니다. 지속성을 위해서는 최종 데이터를 DB에 입력해야 합니다. 여기에는 redis와 db 간의 동기화 문제가 포함됩니다. 프로젝트의 내 솔루션은 먼저 Redis를 수정한 다음 DB를 비동기식으로 수정하고 마지막으로 DB를 Redis에 동기화하는 것입니다. 캐시된 데이터 일관성 요구 사항이 매우 엄격하기 때문입니다.
3. 프로젝트에서는 키를 기반으로 해시 데이터를 쿼리하지만 요청은 각 요청에 대해 Redis에서 동일한 키를 여러 번 얻기 위해 해시의 키 데이터 일부를 별도로 요청합니다. 질문에서 언급한 첫 번째 수준 캐시인 JVM 메모리 캐시가 도입된 이유는 Redis에 대한 액세스 횟수를 줄이는 것이지만 이 첫 번째 수준 캐시의 주요 목적은 동일한 키에 대한 여러 요청을 병합하는 것입니다. 최종 캐시는 여전히 Redis를 기반으로 해야 하기 때문에 JVM 메모리는 매우 제한적입니다.

Answer 3

1. 메모리에 직접 캐시하지 말고 memcache나 redis를 직접 사용하세요.
CPU에는 여러 개의 코어가 있습니다. 일반적으로 하나의 코어에는 하나의 작업자가 있으며 메모리는 공유되지 않습니다. 8개의 코어가 있고 애플리케이션에 캐시하면 8개의 캐시가 있는 것과 같습니다. 물론 공유 메모리를 사용할 수 있지만 여러 작업자 상호 작용을 처리해야 합니다. 그러니 Memcache와 Redis가 그렇게 하도록 놔두세요.
2. 네트워크 지연은 매우 작으며 http 응답 시간은 일반적으로 0.1ms 미만으로 무시할 수 있습니다.
3. 다중 레벨 캐시를 사용하지 마세요. 충분하지 않으면 Memcache 메모리를 늘리세요.
4. 캐시만, 즉 쓰기 시에만 데이터베이스에 쓰고 해당 Memcache 캐시를 삭제합니다. 읽을 때 먼저 Memcache로 이동하고 실패하면 데이터베이스로 이동한 다음 Memcache에 씁니다.