【HBZ分享】后端如何抗高并发

需要考虑的维度

1. JVM
2. 数据库(包括兜底的分库分表)
3. 缓存
4. MQ
5. 网关
6. 硬件配置

如何优化去抗击高并发

1. jVM层面：合理选择垃圾回收器，配置合理参数，比如选G1或ZGC，比如配置堆内存大小。其最终目的都是为了减少GC频率，减少STW的频率。
2. Redis缓存：使用Redis缓存来减少Mysql压力。当然使用redis做缓存，要考虑redis和mysql之间的数据一致性问题。还要注意redis的3问题–>击穿，穿透，雪崩
3. 数据库：数据库层面要配置定位慢查询的监控，然后进行sql优化，如果基本优化都无效，并且数据量巨大，也可使用【分库分表】来解决。但分库分表绝对是兜底解决方案，不是优先选择方案，因为分库分表要面临很复杂的问题，比如后期扩容，分片键的选择，都会影响分库分表性能。
4. 接口限流： 接口要做限流，不能无限制的接受请求，比如谷歌的guava，阿里巴巴的sentinel， 基于Redis等方案，原理大多都是【令牌桶算法】，【漏桶算法】， 【滑动窗口算法】这些。
5. MQ削峰(前提是无需强同步)：请求接口时，把参数保存到MQ，发送到MQ消息容器中，在创建对应消费者，对这些请求进行消费。当然在高并发下，一条条的向MQ发送，即使MQ可能也扛不住，此时可以创建一个缓冲队列，比如1秒发送一次，或者积攒到多少个请求再发送都可以。 为了避免消息太多，延迟消费，建议采用多消费者来进行消费，可以通过K8S的自动扩容来解决，并且消费者也会根据自己能力获取对应数量消息，不像接口来多少处理多少
6. 网关保护：nginx，gateway都可以，推荐nginx。也可以nginx + gateway结合，nginx是通过C语言写的，gateway是java语言写的，nginx的性能会更高，但需要掌握lua语言。
7. 服务降级： 如果某个接口掉了10次，失败了7-8次这种高概率失败，就要做熔断了，当前一段时间不能再调用该接口。熔断的底层是采用【滑动窗口】实现的