高并发那点事

高并发那点事

高并发带来的问题：
1.用户角度
页面加载慢、功能操作后响应时间长、功能无法使用等。
2.开发者角度
接口超时、线程池耗尽、数据库连接池耗尽（https://www.cnblogs.com/sweetchildomine/p/6591692.html）、数据库获取连接时间长、缓存雪崩、导致其他系统功能和业务受到影响等。
问题分析：
个人认为可以从多维度，多角度分析处理高并发问题，系统设计、硬件资源、代码、业务场景，每个维度的处理方式都不相同，但又有一定的联系，无论是硬件、设计、代码基本受限于业务的约束，同时业务的约束又反作用前三者。

分析问题瓶颈：
可通过一些工具（比如arthas)监控调用链，确认时间耗时在哪些地方。
线程池耗尽：可以通过适当增加rpc的线程池的并发数量或者动态扩展机器。
数据库连接池耗尽：适当调整链接池最大并发数量、最大等待时间、连接池活跃数量
获取连接池时间太久：适当缩小最大等待时间（如果不缩小这个时间，可能会导致正常的访问在获取数据库连接的时候会排队，比如后面是查询请求会导致页面一直在加载现象）
常规做法：
设计层面：
1.异步
对于不是必须要等待返回结果的，可以考虑使用异步的方式（多线程、mq）来提高接口的响应。ps:mq的三大作用：异步、削峰、解耦。
2.加缓存
因为大部分的高并发瓶颈在于数据库扛不住压力，应尽可能不让请求落到数据库层面，通过加缓存（redis、本地缓存等）的方式来减少数据库的压力。
3.架构设计上通过分布式等手段实现负载均衡
通过分布式的方式实现动态扩展，比如nginx实现对tomcat的请求分发，redis资源的集群配置，数据库的主从实现读写分离等。
4.服务调用设置超时时间
作用：宏观角度来说，它是为了确保服务链路的稳定性，提供了一种框架级的容错能力。
5.如果rpc接口响应慢，减少不必要的实时rpc调用
举例：获取微信头像等信息，这些信息不常变动，可以在本地缓存，间歇性删除缓存；如果要求必须实时，可以让上游系统在用户更改信息后发个mq通知信息更改本地的缓存数据。
微观角度：
1）有效减少线程池耗尽
2）consumer调用provider，如果不设置超时时间，则consumer的响应时间肯定会大于provider的响应时间。当provider性能变差时，consumer的性能也会受到影响，因为它必须无限期地等待provider的返回。假如整个调用链路经过了A、B、C、D多个服务，只要D的性能变差，就会自下而上影响到A、B、C，最终造成整个链路超时甚至瘫痪，因此设置超时时间是非常有必要的。
3）假设consumer是核心的商品服务，provider是非核心的评论服务，当评价服务出现性能问题时，商品服务可以接受不返回评价信息，从而保证能继续对外提供服务。这样情况下，就必须设置一个超时时间，当评价服务超过这个阈值时，商品服务不用继续等待。
4）provider很有可能是因为某个瞬间的网络抖动或者机器高负载引起的超时，如果超时后直接放弃，某些场景会造成业务损失（比如库存接口超时会导致下单失败）。因此，对于这种临时性的服务抖动，如果在超时后重试一下是可以挽救的，所以有必要通过重试机制来解决。
参考：https://www.cnblogs.com/029zz010buct/p/12576428.html
硬件资源：

	这里主要讲的是对tomcat，redis，mysql等资源的评估，待补充。

代码层面（两个不释放）：事务中数据库连接、数据库锁(x锁）不释放（s锁根据隔离级别而定，rr级别不释放，rc级别释放）。
事务中有数据库加锁操作，在不影响业务的前提下尽量将加锁操作往后放（因为加锁操作只有事务提交后才释放锁）；
应该尽可能减小事务范围，事务中数据库连接不释放，如果事务中有大量计算等耗时工作，尽可能拆分事务，缩小事务粒度。
热点账户问题：
数据库中的锁可能导致热点账户问题，如果数据库中有加锁操作并且加锁锁频率较高，可以通过将热点账户进行拆分，通过锁住子账户来解决（可参考https://blog.csdn.net/xmfsamsara/article/details/80295478）
业务场景：也可以理解为对资源的保护采取的处理措施
1.限流
当服务访问达到阈值的时候，限制访问频率，常用手段有令牌桶算法、漏桶算法、滑动窗口、Guava限流、网关层限流、业务侧代码限流、nginx限流、中间件限流（具体参考：https://blog.csdn.net/sshduanzhijun/article/details/115019205）
2.熔断
当A服务调用B服务的时候，B服务不可用时候，可以Mock一个值来避免A服务一直重试调用B服务导致超时或者导致A服务不可用等问题。
3.服务降级

服务降级中服务调用失败可能导致重试以至于响应超时，甚至最后导致降级失败，所以应该合理设置调用超时时间。详情参考下面的“设置rpc超时时间”。
4.风控
对于部分业务需要校验用户风险等级，把风控调用放业务前面，能拦截部分请求。
5.削峰
对于秒杀等超大访问，可以将请求放入消息队列，下游系统根据自身处理能力去mq中消费请求。

参考文档：
事务内开启线程详解
设置rpc超时时间

限流

热点账户问题