1 项目中如何使用缓存的？
这个问题大家都懂，反正得有应用场景。
2 为啥用缓存？
缓存，主要用途如下：
2.1 高性能
MySQL太久，受不了!
假设你有个操作，一个请求过来，各种操作MySQL，半天查出来一个结果，耗时600ms。
但这结果可能接下来几个小时都不会再变，或者变了也可以不用立即反馈给用户。那么此时咋办？
使用缓存！
折腾600ms查出来的结果，扔缓存里，一个key对应一个value，下次再有人查，别走MySQL折腾600ms了。
直接从缓存里，通过一个key查出来一个value，2ms搞定。性能提升300倍。
- 即高性能
就是把你一些复杂操作耗时查出来的结果，如果确定后面不咋变了，然后但是马上还有很多读请求，那么直接结果放缓存，后面直接读缓存就好了。
应用场景
某商品信息，在1天之内都不会改变。但是这个商品每次查询一次要耗费2s , 1天要被浏览百万次
用户1请求数据1，第一次检查，发现缓存里没数据1，从 MySQL 里查询耗时 800ms，假设数据1在10分钟之内不再变化
第一次查询之后放入缓存。如果后续数据1变化，只要系统A修改数据库的同时，也更新缓存里的值即可。
第二次检查缓存，缓存里有数据1，直接返回。从缓存里获取数据1返回给用户2 ,耗费10ms
假设10分钟之内有1000个用户都查询了同一个数据
10分钟之内，那1000个用户，每个人查询这个数据都感觉很慢, 800ms
假设10分钟之内数据没有变化，然后1000个人来查询这条数据，第一个人是800ms ,后面999个人都是
取数据10ms就可以看到结果
2.2 高并发
应用场景
查电商里的商品, 3/4的数据放在缓存, 1/4的数据留在数据库。
在中午高峰期,有100万用户同时访问系统A，每秒有4000个请求去查询MySQL，其中3000个请求走缓存; 1000个请求走MySQL
- 为什么数据库支撑不了高并发，然后缓存可以支撑高并发呢?
缓存是走内存的，内存天然就可以支撑。别说是4000/s , 4万/s请求也没问题
但是数据库一般建议并发请求不要超过2000/s，如果数据承载每秒4000个请求，可能会宕机。
MySQL天然支持不好高并发。MySQL单机支撑到2000qps就开始容易报警。
所以要是你有个系统，高峰期一秒钟过来的请求有1万，那一个 MySQL单机绝对会死掉。
你这个时候就只能上缓存，把很多数据放缓存，别放mysql。
缓存功能简单，说白了就是key-value式操作，单机支撑的并发量轻松一秒几万十几万，并发量是MySQL单机的几十倍。
3 所以结合上述场景，为啥要用缓存？
一般项目里没啥高并发，别折腾了，直接高性能场景，就思考有没有可以缓存结果的复杂查询场景，后续可以大幅度提升性能，优化用户体验。
4 缓存的不良后果
常见的缓存问题：
- 缓存与数据库双写不一致
- 缓存雪崩
- 缓存穿透
- 缓存并发竞争