本人对java高并发理解有一些误解，希望能帮忙指正下。大侠进

Question

我的理解，，高并发就是在大量用户同一时段浏览网站，包括访问主页，查询信息，或者其他操作。所有的请求涌入服务器；这个时候服务器压力很大；这就是我目前理解的高并发。然后网站开发可能会用到消息队列，如:rabbitmq, 当执行秒杀活动的时候，前端大量的请求涌入后台控制器，这里我理解有高并发存在，所以我觉得有问题，这里可能让服务器崩溃；假如此时前端请求都被处理了，把信息写入了rabbitMq,然后接口也消费了这些消息；但是处理了需要把结果反馈给前端，我看有的人是在前端轮训查询后台数据库里面的信息，或者查询redis里面的数据。这样的话，实际上还是有海量的数据在访问服务器，我感觉这样根本就没有解决问题；还有访问服务器的请求 跟 访问数据库的请求，是不是不一样，有什么区别。
希望大神们能指正下高并发真正的处理以及原理；

Answer 1

我觉得所谓的高并发，一般是指同一个业务（同一个接口），在同一个时刻被大量请求
你上面说的有点笼统了，比方说A,B两个接口分别是完全不关联的两个业务，现在在同一时刻有大量的请求请求你服务器，但是大部分是请求A，少量请求B，这个时候B没有高并发
关于如何处理的话，我觉得还是得根据业务吧，有业务前提能更好考虑

Answer 2

如果A请求占用了大量cpu，内存等资源，导致B 无法访问，，这个应该统一算 系统的高并发吧，而不是单一的某个业务。

Answer 3

如果A请求占用了大量cpu，内存等资源，导致B 无法访问，，这个应该统一算 系统的高并发吧，而不是单一的某个业务。
那说到底还是A得问题，难道你还去优化B不成？

Answer 4

如果A请求占用了大量cpu，内存等资源，导致B 无法访问，，这个应该统一算 系统的高并发吧，而不是单一的某个业务。
你这种场景一般就拆分服务,A,B独立部署,A增加集群机器
如果是上面你说的,压力都是数据库写上,用mq只是流量削峰罢了,查询可以做读写分离
总的思路是,让系统平稳运行,必要是舍弃不重要的服务,服务拆分,压力分摊上面我都没怎么实践过,都是瞎编的

Answer 5

高并发的瓶颈主要在数据库服务器上，如果每个请求都立即去查数据库，数据库响应慢了必定会造成请求堆积，最终会出现雪崩效应拖垮整个系统，其实处理业务的服务器基本上都不会有太大的并发压力，因为即使处理很复杂的逻辑代码所用的时间也不过几十毫秒。所以一般高并发场景中缓存很重要，缓存是放在内存中的，可以很轻松的支撑百万至千万的并发量，况且还有nginx来挡掉大部分请求。所以整个请求链大致是：前端、nginx、网关、后台服务器、redis、数据库。像秒杀类场景，在秒杀未开始时，只返回一个静态页面及系统时间，大部分请求只到nginx就被返回了，而不会达到后台服务器。

Answer 6

高并发是集成的事情，不是单纯的编程，网络，服务器（特别是软件服务）部署方案才是核心是不是把你的java高并发 限定为单一jvm中高并发？

Answer 7

ding..........................................................................

Answer 8

短时间内单个服务器处理大量请求的效率是有限的，比如tomcat，每有一个请求都会起一个线程去处理，也就是说一个进程里有多个线程在
跑，这样并发访问很大的时候性能就很低了。具体能承载多少并发，需要看硬件的配置，CPU 越多性能越高，分配给JVM的内存越多性能也就越高，但也会加重GC的负担。操作系统对于进程中的线程数有一定的限制：Windows 每个进程中的线程数不允许超过 2000，Linux 每个进程中的线程数不允许超过 1000，在Java中每开启一个线程需要耗用1MB的JVM内存空间用于作为线程栈之用，此处也应考虑。为了解决这种问题，首先想到就是集群，想办法让请求都从一个入口进来，通过一定的策略去访问集群中的某一台服务器，还要让访问在一个集群里的任何一个服务器的效果都一样。
还有一个方法是分布式， 在一个项目里可能有多个模块，可能有的模块被访问的量比较大而有的模块却比较少， 这个时候如果它们在一个项目部署在一个服务器上， 那个访问较少的模块就浪费了资源， 所以可以把访问比较多并发比较高的模块拿出来搞个集群，其他的模块不弄集群，或者弄个小集群。个人的理解，有错的地方希望大家指正

Answer 9

ddd.......................................................................

Answer 10

首先高并发是秒级的，同时的，大量请求同时进入服务器，服务器进行处理，如果同时处理的数量过多的话，会导致CUP不足然后挂了，使用队列的意思就是，把这些同时的 大量的请求 让服务器不同时的处理，比如同时进来100个请求，放到队列里，服务器可能只能同时处理10个，那就从队列里取出来10个进行处理，处理完了之后返回给前端10个，这样就拉长了时间但是把所有请求都处理完了。服务器和数据库请求同理。

Answer 11

首先要说的是高并发方案，是个综合的方案，不是单一的使用了某个组件或者开源的框架就能解决的。
1.高并发最常见的方案是负载均衡，就是增加机器，比如有5000个请求，以前1台机器，现在5台机器的，一台抗1000个请求，负载大公司会直接用硬件，比如F5，互联网用nginx的比较多；
2.第一个说的是增加web服务器，第二个是数据库分库，增加数据库的数量和实例，比如根据uuid进不同的数据库，这样数据库压力也可以下来了。
3.第三个就是你说的队列，但是队列异步一般是异步的，就是先落地基本信息，就返回成功；然后排队去处理，处理完成后提醒用户，会有个延迟的动作。等等，还的具体问题具体分析，我们以前做过个春晚抢红的，就用了这个套路，web服务器负载均衡，数据库分库，有个入库的规则，入到20个库中；然后根据队列再慢慢处理。

Answer 12

对于高并发，并不纯粹是个技术问题，它更多是个业务问题。
不过想想，对于高并发概念挺简单的，但是处理确是极其复杂的一个问题。
首先高并发在不同业务下面的处理方式不同，第一步先从时机业务逻辑来解决高并发。
其次不同高并发的量和业务场景，处理高并发的方案完全不同，例如1W并发量和10W并发量，技术体系完全不同，而且并不互相兼容，例如能够处理1W并发量的架构体系可能处理不了10W并发量的问题，反之，10W并发量的技术体系，可能对于1W并发量体系处理肯定远远没有针对1W并发量架构好。另外对于并发量的不同业务的处理也前千差万别，说过简单的，同样1W并发量处理，读取新闻网页的1W并发量，根本不用做多少处理，直接一台机器做个页面静态化就完成了。如果是1W表单提交并发量处理，那么你可能要做服务器负载均衡，并且做内存服务器处理用户表单缓存来减轻数据库压力，也可能要做一个数据库集群。如果你要处理1W订单下单并发处理，那么你可能要在之前逻辑上再加上消息机制来限流，等等。对于不同业务复杂度的并发处理也是不同的。