前言
对于Web来说，用户量和访问量增肯定水平上推动我的项目技术和架构的更迭和提高。可能会有以下的一些情况：
- 页面并发量和访问量并不多，MySQL
足以撑持本人逻辑业务的倒退。那么其实能够不加缓存。最多对动态页面进行缓存即可。 - 页面的并发量显著增多，数据库有些压力，并且有些数据更新频率较低
重复被查问或者查问速度较慢。那么就能够思考应用缓存技术优化。对高命中的对象存到key-value模式的Redis中，那么，如果数据被命中，那么能够不通过效率很低的db。从高效的redis中查找到数据。 - 当然，可能还会遇到其余问题，你还通过动态页面缓存页面、cdn减速、甚至负载平衡这些办法进步零碎并发量。这里就不做介绍。
缓存思维无处不在
咱们从一个算法问题开始理解缓存的意义。
问题1：
- 输出一个数n(n<20),求
n！；
剖析1：
- 单单思考算法，不思考数值越界问题。 当然咱们晓得
n!=n * (n-1) * (n-2) * ... * 1= n * (n-1)!; 那么咱们能够用一个递归函数解决问题。
static long jiecheng(int n) { if(n==1||n==0)return 1; else { return n*jiecheng(n-1); }}复制代码这样每输出求一次须要执行n次。 问题2：
- 输出t组数据(可能成千盈百)，每组一个xi(xi<20),求
xi！；
剖析2：
- 如果应用
递归,输出t组数据，每次输出为xi，那么每次都要执行次数为： 当每次输出的Xi过大或者t过大都会造成不小的累赘！工夫复杂度为O(n2) - 那么是否换个思维的。没错、是
打表。打表罕用于ACM算法中，罕用于解决多组输入输出、图论搜寻后果、门路贮存问题。那么，对于这个求阶乘。咱们只须要申请一个数组，依照编号从前往后将在需要的数存到数组中，前面再获得时候间接输入数组值就能够，思维很明确吧:
import java.util.Scanner;public class test {public static void main(String[] args) { // TODO Auto-generated method stub Scanner sc=new Scanner(System.in); int t=sc.nextInt(); long jiecheng[]=new long[21]; jiecheng[0]=1; for(int i=1;i<21;i++) { jiecheng[i]=jiecheng[i-1]*i; } for(int i=0;i<t;i++) { int x=sc.nextInt(); System.out.println(jiecheng[x]); }} }复制代码- 工夫复杂度才O(n)。这里的思维就和
缓存思维差不多。先将数据在jiecheng[21]数组中贮存。执行一次计算。当前面持续拜访的时候就相当于当问动态数组值。每次都为O(1的操作)。
缓存的利用场景
缓存实用于高并发的场景，晋升服务容量。次要是将从常常被拜访的数据或者查问老本较高从慢的介质中存到比拟快的介质中，比方从硬盘—>内存。咱们晓得大多数关系数据库是基于硬盘读写的，其效率和资源无限，而redis是基于内存的，其读写速度差异差异很大。当并发过高关系数据库性能达到瓶颈时候，就能够策略性将常拜访数据放到Redis进步零碎吞吐和并发量。
对于罕用网站和场景，关系数据库次要可能慢在两个中央：
- 读写IO性能较差
- 一个数据可能通过较大量计算失去
所以应用缓存可能缩小磁盘IO次数和关系数据库的计算次数。读取上速度快也从两个方面体现：
- 基于内存，读写较快
- 应用哈希算法间接定位后果不须要计算
所以对于像样的，有点规模的网站，缓存是很 necessary的，而Redis无疑是最好的抉择之一。
须要留神的问题
缓存使用不当会带来很多问题。所以须要对一些细节进行认真考量和设计。当然最难得数据一致性在上面独自剖析。
是否用缓存
我的项目不能为了用缓存而用缓存，缓存并肯定适宜所有场景，如果对数据一致性要求极高，又或者数据频繁更改而查问并不多，又或者基本没并发量的、查问简略的不肯定须要缓存，还可能浪费资源使得我的项目变得臃肿难保护，并且应用redis缓存多多少少可能会遇到数据一致性问题须要思考。
缓存正当设计
在设计缓存的时候，很可能会遇到多表查问，如果遇到多表查问缓存的键值对就须要正当思考，是拆分还是合在一起？当然如果组合品种多但常呈现的不多也能够间接缓存，具体的设计要依据我的项目业务需要来看，并没有一个十分相对的规范。
过期策略抉择
- 缓存装的是绝对热点和罕用的数据，Redis资源也是无限，须要抉择一个正当的策略让缓存过期删除。咱们学过
操作系统也晓得在计算机的缓存实现中有先进先出的算法（FIFO）；最近起码应用算法（LRU）；最佳淘汰算法（OPT）；起码拜访页面算法（LFR）等磁盘调度算法。设计Redis缓存时候也能够借鉴。依据工夫来的FIFO是最好实现的。且Redis在全局key反对过期策略。 - 并且过期工夫也要依据零碎状况正当设置，如果硬件好点以后能够略微久一点，然而过期工夫过久或者过短可能都不太好，过短可能缓存命中率不高，而过久很可能造成很多冷门数据存储在Redis中不开释。
数据一致性问题★
下面其实提到数据一致性问题。如果对一致性要求极高那么不倡议应用缓存。上面略微梳理一下缓存的数据。 在Redis缓存中常常会遇到数据一致性问题。对于一个缓存，上面列举几种状况：
读
read：从Redis中读取，如果Redis中没有，那么就从MySQL中获取更新Redis缓存。 上面流程图形容惯例场景，没啥争议：
写1：先更新数据库，再更新缓存(一般低并发)
更新数据库信息，再更新Redis缓存。这是惯例做法，缓存基于数据库，取自数据库。
然而其中可能遇到一些问题，例如上述如果更新缓存失败(宕机等其余情况)，将会使得数据库和Redis数据不统一。造成DB新数据，缓存旧数据。
写2：先删除缓存，再写入数据库(低并发优化)
解决的问题
这种状况可能无效防止写1中避免写入Redis失败的问题。将缓存删除进行更新。现实是让下次访问Redis为空去MySQL获得最新值到缓存中。然而这种状况仅限于低并发的场景中而不实用高并发场景。
存在的问题
写2尽管可能看似写入Redis异样的问题。看似较为好的解决方案然而在高并发的计划中其实还是有问题的。咱们在写1探讨过如果更新库胜利，缓存更新失败会导致脏数据。咱们现实是删除缓存让下一个线程拜访适宜更新缓存。问题是：如果这下一个线程来的太早、太巧了呢？
因为多线程你也不晓得谁先谁后，谁快谁慢。如上图所示状况，将会呈现Redis缓存数据和MySQL不统一。当然你能够对key进行上锁。然而锁这种重量级的货色对并发性能影响太大，能不必锁就别用！上述情况就高并发下仍然会造成缓存是旧数据，DB是新数据。并且如果缓存没有过期这个问题会始终存在。
写3：延时双删策略
这个就是延时双删策略，能过缓解在写2中在更新MySQL过程中有读的线程进入造成Redis缓存与MySQL数据不统一。办法就是删除缓存->更新缓存->延时(几百ms)(可异步)再次删除缓存。即便在更新缓存途中产生写2的问题。造成数据不统一，然而延时(具体实间依据业务来，个别几百ms)再次删除也能很快的解决不统一。
然而就写的计划其实还是有破绽的，比方第二次删除谬误、多写多读高并发状况下对MySQL拜访的压力等等。当然你能够抉择用MQ等音讯队列异步解决。其实理论的解决很难顾及到十拿九稳，所以不少大佬在设计这一环节可能会因为一些纰漏会被喷。作为菜菜的笔者在这里就更不献丑了，各位大佬欢送奉献你们的计划。
写4：间接操作缓存，定期写入sql(适宜高并发)
当有一堆并发(写)扔过去的后，后面几个计划即便应用音讯队列异步通信但也很难给用户一个舒服的体验。并且对大规模操作sql对系统也会造成不小的压力。所以还有一种计划就是间接操作缓存，将缓存定期写入sql。因为Redis这种非关系数据库又基于内存操作KV相比传统关系型要快很多。
下面实用于高并发状况下业务设计，这个时候以Redis数据为主，MySQL数据为辅助。定期插入(如同数据备份库一样)。当然，这种高并发往往会因为业务对读、写的程序等等可能有不同要求，可能还要借助音讯队列以及锁实现针对业务上对数据和程序可能会因为高并发、多线程带来的不确定性和不稳定性，进步业务可靠性。
总之，越是高并发、越是对数据一致性要求高的计划在数据一致性的设计方案须要思考和顾及的越简单、越多。上述也是笔者针对Redis数据一致性问题的学习和自我发散(胡扯)学习，欢送进群973961276一起来吹水聊技术，如果有解释了解不合理或者还请各位大佬斧正！