好几百人同时请求一个API接口，如何处理并发呢？？？

[养 家 糊 口]

系统流程图就是上图，有什么好的方案吗？

[imarshal]

估计这个api接口在sta

[king12399999]

如何设计高并发接口? - 这个人很吊的技术博客

[qq_44715594]

如何设计高并发接口? - 这个人很吊的技术博客

[Cliven_]

看看服务器资源占用率，不高的话，可以选择用docker做个镜像 多启动几个实例水平扩展，然后用nginx负载均衡一下。如果占用特别高，那么硬件瓶颈了……

[Pigeon汪]

业务处理模块也需要使用多线程异步模式，尽可能地增加并发性能。

[望向缸外的大眼睛]

几百人人数不多, 写个代码判断相同或相似请求,进行归类,同一类型的问题xml解析一次即可. 再把解析结果放置到redis缓存中,高频部分存储入后台数据库.下次直接调用redis缓存或 数据库结果,不再解析.从而减小xml解析拥堵问题.

[maradona1984]

引用 18 楼 养 家 糊 口 的回复:

[quote=引用 7 楼 胖叔叔写代码 的回复:]
[quote=引用 楼主 养 家 糊 口 的回复:]



系统流程图就是上图，有什么好的方案吗？

看你的图看不出来压力在哪里，你如果做一个简单的回声程序：

        public string EchoTest(string name)
        {
            //throw new Exception("asdas");
            return $"hello {name}";
        }

会阻塞吗？肯定不会，那么就是你业务处理这里有问题没有安排好，这里的问题你又没给出代码，就没法诊断了。[/quote]

前端ajax请求API接口，API接口中有解析xml的操作，有些xml较大，解析较慢，这个时候会不会出现阻塞，因为后台代码中没看到任何多线程或者异步[/quote]
虽然不懂C#,但作为一个web服务器,线程池这些东西对开发应该是透明的,你是看不到的

[非专业开发Five]

引用 18 楼 养 家 糊 口 的回复:

前端ajax请求API接口，API接口中有解析xml的操作，有些xml较大，解析较慢，这个时候会不会出现阻塞，因为后台代码中没看到任何多线程或者异步

那就加上异步就行了，阻塞这种事情难免的，后台controller做成异步的，然后就……io阻塞别人也没法解决，当然你可以考虑做个memcache的缓存什么的，提前读取文件之类的，但是你的业务逻辑谁也不知道，你先把xml的读取写成异步，然后把controller写成异步看看效果吧。

[還是]

增加一个缓冲队列。

[正怒月神]

你能详细的通过测试来确定，是 xml解析比较慢吗？ 如果是由于xml比较大导致的数据转换比较慢。那么可以从需求上来解决吗？ 以前我遇到过提交人家api将近10W的xml数据量。的确是比较慢。 xml比Json大太多了，解析速度我没测试过。 但是后来换了json，就好多了。

[正怒月神]

我个人感觉，controller异步，无法带来太多的提升 因为看起来楼主的其他处理逻辑都相对简单，只有这个反序列化过程，可能比较耗时

[airen821010]

好，受教了，感谢楼主的分享！

[银龙软件]

用json试试。

[兔子家族-二哥]

几百的并发量 你连Nginx都弄出来了 还得了啊？这就要做负载均衡了，我的天！做负载均衡你还要几台服务器？
真的不至于，LS有说你直接返回xml试试，不解析成Json，就拿到xml到本地去解析，可以看看是不是这里的问题。
我更愿意相信是你某些地方代码写的有问题，或者用了某些东西第三方的东西，比如格式转换这些东西 消耗大量的服务器承载。

又或者sql啊之类的，我真心不认为几百的并发有那么吓人。。。。除非一个接口真的就没用解耦的那种，一个接口通一个系统那样的不现实

[吹风的兔子]

我之前做过测试： i3 1代 CPU 6G内存 最简单的 发送 Hello Word， 响应 Hello Word Socket 通讯是 5000次/秒 WCF 通讯是 4000次/秒 WebService （正式部署到 IIS） 通讯是 3000次/秒 WebService （用 VS自带的Web服务） 通讯是 500次/秒 这种返回 JSON 的 webapi 理论上是比 WebService 快的。 -------------------------------------------- 查错步骤： > 先增加一个 HelloWord 的 api > 测试一下 这个 HelloWord 的 吞吐量 > 如果 HelloWord 很快 —— 但是 其他 api 很慢，那就是你 其他 api 的实现逻辑 浪费了性能。

[吹风的兔子]

> 如果 HelloWord 也很慢，说明是 你们框架底层 有问题，没写好。

[以专业开发人员为伍]

[quote=引用 17 楼 养 家 糊 口 的回复: 前端ajax请求API接口，API接口中有解析xml的操作，有些xml较大，解析较慢，这个时候会不会出现阻塞，因为后台代码中没看到任何多线程或者异步[/quote] 仅凭你说的这个设计描述，无法判断会不会出现阻塞。web服务端处理 http 请求消息天然是并发的，阻塞不阻塞，实际上要看具体代码设计思路。

[以专业开发人员为伍]

引用 17 楼 养 家 糊 口 的回复:

前端ajax请求API接口，API接口中有解析xml的操作，有些xml较大，解析较慢，这个时候会不会出现阻塞，因为后台代码中没看到任何多线程或者异步

仅凭你说的这个设计描述，无法判断会不会出现阻塞。web服务端处理 http 请求消息天然是并发的，阻塞不阻塞，实际上要看具体代码设计思路。 例如说如果你说你大量访问了关系数据库，使用了事务，有访问共享的（查询条件结果重合的）数据记录，那么就可能阻塞。关系数据库事务本身就是性能杀手。 但是你并没有很具体地来说程序设计，你只是说“xml解析”这类概念，这其实就是服务器端处理客户端请求经常做的事情（现在更多地用 json 而不是 xml）。

[CalvinR]

mark

[kuyz]

做队列可以试试