cursor 更适合前端吧

打开任务管理器，我这边不是内存占用的问题，而是 CPU 的问题。

内存加上去，CPU 这一两年的都没啥问题

这个 Code Request 和 restfultool 这个插件很像。我主要是常用全局搜索 API ，所以 restfultool 已经满足我的需求了。接口测试还是习惯使用 postman ，目前确实没有可以替换 postman 的存在。

感谢大家的回复，我目前选择的方式是，用户发起批量支付时，同步将运单的 id 写入新表中，然后返给前端处理中的结果。前端查询时，我会过滤掉已经记录的运单，这样就不会造成用户重复发起。
因为一开始我担心批量修改和插入会比较耗时，我试下了循环调用 insert 插入，确实比较费时，1000 条 40 秒，然后换成 foreach 插入，1000 条 300 毫秒。所以选择同步去记录运单。
后续如果还有其他问题，也会更新，感谢。

@offswitch 我主要是一开始不太确定，应该如何去更改这 1000 笔运单的状态，如果同步修改，可能会耗时比较久，给用户的感受不太好。我刚才换了中批量插入的方式，很快了。
让前端设计下，这个一般前端是不太想参与的，😄。

@perbugwei 我换成 foreach 插入，1000 笔，300 毫秒。那我就同步记录下请求中的运单 id ，查询时过滤掉已经记录的运单，这样就不会再重复发起。

@dong568789 如果是同步更新状态，就不会出现用户会重复提交的问题。如果是异步更新状态，就会出现。

@perbugwei 不是 savebatch ，就是 insertSelective

@iOCZS 我们可以先给前端一个处理中的结果，后续的支付都是异步，前端刷新就可以看到最新结果。

@wuyiccc 我试下了循环插入 1000 条数据，40 秒。我再换下其他插入的方式。我们使用的是 mybatis.

@yc8332 支付是使用异步处理。现在我犹豫不决的是发起支付请求如何去记录运单支付处理中的状态，因为有 1000 笔运单，我要同步去修改，耗时较长，如果把这部分也做成异步处理，用户刷新到运单数据，可能会有上次请求中还未修改状态的运单。

@None2 如果是同步更改运单处理中的状态，我试下了，我是重新建了一张表，有个 id 主键字段，一个运单 id 字段，1000 条数据，我是循环插入，用了 40 秒。

@lsk569937453 因为用户的运单量比较大，且支付时间集中，基本就是月底，大概 6 万以上，如果用户发起一次请求，直到运单全部处理完成之前不允许再支付，这个是不行的。

@yc8332 对，发起后就不需要用户再参与了，等待最后的处理结果就行，失败或者成功都会记录到运单状态中。

@wuyiccc 就是在用户发起这 1000 笔运单支付请求是，我要异步记录 1000 笔运单的处理中状态，还是同步记录，如果是异步记录，直接返回给用户处理中的结果，这样用户查到的可能还有没来及的记录处理中状态的运单。如果同步去记录这 1000 笔运单，需要的时间会长些，会让用户在界面有个等待的时间。

@wolfan 我们现在的方案是，前端发起请求后，后端直接返回类似交易已受理的结果，前端不用再等待后端对这笔请求中 1000 笔运单的一个预处理(修改运单状态及相关表)，因为这个太耗时，所以我们后端接收到这 1000 笔运单后，先记录下 1000 笔运单的 id ，异步去处理，但是在这处理这笔运单时，客户还会继续发起下一次 1000 笔运单的支付请求，这个 1000 笔运单中，肯定会有上次请求还未来得及修改运单状态的运单，这个就会造成重复支付的可能，所以我们首先需要将每次请求中的运单 id 记录下来，存储到 redis 或者数据库，这样在 MQ 发起支付时，判断下每笔运单的状态，如果是处理中，则直接跳过，不再处理。目前我主要犹豫不定的是把这 1000 笔运单的 id 存储到 redis 中还是数据库中。

不能登录的，可以网上搜索下案例，有解决方案，我刚开始也是登不上。