高并发业务的化解之道

在高并发业务中大量的流量冲击，经常会造成服务不可用，这些流量可能是异常的爬虫或者攻击，也有可能就是正常的大促活动，业务系统大多是独立的模块，某个链路节点的不可用不会造成整条链路阻塞，但在首页还真的有这样的问题，首页业务聚合了所有下游服务，一旦被流量冲垮就会造成所有用户不可访问，这样的影响是不可接受的，所以面对首页业务的大流量，其实也是解决高并发的三板斧：缓存，降级，限流

缓存

图片中是我在日常开发过程中积累的，这里的顺序并非随意书写，高并发首当其冲是缓存，因为保证业务的正常运转是很重要的，只有当核心业务可能受损时，才会考虑使用降级或者限流的方式来牺牲一部分用户体验，来换取整体系统的正常运转，所以缓存和其他俩种方式的区别是无损业务的。

正常我们会使用Redis远程缓存+本地缓存的二级缓存模式来处理，这里为什么没有完全采用Redis：1.时间成本，redis是需要进行远程连接的会有一定的访问时延，即时这个耗时已经非常小，但整体访问次数多了也会增加总耗时，而且引入中间件就会存在一些超时或者不可用问题（这里在后面文章细说，集群模式下什么问题都有可能发生），2.费用成本，除了一些追求数据一致性的场景，还有分布式锁这种情况，其实很多数据都可以在本地进行缓存，尤其是更新频率非常低，而且也不会有大对象产生时，本地缓存即能节省时间成本，还能节约服务器资源。架构方案有时并不需要什么技术都塞进来显得高大上，只要能解决问题的就是好办法。

降级

当缓存已经打满还不能解决大流量带来的影响，这时就可以考虑进行降级处理，但降级也要分情况处理，是哪些接口进行降级，还是整体进行降级，我们是否可以抛弃丢边缘非核心业务，给一些非核心流程接口设置调用开关，比如在正常的电商页面里比如商品流接口，当流量访问很大时，我们可以对商品信息中插入的广告或者是其他活动接口进行调用关闭来实现降级，让接口能快速响应保证大部分用户可以看到商品即可，不影响主要交易流程的就可以抛掉，其实这里说的降级也是限流或者熔断的一种。

如果说接口降级只是割须弃袍，那整体降级就是丢盔弃甲了，这里当主要的接口都无法保证时，我们必须构建整体如首页接口的降级，毕竟不能直接抛一个空白或者错误码给用户展示，整体降级已经无法维持核心流程的功能，却是服务最后的体面。

这里说的页面降级是指前端的处理，比如网络不通或者整体机房出现问题，前端势必要缓存之前的页面，或者展示其他提示性内容来降级，比如app端可以缓存最近一次的数据流以备降级使用，而在内部可以不断重试或者发送监控报警消息，通知开发人员及时介入。

限流

服务限流是指在控制层的入口进行限流，可以通过限流中间件或者是自己实现的限流注解来实现，当QPS达到每分钟多少量时及时阻断，可以返回给用户提示：“当前活动太火爆，请稍后再试一试”，限流应该是高并发处理的杀手锏了，这样做确实可以保护系统，但用户体验是相当糟糕的，大部分时候爬虫等异常攻击和普通用户访问是重叠的，我们很难进行甄别处理，就会造成大面积的杀伤力，所以我们尽量保证用户“少看”，而不是“不看”。

上面说爬虫很难甄别，小系统网站的爬虫也许很简单，通过一些访问特征就可以区分，但类似美团淘宝这样的系统，每天都有专业的爬虫团队来访问，双方就在你攻我守之间不断拉扯。但针对简单的IP或者端其实还是可以进行限流的，比如某个IP每秒钟超过10次访问就可以进行限制，或者比如IOS端访问频率一分钟超过30次就可以限流，毕竟很少会有人一直刷刷刷，这些都是简单的防御手段。

总结起来，三板斧可以解决大部分的高并发问题，像是运营大促活动，可以考虑扩容服务器来提升更多的用户体验，解决问题的思路有很多，这些不一定是对的，但却是很多人很多年积累下来的经验。