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. N'effectuez qu'une mise en cache appropriée
2. N'utilisez pas la technologie juste pour le plaisir

Answer 2

Permettez-moi de parler de mon utilisation de Redis.
1. Tout d'abord, utilisez Redis pour mettre en cache les données statiques (c'est-à-dire inchangées ou rarement modifiées). Il n'est pas nécessaire de les réinsérer. Un cache de premier niveau rend les requêtes de cache complexes.
2. Le problème est qu'utiliser Redis pour mettre en cache des données variables, c'est-à-dire que les données doivent être modifiées, sera très gênant à ce stade, car actuellement Redis ne peut pas remplacer complètement la fonction de stockage de la base de données, c'est-à-dire la les données finales doivent encore être saisies dans la base de données pour des raisons de persistance, cela implique le problème de la synchronisation entre redis et db. Ma solution dans le projet consiste à modifier d'abord Redis, puis à modifier la base de données de manière asynchrone et enfin à synchroniser la base de données avec Redis, car mes exigences de cohérence des données mises en cache sont très strictes.
3. Dans le projet, les données de hachage seront interrogées en fonction de la clé, mais une requête demandera séparément une partie des données de clé dans le hachage afin d'obtenir la même clé plusieurs fois auprès de Redis pour chaque requête. un cache mémoire JVM est introduit, qui est le cache de premier niveau mentionné par la question, vise à réduire le nombre d'accès à Redis, mais l'objectif principal de ce cache de premier niveau est de fusionner plusieurs requêtes pour la même clé. .Le cache final doit toujours être basé sur Redis, après tout, la mémoire JVM est très limitée.

Answer 3

1. Vous ne devez pas mettre en cache vous-même la mémoire, utiliser directement Memcache ou Redis.
Un processeur a plusieurs cœurs. De manière générale, un cœur a un travailleur et la mémoire n'est pas partagée. S'il y a 8 cœurs et que vous mettez en cache dans l'application, cela équivaut à avoir 8 caches. Bien sûr, vous pouvez utiliser la mémoire partagée, mais vous devez gérer plusieurs interactions avec les travailleurs. Alors laissez Memcache et Redis le faire.
2. Le délai du réseau est très faible et peut être ignoré pour le temps de réponse http, généralement inférieur à 0,1 ms.
3. N'utilisez pas de cache multi-niveaux. Si cela ne suffit pas, augmentez la mémoire memcache.
4. Cache uniquement, c'est-à-dire écrivez uniquement dans la base de données lors de l'écriture, puis supprimez le cache memcache correspondant. Lors de la lecture, accédez d'abord à Memcache, accédez à la base de données en cas d'échec, puis écrivez dans Memcache.