性能瓶颈解决思路
硬件层面：机器扛得住
架构设计：做好服务拆分
代码层面：做好缓存、削峰、解耦
-
数据库：读写分离、分库分表
-
监控：熔断、限流、降级
总结
事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。
事中：本地 ehcache 缓存 + Hystrix 限流+降级，避免MySQL 被打死。
事后：Redis 持久化 RDB+AOF，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。
数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。 只要数据库不死，就是说，对用户来说，3/5 的请求都是可以被处理的。 只要有 3/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来一次。
这个在目前主流的互联网大厂里面是最常见的，你是不是好奇，某明星爆出什么事情，你发现你去微博怎么刷都空白界面，但是有的人又直接进了，你多刷几次也出来了，现在知道了吧，那是做了降级，牺牲部分用户的体验换来服务器的安全，可还行？
出bug了，大家一定要理解是怎么发生的，以及是怎么去避免的，发生之后又怎么去抢救，你可以不是知道很深入，但是你不能一点都不去想，
测试关注点：
引入缓存之后就还要考虑缓存击穿、雪崩、热点一系列的问题了
缓存概述
核心作用：加快取用的速度
缓存作为高性能的代表，在某些特殊业务可能承担90%以上的热点流量。对于一些活动比如秒杀这种并发QPS可能几十万的场景，引入缓存事先预热可以大幅降低对数据库的压力，10万的QPS对于单机的数据库来说可能就挂了
缓存选型
在项目中使用redis做为缓存，还没有使用memcache,考虑因素主要有两点：
1.redis丰富的数据结构,其hash,list,set以及功能丰富的String的支持，对于实际项目中的使用有很大的帮忙。（可参考官网redis.io）
2.redis单点的性能也非常高效（利用项目中的数据测试优于memcache）.
作者：欣然 链接：https://zhuanlan.zhihu.com/p/112885553 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
场景预设-秒杀系统
预热商品信息：可以提前缓存提供查询服务
库存数据：可以提前缓存，下单流程可以完全走缓存扣减，秒杀结束后再异步写入数据库。
热key
有几十万的请求去访问redis上的某个特定key，那么这样会造成流量过于集中，达到物理网卡上限，从而导致这台redis的服务器宕机引发雪崩
针对热key的解决方案：
提前把热key打散到不同的服务器，降低压力
加入二级缓存，提前加载热key数据到内存中，如果redis宕机，走内存查询
缓存击穿
单个key并发访问过高，过期时导致所有请求直接打到db上
缓存穿透
缓存穿透是指查询不存在缓存中的数据，每次请求都会打到DB，就像缓存不存在一样。
解决方案：
加一层布隆过滤器
缓存雪崩
大量的请求进来直接打到DB上，这样可能导致整个系统的崩溃，称为雪崩。雪崩和击穿、热key的问题不太一样的是，他是指大规模的缓存都过期失效了。
解决方案：
针对不同key设置不同的过期时间，避免同时过期
限流，如果redis宕机，可以限流，避免同时刻大量请求打崩DB
二级缓存，同热key的方案。
