缓存三大矛盾问题总结
1、缓存实时性和一致性问题：当有了写入后咋办？
虽然使用了缓存，大家心里都有一个预期，就是实时性和一致性得不到完全的保证，毕竟数据保存了多份，数据库一份，缓存中一份，当数据库中因写入而产生了新的数据，往往缓存是不会和数据库操作放在一个事务里面的，如何将新的数据更新到缓存里面，什么时候更新到缓存里面，不同的策略不一样。
从用户体验角度，当然是越实时越好，用户体验越流畅，完全从这个角度出发，就应该有了写入，马上废弃缓存，触发一次数据库的读取，从而更新缓存。但是这和第三个问题，高并发就矛盾了，如果所有的都实时从数据库里面读取，高并发场景下，数据库往往受不了。
2、缓存的穿透问题：当没有读到咋办？
为什么会出现缓存读取不到的情况呢？
第一：可能读取的是冷数据，原来从来没有访问过，所以需要到数据库里面查询一下，然后放入缓存，再返回给客户。
第二：可能数据因为有了写入，被实时的从缓存中删除了，就如第一个问题中描述的那样，为了保证实时性，当数据库中的数据更新了之后，马上删除缓存中的数据，导致这个时候的读取读不到，需要到数据库里面查询后，放入缓存，再返回给客户。
第三：可能是缓存实效了，每个缓存数据都会有实效时间，过了一段时间没有被访问，就会失效，这个时候数据就访问不到了，需要访问数据库后，再放入缓存。
第四：数据被换出，由于缓存内存是有限的，当使用快满了的时候，就会使用类似LRU策略，将不经常使用的数据换出，所以也要访问数据库。
第五：后端确实也没有，应用访问缓存没有，于是查询数据库，结果数据库里面也没有，只好返回客户为空，但是尴尬的是，每次出现这种情况的时候，都会面临着一次数据库的访问，纯属浪费资源，常用的方法是，讲这个key对应的结果为空的事实也进行缓存，这样缓存可以命中，但是命中后告诉客户端没有，减少了数据库的压力。
无论哪种原因导致的读取缓存读不到的情况，该怎么办？是个策略问题。
一种是同步访问数据库后，放入缓存，再返回给客户，这样实时性最好，但是给数据库的压力也最大。
另一种方式就是异步的访问数据库，暂且返回客户一个fallback值，然后同时触发一个异步更新，这样下次就有了，这样数据库压力小很多，但是用户就访问不到实时的数据了。
3、缓存对数据库高并发访问：都来访问数据库咋办？
我们本来使用缓存，是来拦截直接访问数据库请求的，从而保证数据库大本营永远处于健康的状态。但是如果一遇到不命中，就访问数据库的话，平时没有什么问题，但是大促情况下，数据库是受不了的。
一种情况是多个客户端，并发状态下，都不命中了，于是并发的都来访问数据库，其实只需要访问一次就好，这种情况可以通过加锁，只有一个到后端来实现。
另外就是即便采取了上述的策略，依然并发量非常大，后端的数据库依然受不了，则需要通过降低实时性，将缓存拦在数据库前面，暂且撑住，来解决。
二、解决缓存三大矛盾的刷新策略
1、实时策略
所谓的实时策略，是平时缓存使用的最常用的策略，也是保持实时性最好的策略。
读取的过程，应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。如果命中，应用程序从cache中取数据，取到后返回。
写入的过程，把数据存到数据库中，成功后，再让缓存失效，失效后下次读取的时候，会被写入缓存。那为什么不直接写缓存呢？因为如果两个线程同时更新数据库，一个将数据库改为10，一个将数据库改为20，数据库有自己的事务机制，可以保证如果20是后提交的，数据库里面改为20，但是回过头来写入缓存的时候就没有事务了，如果改为20的线程先更新缓存，改为10的线程后更新缓存，于是就会长时间出现缓存中是10，但是数据库中是20的现象。
这种方式实时性好，用户体验好，是默认应该使用的策略。
2、异步策略
所谓异步策略，就是当读取的时候读不到的时候，不直接访问数据库，而是返回一个fallback数据，然后往消息队列里面放入一个数据加载的事件，在背后有一个任务，收到事件后，会异步的读取数据库，由于有队列的作用，可以实现消峰，缓冲对数据库的访问，甚至可以将多个队列中的任务合并请求，合并更新缓存，提高了效率。
当更新的时候，异步策略总是先更新数据库和缓存中的一个，然后异步的更新另一个。
一是先更新数据库，然后异步更新缓存。当数据库更新后，同样生成一个异步消息，放入消息队列中，等待背后的任务通过消息进行缓存更新，同样可以实现消峰和任务合并。缺点就是实时性比较差，估计要过一段时间才能看到更新，好处是数据持久性可以得到保证。
一是先更新缓存，然后异步更新数据库。这种方式读取和写入都用缓存，将缓存完全挡在了数据库的前面，把缓存当成了数据库在用。所以一般会使用有持久化机制和主备的redis，但是仍然不能保证缓存不丢数据，所以这种情况适用于并发量大，但是数据没有那么关键的情况，好处是实时性好。
在实时策略扛不住大促的时候，可以根据场景，切换到上面的两种模式的一个，算是降级策略。
3、定时策略
如果并发量实在太大，数据量也大的情况，异步都难以满足，可以降级为定时刷新的策略，这种情况下，应用只访问缓存，不访问数据库，更新频率也不高，而且用户要求也不高，例如详情，评论等。
这种情况下，由于数据量比较大，建议将一整块数据拆分成几部分进行缓存，而且区分更新频繁的和不频繁的，这样不用每次更新的时候，所有的都更新，只更新一部分。并且缓存的时候，可以进行数据的预整合，因为实时性不高，读取预整合的数据更快。
作者：远方的梦Java
链接：https://www.jianshu.com/p/26be2d07d74b