共计 2421 个字符，预计需要花费 7 分钟才能阅读完成。
缓存
在零碎中最耗费性能的中央就是对数据库的拜访了，一般来说，增、删、改操作不会呈现什么性能问题，除非索引太多，并且数据量有非常宏大的状况下，这三个操作才会导致性能问题。个别能够限度单表索引的数量来晋升性能，比方单表的索引数量不能超过 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 的刷盘操作。
毛病：异步就代表数据不是强一致性的，还存在数据失落的危险，实现逻辑也较为简单。
设计思路
无状态的服务
在分布式系统中，无状态的服务有利于横向扩大，所以缓存也应该独立于业务服务在外，设计成一个独立的服务，使业务服务变成无状态的。很多公司都抉择是用 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。
可依据我的项目理论状况进行抉择。
小结
缓存是为了减速数据的拜访，在数据库之上的始终机制，并非所有业务都适宜应用缓存，要依据具体情况抉择更新策略和淘汰策略。
起源：blog.csdn.net/qq_36011946/article/details/104164031
