1.微服务中的雪崩效应如何解决?(高并发的解决方案）
答:先说高并发会造成哪些现象。比如1.大量客户端请求超时(一直再转)，甚至无法访问。2.服务器内存溢出，直接down了。3.导致数据库甚至redis超时,死机。再针对各个点说解决方案。比如针对1,对服务进行降级处理。这里的降级限制分为3个点。1.每秒请求数量限制(每台服务器中的服务每秒超过100个请求，100以后的直接调用本地降级的处理方案)2.每个请求的返回时间限制(超过100毫秒做降级处理,直接调用本地方法返回,不用再等待)。3.对本服务中的个别大流量的接口做隔离(通过线程池和信号量)。用springCloud中的表达就是服务的熔断(1,2),降级(走本地方法)和隔离(3)。实现就是1.针对单个方法在需要处理的方法上添加注解@HystrixCommand(fallbackMethod = "降级的方法")。2.针对整个接口上@FeignClient(value ="service-member", fallback = 降级的类.class)，降级的类中实现接口写各个降级的方法。针对2,在1的基础上对服务进行扩容，这边大流量应该提前有心里准备做好扩容。针对3.数据库做主从，一主多从，redis做高可用集群，正常一般互联网公司的redis都是用的阿里云的集群高可用版本，起码在每秒8万的并发。针对前端的请求尽量查询redis,不要把压力放在数据库。如果是数据一致性有强一致性要求(比如商品的库存)则要想变通的办法。比如预占的模式(自己可百度详细的学习，参考12306秒杀扣库存的艺术)。如果是像京东这类的大公司的销售库存直接基于redis,不用数据库。有技术实力的公司可以这样搞(你要保证redis的数据绝对安全性),正常的互联网公司还是用预占的模式比较靠谱。还有一些互联网公司根本就没有考虑库存的强一致性问题,采用更新数据库，然后更新或者删除redis的方式这种再高并发下是不可取的。(关于如何保证强一致性我后面会写文章或者视频讲解,可以先关注我的微信公众号Java面试题精讲)
网友评论