不是速度慢的问题，是怕同时请求的数据太多死掉

@心怀宇宙: cpu不到100%,网卡不打满你怕什么？程序所谓的死掉还是因为扛不住压力速度慢了啊，如果性能衰减还是并发大了啊，归根结底还是资源不足，资源不足除了换架构做优化加硬件没有什么好办法了。

@Daniel Cai: 请问可以将数据先存起来然后一条一条处理吗？

@心怀宇宙: MQ

@心怀宇宙: 如果你不需要实时响应当然可以慢慢做，就你担心的问题你可以找下具体你担心的原因，而不是笼统的怕死掉，怕拖挂就完了，找到原因再看能怎么办，如果能异步处理那最好，后面你怎么掰都行，积压过多我加服务实例，处理过慢看看流程中是不是有地方可以简化或者更改设计。如果消息体太大或者交互过于频繁这个基本可以归纳为设计问题。如果某个点上变慢就需要具体看场景，数据库，程序上出现问题都需要针对性的解决，这个不好简短的说完。如果网络节点上变慢这个。。。。找运维

@zhibudao: 能给个例子吗？

@心怀宇宙: 消息队列 一般应对访问峰值 可先将数据写入消息队列 然后后台逐条处理 你可以百度这方面的资料

@心怀宇宙:比如支付环节，有时候是需要高并发且需要响应结果，这个地方就是用mq的时候，用mq在这里有两个好处，一个是提高服务的吞吐量，另一个mq通过合适的配置可以确保扣费消息不丢掉。你需要的同步响应的确在中间mq夹进来异步后不好做，但可以变相改为接入端在请求完毕后通过轮询的方式查询结果，而另一边mq的消费者可以在处理完成后回写或者通过回调的方式更改结果，这样在应用端看起来好像就是同步返回了。

这个地方你可以找个pc版的支付宝二维码支付看下http请求，在二维码请求完毕后会有连续的http请求，这个请求中就包含了对支付结果的查询

有参考案例吗

@心怀宇宙: www.rabbitmq.com 直接研究下这个网站吧。弄明白队列怎么个逻辑，后期的代码就很容易了。

这个有考虑过，现在还有一个问题是，每条数据都得有返回结果，这样貌似不行吧