在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常见问答相关问题，记得关注本站最新消息哦。
推荐阅读：