问题描述
webservies怎样解决10000个用户频繁请求服务问题？ 问题补充：283433775 写道
解决方案
我换种说法：1. 首先，你的webservice难道要处理很多数据，很慢吗，一般如果很快的话也就毫秒级的事情，一般的网络超时大概在默认20秒这样。2. 其次，对于在满足了webservice很快的前提下，你先达到10000个并发数，那你应用同时访问的数量达到百万级，会有这么大吗，至少我们公司现在的云，百万级的用户，最多也就是千级的并发数。3. 如果你的webservice访问接口里面耗费大量时间的话，你需要程序优化，加入一些模式，或者处理，让用户共享数据，多用户并发，你不能把时间耗费在处理逻辑上，最好只是传递数据上。4. 如果你的应用能达到万级的并发，那么你完全可以假设集群或者云服务，使用多路并发机制，使用多服务器负载均衡来做。
解决方案二：
大家都描述的很正确：首先在架构时应该分析到多少用户，并发请求连接有多少，这个问题归结与你web服务器以及硬件和网络的规划，数量大的话怎么集群，怎么做冗余，热备等。如果你的问题出在web服务这块，C10K的问题的话，从这个角度去分析解决问题。其次，他们都说和webService没有关系，这个是不对的，有关系而且有很大关系。这个问题从你软件层去考虑，分析你做服务端响应以个处理的所耗费的时间，和耗费的资源大小。耗费资源就掠过不说了，就是网络带宽，内存，CPU要跟上，关键还是软件处理方式。在你分析处理时间的时候，如果一个用户一次请求很快，1秒或者小到毫秒，做业务的时候你完全可以同步把业务数据返回。如果时间很长10秒甚至更长，那么你设想当10000并发时是什么情况。这种情况下你的软件业务逻辑就应该设计成异步返回给客户端了。用户请求来的时候没有返回业务数据，而是返回交行数据，告诉客户端请求成功了。至于业务数据，是你的任务在本地完成后push给他（客户端）还是它再次request，可以根据业务分析设计交互流程。很多webService都有多一些慢I/O的任务都留有查询接口，或者取回执行结果这样的设计。大体情况就是这样了，移动10086积分商城都是采用的这种慢I/O的操作。如果你现在系统运行上线，没法改了，那只能加强硬件，增大带宽，加内存，提高CPU，多服务器集群来加快响应速度，祝你好运！
解决方案三：
并不同意楼上的见解。webservice在访问时有个特点，每一个请求都会开启一个新的线程处理，所有10000个并发请求压力还是特别大得。首先从物理上来解决，增加服务器，通过5台服务器连成集群，使用负载均衡，使每台机子分担平均压力。从程序角度来说，你需要使用线程池来管理访问请求线程，只要比较好的管理，然后才能及时释放资源。使用一些比如原型模式等来优化你的程序，也许你的程序中有一句 A a = new A();10000个并发请求要生产10000个A对象，这是在是太浪费了。再者，可以考虑运用超时机制和积极拒绝机制，通过超时机制，可以分散压力，但是会延长处理时间。超时机制，可以在达到一个压力顶峰值时，积极反馈给客户端当前已经超过连接最大数，这个应该在很多地方都见到过。
解决方案四：
并发10000，这个就和webservice没有关系了webservice只是一种基于http的传输协议10000个请求或100个请求，webservice的使用都是一样的