高并发解决方案,应该如何处理高并发问题?

2020-05-08 13:00:44 java常见问答 4641

在java开发过程中,难免会遇到像高并发这类的问题,那么你有了解过,应该怎么解决高并发的相关问题吗?有兴趣的小伙伴可以跟小编一起来看下呢。

首先是不得不说的求接口的合理设计。一个秒杀或者说抢购页面,一般来说分为2个部分,一个是静态的HTML等内容,另一个就是参与了秒杀的Web后台请求的接口。

一般静态HTML等内容,都是通过CDN的部署的,所以一般压力不会太大,核心瓶颈实际上是在后台请求接口上。这个后端接口,必须是要能够支持高并发请求,同时,也是很重要的一点,就是必须尽可能“快”,在最短的时间里返回用户的请求结果。那么为了实现尽可能快这一点,接口的后端存储使用内存级别的操作会更好一点。这就导致了仍然直接面向MySQL之类的存储是不合适的现象了,如果说有这种复杂业务的需求,都是建议采用异步写入的。

高并发的挑战:一定要“快”。一般衡量一个Web系统的吞吐率的指标是QPS(Query Per Second,每秒处理请求数),解决每秒数万次的高并发场景,这个指标是非常关键的。假设处理一个业务请求平均响应时间是100ms,同时,系统内有20台Apache的Web服务器,配置MaxClients为500个(表示Apache的最大连接数目)。

那么,我们的Web系统的理论峰值QPS为(理想化的计算方式):

20*500/0.1 = 100000 (10万QPS)

在高并发的实际场景下,机器都处于高负载的状态,在这个时候平均响应时间会被大大增加。

其实就Web服务器而言,Apache打开了越多的连接进程,CPU需要处理的上下文切换也越多,额外增加了CPU的消耗,然后就直接导致平均响应时间增加。因此上述的MaxClient数目,是要根据CPU、内存等硬件因素综合考虑的,绝不是越多越好的。

重启与过载保护。如果系统发生“雪崩”,贸然重启服务,是无法解决问题的。最常见的现象就是,启动起来后,立刻就挂掉。这种时候,最好在入口层就将流量拒绝,然后再将重启。如果是redis/memcache这种服务也挂了,重启的时候需要注意“预热”,并且很可能需要比较长的时间。

秒杀和抢购这样的场景,流量往往是超乎我们系统的准备和想象的。这个时候,过载保护是必要的。更合适一点的是,将过载保护设置在CGI入口层,快速将客户的直接请求返回。

好了,以上就本篇文章的所有内容了,还想了解更多java常见问答相关问题,记得关注本站最新消息哦。

推荐阅读:

redis队列实现高并发怎么用?Java如何使用redis队列解决高并发