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. Only do appropriate caching
2. Don’t use technology just for the sake of it

Answer 2

Let me talk about my use of Redis,
1. First use Redis to cache static data (that is, unchanged, or rarely changed). That is completely OK and very appropriate. There is no need to insert a first-level cache. , making cache queries complex.
2. The trouble is that using Redis to cache variable data, that is, the data needs to be modified, will be very troublesome at this time, because currently Redis cannot completely replace the storage role of DB, that is, the final data still needs to be entered into DB for persistence. ization, which involves the issue of synchronization between redis and db. My solution in the project is to modify Redis first, then modify the DB asynchronously, and finally synchronize the DB to Redis, because my cached data consistency requirements are very strict.
3. In the project, a hash data will be queried based on the key, but a request will request part of the key data in the hash separately. In order to obtain the same Key multiple times from Redis for each request, a JVM memory cache is introduced, which is also necessary. It is the first-level cache mentioned by the question. The purpose is to reduce the number of accesses to Redis. However, the main purpose of this first-level cache is to merge multiple requests for the same key. The final cache must be based on Redis. After all, the JVM memory is very limited. .

Answer 3

1. You should not cache in memory yourself, use memcache or redis directly.
A CPU has multiple cores. Generally speaking, one core has one worker, and the memory is not shared. If there are 8 cores and you cache in the application, it is equivalent to having 8 caches. Of course you can use shared memory, but you need to deal with multiple worker interactions. So let memcache and redis do it.
2. The network delay is very small and can be ignored for http response time, which is generally less than 0.1ms.
3. Don’t use multi-level cache. If it’s not enough, increase the memcache memory.
4. Only cache, that is, only write to the database when writing, and then delete the corresponding memcache cache. When reading, go to memcache first, go to the database if it fails, and then write to memcache.