2.1 高性能

MySQL太久，受不了!

假设一个请求，各种操作MySQL，半天才查出来一个结果，但这结果可能接下来几个小时都不会再变，或变了也可不用立即返给用户。

使用缓存！

折腾半天查出来的结果，扔缓存里，一个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个请求，可能宕机。

3 所以结合上述场景，为啥要用缓存？

一般项目没啥高并发，就别折腾了，直接高性能场景，就思考有没有可以缓存结果的复杂查询场景，后续可以大幅度提升性能，优化用户体验。

文章来源: javaedge.blog.csdn.net，作者：JavaEdge.，版权归原作者所有，如需转载，请联系作者。

原文链接：javaedge.blog.csdn.net/article/details/106189413