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 所以结合上述场景，为啥要用缓存？
一般项目没啥高并发，就别折腾了，直接高性能场景，就思考有没有可以缓存结果的复杂查询场景，后续可以大幅度提升性能，优化用户体验。
