如何通过缓存来提升系统性能

我不是女神ヾ 2022-10-18 12:44 197阅读 0赞

**点击关注公众号，利用****碎片时间学习****![f28d5444fee0d25c7cecc26c6e1bcd72.png][]**

## 缓存 ##

在系统中最消耗性能的地方就是对数据库的访问了，一般来说，增、删、改操作不会出现什么性能问题，除非索引太多，并且数据量有十分庞大的情况下，这三个操作才会导致性能问题。一般可以限制单表索引的数量来提升性能，比如单表的索引数量不能超过5个。

绝大多数情况下，性能问题都出在查询上，select操作提供了非常丰富的语法，这些语法包括函数，子查询，like子句，where子句等，这些查询都是非常消耗性能的。大部分应用都是读多写少的应用，所以查询慢的问题会被放大了，导致慢查询成为了系统性能的瓶颈，这是就需要用到缓存来提高系统的性能。

**缓存为什么能提供系统性能？**

缓存通过减少系统对数据库的访问量来提高系统性能。试想一下，如果有100个请求同时请求同一个数据，没有加缓存之前，需要访问100次数据库，而加了缓存之后，可能只需访问1次数据库，剩下的99个请求的数据从缓存中取，大大的较少了数据库的访问量，虽然同样需要访问100次，但数据库的读取性能和缓存的读取性能不在一个级别上，所以对系统性能提升显著。为什么说可能需要访问1次数据库呢，这个和过期有关，后面会讲。

### 更新模式 ###

既然知道了缓存对系统性能提升显著，那下面先来了解一下缓存如何更新吧。

#### Cache Aside（推荐） ####

这应该是最常用的更新模式了，这种模式大致流程如下：

**读取**

*  如果缓存中没有，则再从数据库中读取数据，得到数据之后，放入缓存。
 *  如果缓存中有，取到后直接返回。

**更新**

*  先更新数据库里的数据，成功后，让缓存失效。

##### 为什么是让缓存失效而不是更新缓存呢？ #####

主要是因为两个并发写操作导致脏数据。试想一下，有两个线程A和B，分别要将资源A的值修改为1和2，线程A先到达数据库把数据更新为1，但还没更新缓存，由于时间片用完了，此时线程B获得了CPU，并在这期间把数据库资源A的值和缓存的值都更新为2，线程B结束后，线程A重新获得CPU，执行更新缓存，把资源A的值改为1，线程A结束。此时，数据库中A的值为2，而缓存中A的值为1，数据不一致。所以让缓存失效就不会有这个问题，保证缓存中的数据和数据库的保持一致。

##### 那是不是Cache Aside模式就不会有并发问题了呢？ #####

不是的。比如，一个读操作，没有命中缓存，就去数据的读取数据（A=1），此时一个写操作，更新数据库数据（A=2）并让缓存失效，此时读操作把读取到的数据（A=1）写到缓存中，导致脏数据。

这种情况理论上会出现，但现实情况中出现的几率极低。要这种情况出现必须在一个读操作发生时，有一个并发写操作，并且既要读操作要于写操作写入前读取，又要后于写操作写入缓存。满足这种条件的概率并不大。

基于出现上面所描述的问题，目前有两种比较合理的解决方案：

*  通过2PC这种保证数据的一致性（复杂）；
 *  通过降低并发时脏数据的概率，并设置合理的过期时间（简单，但存在一定时间内的错误率，一般可以接受）。

#### Read/Write Through ####

在这种模式下，对于应用程序来说，所有的读写请求都是直接和缓存打交道，关于数据库的数据完全由缓存服务来更新（更新同步为同步操作）。

这种模式下流程就相当简单了，完全就是对缓存的读写。

缺点：这种模式对缓存服务有强依赖性，要求缓存具备高可用性。所以应有没有上一种普遍。

#### Write Behind Caching ####

其实这个模式就是Read/Write Through的一个变种，区别就在于前者是异步更新，后者是同步更新。

既然是异步更新数据库，他的相应速度比Read/Write Through还要高，并且还能合并对同一个数据的多次操作。这个有点像MySQL的buffer pool的刷盘操作。

缺点：异步就代表数据不是强一致性的，还存在数据丢失的风险，实现逻辑也较为复杂。

## 设计思路 ##

### 无状态的服务 ###

在分布式系统中，无状态的服务有利于横向扩展，所以[缓存也应该独立][Link 1]于业务服务在外，设计成一个独立的服务，使业务服务变成无状态的。很多公司都选择是用Redis来搭建他们的缓存系统，取决于其高速的读写性能。

### 命中率 ###

一个缓存服务的好坏主要看命中率，一般来说，命中率保存在80%以上已经算很高了，但我们不能为了提高命中率而把数据库的全部数据的写到缓存了，这个是不符合缓存的设计理念，而且需要极大的内存空间。**通常来说，应该只有小部分热点数据写到缓存。** 缓存是通过牺牲强一致性来换取性能的，并不是所有的业务的适合使用缓存。

### 有效时间 ###

缓存数据的有效时间不易过短，不易过长，不易过于集中。

*  过短，会增加数据库访问的次数。
 *  过长容易不使用的数据一直停留在缓存中，浪费空间，并且一旦产生脏数据，过程的有效时间会导致脏数据迟迟无法失效，进而导致影响更多的业务。
 *  过于集中，会导致缓存雪崩。

### 淘汰策略 ###

当内存不足时，缓存系统就要按照淘汰策略，把不适合留在缓存的数据淘汰掉，腾出位置给新数据。下面就以Redis为例，给出了淘汰策略：

*  `noeviction`: 不删除策略, 达到最大内存限制时, 如果需要更多内存, 直接返回错误信息(有极少数会例外, 如 DEL )。
 *  `allkeys-lru`: 所有key通用，优先删除最近最少使用(less recently used ,LRU) 的 key。（推荐）
 *  `volatile-lru`: 只限于设置了 expire 的部分，优先删除最近最少使用(less recently used ,LRU) 的 key。
 *  `allkeys-random`: 所有key通用，随机删除一部分 key。
 *  `volatile-random`: 只限于设置了 expire 的部分，随机删除一部分 key。
 *  `volatile-ttl`: 只限于设置了 expire 的部分，优先删除剩余时间(time to live,TTL) 短的key。

可根据项目实际情况进行选择。另外，欢迎关注公众号Java笔记虾，后台回复“后端面试”，送你一份面试题宝典！

## 小结 ##

缓存是为了加速数据的访问，在数据库之上的一直机制，并非所有业务都适合使用缓存，要根据具体情况选择更新策略和淘汰策略。

*（感谢阅读，希望对你所有帮助)*

*来源：blog.csdn.net/qq\_36011946/article/details/104164031*

推荐好文

[强大，10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程！][10k_ SpringBoot]

[分享一套基于SpringBoot和Vue的企业级中后台开源项目，代码很规范！][SpringBoot_Vue]

[能挣钱的，开源 SpringBoot 商城系统，功能超全，超漂亮][SpringBoot]![4741f6248b93596541642acef5984fc9.png][]

[f28d5444fee0d25c7cecc26c6e1bcd72.png]: /images/20221005/ed3891e9877c48578c1b8db2293bd0ea.png
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc79a1c9cb0e28df8f63b686afcea25b5d29ff511fd17efab0cc052cf35470d93d5d4f4b2823&idx=2&mid=2247502951&scene=21&sn=338925dbe072c9aa138044d52e11ee76#wechat_redirect
[10k_ SpringBoot]: http://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ%3D%3D&chksm=ebd5c411dca24d07446a4f22772cd12d2cc1143b62eb922a14500ae981cd57fb850ef74ca257&idx=2&mid=2247498557&scene=21&sn=84902d7030e174e152615d8fae3755cc#wechat_redirect
[SpringBoot_Vue]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc799be6cb0e12f0b58479f8b031bc5ae79efdca1880ff9b19f0a107c3a88c37b9596dc73203&idx=2&mid=2247497288&scene=21&sn=65d7111a19e920df1e9416959594b2f4#wechat_redirect
[SpringBoot]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc799a9ccb0e138a64a2671f31b8d4be1b3c061a288f7b0d1d4af02a60c45a72231446b91e00&idx=2&mid=2247497522&scene=21&sn=c5b4e596be4ac7d7f293e7e2f0ea0769#wechat_redirect
[4741f6248b93596541642acef5984fc9.png]: /images/20221005/6a7a3446f3834d64ab58da630da324c8.png