共计 2578 个字符，预计需要花费 7 分钟才能阅读完成。
作者：翁智华
出处：https://www.cnblogs.com/wzh2010/
概述
咱们所说的缓存分为过程外部缓存（零碎外部缓存）和 缓存服务（如 redis/memcache）。
计算机服务从原来的单体构造，到多实例，到当初风行的微服务，缓存服务变得原来越风行了。
过程缓存
先说说过程缓存，它将数据存储在站点、服务的过程内。在 Web 的倒退历史上，这样的形式备受欢送。比方晚期罕用的.Net 的 System.Web.Caching.
这种实现载体很简略，比方一个带锁的 HasTable，或者一个 List 对象。应用简略便捷，能存储数据、html 页面片段、文件，甚至任何对象。
在单体构造的 Web 模式下，过程内缓存被开发到极致，大略流程如下图：
与原先没有缓存相比，过程内缓存的益处是，数据读取不再间接拜访数据库，先判断缓存中是否存在，如果存在，则间接读取，不存在则再去数据库中取，同时写入缓存。
这样防止了每次的申请都走数据库，缩小网络开销和数据申请次数，进步了数据获取效率，根本等同在内存中执行。
缓存的目标是为了冷热数据的隔离，对于频繁被批改的数据，缓存的意义不是很大，比方微信用户的实时步数。比拟有价值的是那些不被频繁批改且数据量较大的内容，比方零碎字典、配置数据。
判断是否须要创立缓存须要肯定的根据，以下是我的团队的策略，不肯定实用，能够参考：
缓存的必要性：数据的变更是否过于频繁，过于频繁则可能导致缓存一直重建，反而升高效率。评估形式：缓存的过期工夫内没被被动更新的量值应该超过 60%。
假如缓存工夫：3600s
假如同一种类型缓存数据基数：6000 个
6000 * 60% = 3600 的数据在一个小时内事务未更新，这样的缓存价值更大。
过程缓存的问题
在互联网大潮下，随着用户量的激增，原来单体构造逐步的向 Web 服务集群倒退，在多实例指标下，过程缓存的弊病越来越显著。
比方缓存无奈对立的问题。
如果站点和服务中的多个节点拜访对立的缓存服务（比方 redis 或者 memerche），数据对立存储，数据的一致性就比拟容易保障。
但如果是过程缓存，数据存储在站点和服务的多个节点内，每个节点一个缓存，存储多份，一致性就比拟难保障。
如上图，然而有个问题，Cache1、Cache1、Cache3 一致性难以保障，如果想放弃缓存的一致性时，该怎么办呢？
个别有以下几种办法：
1、繁多服务节点告诉其余服务节点，如果咱们只是 Web Service1 在执行业务操作的时候批改数据库，更新缓存，同时告诉其余 Web Service
服务，其余 Web Service 接管到信息的时候，进行缓存更新。
2、启动 MQ 告诉其余节点：如下图，能够通过 MQ 告诉其余节点。写申请产生在 server1，在批改完本人缓存数据与数据库中的数据之后，给 MQ 生产数据变动告诉，
server2 和 server1 订阅 MQ 音讯，当生产到 MQ 信息的时候，也批改缓存数据。
3、有一种简略的形式，也能够解耦与 Web Server 的关系，就是间接放弃了“实时一致性”，启动一个独立的过程服务，定时从后端拉取最新的数据，更新内存缓存。
上述的几种办法为了保持数据的一致性，减少了肯定的开销，一方面缓存数据同步过程中会有出错的危险；
另一方面实际上违反了缓存的准则：冷热数据断绝，无效的利用冷数据，加重数据库压力，晋升效率。如果缓存被频繁批改或者同步，那缓存的价值就不大了。
补充：1、2 两种形式，实例越多，缓存冗余越多，各缓存节点数据同步的原子性越难保障，一致性也就越难保障。
第 3 种形式：采纳定时拉取自身曾经放弃了数据的实时一致性。
所以咱们在以下这几种状况下摈弃过程缓存，选用缓存服务：
1、Web 集群下，蕴含多个实例，并且不容许业务数据的不一致性（我置信大部分业务不容许）
2、过程内缓存数据量较大，缓存内存空间有余，影响 Web 性能，能够思考走缓存服务（缓存服务如 redis，个别独立服务甚至集群配置，反对超大量级）。
3、评估 value 大小、缓存内存空间、峰值 QPS、过期工夫、缓存命中率、读写更新策略、key 值散布路由策略、过期策略以及数据一致性计划，依据理论须要判断是否走缓存服务。
缓存服务
在互联网分层架构中，最罕用的 kv 构造的缓存是 redis。他有如下特点：
1、它反对简单数据结构
value 是字符串、哈希，列表，汇合，有序汇合这类简单的数据结构。反对各种场景，如客户订单信息列表，用户音讯，帖子评论等。
2、反对长久化
首先，redis 的所有数据都是保留在内存中，而后不定期的通过异步形式保留到磁盘上 (这称为“半长久化模式”)；
也能够把每一次数据变动都写入到一个 append only file(aof) 外面 (这称为“全长久化模式”，效率会低一点)。
然而咱们尽量不要把 redis 当作数据库用，如果真的须要长久化数据，倡议能够走 MySQL：
2.1、redis 的定期快照不能保证数据不失落
2.2、redis 的 AOF 会升高效率，并且不能反对太大的数据量
3、具备高可用个性
redis 人造反对集群性能，能够实现被动复制，读写拆散。官网也提供了 sentinel 集群管理工具，可能实现主从服务监控，故障主动转移。
4、存储的内容比拟大
String 类型：一个 String 类型的 value 最大能够存储 512M，List、Set、Hash 类型：list 的元素个数最多为 2^32- 1 个，也就是 4294967295 个。
5、反对事务
操作都是原子性，对数据的更改要么全副执行，要么全副不执行。防止业务数据的不一致性。
缓存应用留神
1、Web 服务 单体模式转为多实例之后，咱们将过程缓存降级为缓存服务（redis），清清理了所有的缓存应用，都改成了对接 redis。然而有一些中央漏掉，因为咱们有 3 个实例，所以漏掉的那几个中央，一旦批改某个数据之后，一会儿是新值，一会儿旧值，很神奇。
2、谨防缓存击穿、雪崩的产生，这个咱们有惨痛的教训，后续来一篇专门剖析下。
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿 (2021 最新版)
2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！
3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
