三高项目-缓存设计

分流、并发

导流：将原本复杂操作的请求，引导到简单的操作上。以后再来查，不需要经过复杂的计算。

成本：空间，收益：节省了时间。

不要以为仅仅是 redis，map等。

对应。kv值。

1计算k，2 查询k，3 得到值，做转换。

如果能做好对应，最好，做不好对应呢？ 命中率。没有命中的缓存，查原数据。

数据的查询时间：时间（123）+（1-命中率p）*查原数据的时间。

命中率=缓存中能查到的数据/数据库总数据

如何 提升缓存的收益：

减少 123时间。

提高命中率（*）。

应用场景：

读多写少用缓存。

查询原数据时间特别长的场景。

Key

键K有关

生成时间

不同功能业务的，key值要不一样，否则会被覆盖。

要唯一，避免碰撞。

单向函数：hash。给定输入的情况下，很容易计算出结果，而给定结果的情况下，几乎不可能计算出输入值。

一般不存在。正向快速，逆向困难，输入敏感，冲突避免。

---

md4 , md5,sha-0,sha-1,sha-2(用)

---

查询时间

缓存的位置。内存，硬盘，本地。

数据结构。

1234567890

234567890-

equals，hashcode。

键总结

无碰撞（唯一），高效生成（不需要，约定好），高效比较。

系统标识+功能标识+业务标识+前后缀。

13910712345+vcode: 123456

公司统一标准。

值

序列化值（二进制），对象值。

数据污染：

0-0.5-1 1-2 存的不是最终值

---

缓存只是 在 调用方和 数据提供方之间的一个 暂存方。

统一：缓存中数据怎么来的，查询的时候，如果没有，就从数据提供方获取，然后放到缓存中。

缓存的更新机制

时效性更新机制

固定时间过期，被动更新

：缓存中的数据设置一个过期时间。如果缓存数据过期，那么，我会去提供方查询，这样就相当于将 提供方 的数据 更新到缓存中了。

放弃了：实时一致性。（商品关注人数，评论数，浏览量，评论点赞收藏）

读，

写：只写数据提供方。不理会缓存。

主动更新机制

清风：cap。

cache aside

写：先更新，更新数据提供方，删除缓存。

概率很低：

1。 读的时候，缓存里 没有数据。

2。 读的时候，有写在同时进行。

3。读的时长大于 写操作。（不那么容易发生 1%）。

4。 读写操作 同时发生时，读到的是旧值。50%。

可以用。鸵鸟算法。

在计算机科学中，鸵鸟算法 是一个忽略潜在问题的一种算法策略，这种策略对计算机程序可能出现的问题采取无视态度（类似于鸵鸟在遇到危险时将头埋在地里，装作看不见）。鸵鸟算法的使用前提是，问题出现的概率很低。

三高项目-缓存

双写一致性

先删除缓存，再更新数据提供方。 延迟双删。

1。更新缓存，更新数据库。更容易造成数据的不一致，缓存成功，数据提供方失败。更糟糕。

2。更新数据库，更新缓存。有缺点，一点点稍微可取。

缺点：A 更新了数据库。B更新了数据库，B更新了缓存，A更新了缓存。

空干活，经过复杂的计算，给缓存设置值，但是用的少，浪费了资源。

3。删除缓存，更新数据库。延迟双删

4。更新数据库，删掉缓存。上节课所说的额cache aside。

延迟双删：删除缓存，更新数据提供方，睡眠一段时间（根据实际业务），再删除缓存。

如果第二次 删除失败了，怎么办？ 重试一下。

自己写重试代码，没问题。自己挂了呢？

转移风险。重试的组件？ 消息队列。

上面所说的，不管方案多么复杂，完善，总不能保证一致性。

Read/Write Through

直接 将 结果写入缓存。再从缓存 同步到数据提供方。调用方只需要和缓存交互。

写成功标识：缓存成功，数据提供方成功。TCC。

初始化：1。 启动缓存，从数据提供方，初始化。2。读取缓存 ，初始化。

缓存预热。命中率低，慢慢的命中率才高。

保障：缓存 非常 可靠。

Write Behind

在上面 做了升级，异步写入到数据提供方。加入消息队列，保证最终一致性。

---

缓存空间足够大，能缓存所有的数据，命中率 100%。

清理机制

以提高缓存命中率为目标。

过去访问多的，未来访问也多。

最近被更新的，未来访问的多。

时效性清理

过期全部清理。要求缓存中的数据都有一个生存期，有效期。

1条数据：data，ttl。2min。

轮询时效清理：额外开启一个程序，定期扫描所有数据的有效期，到期了，干掉。

自动时效清理：cookie。本质：上面的 轮询。

数目阈值清理

1 条数，2 每条的大小。

FIFO: 队列大小是10，

LRU：左神算法。数据访问次数，头部，删尾部。

LinkedHashMap 都可以实现 fifo，lru。

如果空间充足，则缓存多多的，提高命中率。如果空间不够，再回收空间，把空间给其他人让出来。

垃圾回收。

强引用：只要被强引用，就不会被回收。内存不足时，哪怕自己挂掉，也不回收。

软引用：空间不足时，才会被回收。

弱引用，虚引用。

SoftReference。 java实现它。

用java实现一个 根据内存空间大小的使用情况，做一个缓存组件。

Map <k,SoftReference<>>。

实战：

时效性清理+数据阈值式= 1。过期就干掉。2，密集查询，导致空间急剧增大。

LRU+软引用：保证最近用的数据在，然后最近不用的，放到软引用里，用软引用包装一下。

不建议：只用软引用。缓存的存活与否，从业务逃脱。业务控制不了。

---

三高项目

缓存风险点

每增加一个环节，就多一个风险。

缓存穿透

缓存没有数据，数据提供方也没有数据，穿透了。

无效的调用，增加数据提供方的压力，缓存基本无效。

解决方案：在缓存中，缓存一份 空数据。key有值，value为空。

缓存雪崩

大量缓存突然失效，引发的数据提供方压力 骤增。

数据阈值式清理：（缓存是逐个失效的）阈值比较低的时候会。10个缓存。阈值高，可以缓解。

时效式清理：会造成雪崩。避免缓存在同一时刻失效。过期时间=固定值+随机值。错峰失效。

软引用清理：当空间紧张的时候，缓存占据的空间会被回收。单纯的软引用无法解决。lru：对经常访问的数据建立强引用。

缓存击穿

有数据提供方 兜底，不叫穿透。

lru：高频访问的数据，大概率在前面 fifo。

read/write through, write behind。更新机制。缓存里有没有？因为数据的写、更新，先操作的是缓存。

cache aside: 有一个节点，缓存被删除。可能有击穿。

实际工作：

清理机制+更新机制，针对缓存，共同考虑。

缓存预热

启动系统的时候，提前加载一些数据。预加载。

缓存服务启动后，脚步直接灌入。init

时效式清理机制：缓存重复预热。

缓存的位置

需要缓存的数据，一定要靠前。。要想系统性能好，缓存一定要趁早。

前置模块：减少和后端通信的成本。

后置模块：公共模块，尽量用这个方式。

客户端缓存

客户端：浏览器，c软件，安卓，ios，h5，小程序。

浏览器：cookie，过期时间。轻量级的缓存。

F12 application。h5支持 & 浏览器的支持。

sqlite ：安卓端的一个数据库。规则类。开机图片，引导页。

cdn 静态缓存

静态资源：页面，图片。

数据：重点：地名，字典，行业分类，统计局 那些标准化的数据。三级联动。算。广义：与用户个体无关的具有通用性的数据，都可以作为静态数据。

数据：用户不同，参数不同，时间不同，----结果不同。 对系统性能造成负面影响。

服务端缓存

redis。localcache，guava。

数据库缓存

冗余字段，中间表

操作完业务，需要做统计，非实时的数据，让它后置。

新增订单：

insert order (xxxxxx), 统计表 （订单数据 + 1） 10s。

5s， 定时任务扫描（48h-24h） +10。

冗余字段：

订单表（商品的数据）快照。

三高项目

写缓存

读缓存。调用方 数据提供方。

写缓存：调用方和 数据 处理方之间。目的：减少巨量调用操作对数据处理方的冲击。库存。削峰。

消息队列。

写缓存收益：原始时间 <（写缓存时间+缓存中数据向后传递的时间+原始时间）

收益在于用户的角度：目标用户的响应时间 降低了。

读缓存：是以缓存命中的数据 替代 数据提供方的操作。

写缓存：通过增加额外花费的时间，来延迟数据处理方的工作。

写缓存实践：redis(发布订阅)，消息队列（发布订阅），数据库（先生成数据，后期再进行统计，耗时的&对实时性要求不高的，后置）

适合场景：请求峰谷值变化明显&对实时性要求不高的系统中。

抢购系统，竞品系统，秒杀系统，抢红包系统。

消息推送系统：极光，百度。

实时性不高。

大厂：

需求：平峰（请求量在某个阈值之下）：正常处理。峰值超过阈值的时候，触发写缓存。

降级：微服务降级组件处理可以。

灰度发布。配置灰度规则（规则中 请求的阈值，根据阈值的不同，调用不同的系统）。

限流。要对流量进行 评估。

面试：写的访问量增大，怎么处理。

下单：订阅消息，不重要的系统订阅关键 业务的数据。

---