订单业务处理太过耗时如何优化？

[cai88112]

单台服务器

对接的硬件设备，它们处理数据很快，超过 300ms 就认为超时、重试。
我的订单接口要插入数据到 6 张表中，大概 1-3s，所以经常出现大量重复请求。

想到一个不成熟方案，先把请求缓存 redis 中，先返回结果，再异步处理数据。
但是如果 redis 丢失或者 redis 缓存失败，数据就彻底丢失了，不知道如何补救。

求教好的方案

[zardly666]

消息中间件就是做这个的呀 rabbitmq

[hand515]

如果单纯是插入 6 张表要 1~3s，我觉得应该从性能上入手，查找问题

[cai88112]

@zardly666 单机用不太好吧，挂了的话，系统就彻底崩了吧

[swulling]

redis 做高可用就行了，不丢不就完了。

简单点就主从同步，加一个监控避免从落后太对就够了。

[AngryPanda]

同意二楼，你这写入速度也忒慢了

[crclz]

消息中间件没毛病哦

[skymei]

感觉可以考虑先优化现有的 sql,然后尝试改为异步

[sadfQED2]

才 6 张表就要 1 到 3 秒？？你应该先研究下为啥这么慢

[allanzhuo]

1 到 3 秒应该有可以优化的地方

[cai88112]

@skymei
@AngryPanda
@hand515 感谢，我再测试测试，sql 的问题

[cai88112]

@sadfQED2 中间还有业务处理，可能是业务处理耗时

[thinkmore]

可能人家楼主只能有一台服务器，上中间件不合适。还是想想优化业务逻辑

[heyjei]

先别急着 redis 和消息中间件，

先按二楼的意见，看下为啥 6 张表而已，却要 1-3 秒？

[cai88112]

@heyjei 嗯 谢谢，不着急，方案成熟了再搞
我再看看，有没有优化空间

[leaderhyh]

首先考虑最简单的通过提升硬件来 tps
其次考虑优化业务逻辑, SQL 等, 可以通过压测找出性能瓶颈 是代码还是 SQL, 亦或是有其他的第三方请求
最最最后才考虑改成异步, 因为异步返回的是处理中的中间态, 你可能还需要提供一个查询业务处理状态的接口
如果确定改异步, 可以考虑在简单的验证后将请求体直接落库, job 异步处理即可

[JsonTu]

先记录下哪里耗时严重，如果是代码逻辑，看能不能优化，如果单插入 sql 耗时用消息中间件吧

[qq976739120]

1-3 秒.....你插入的是 excel 不是 mysql 吧....

[guanhui07]

太慢了 1-3 秒 排除逻辑 只插入到 Mysql 要这么久

[ty89]

好奇，如何实现插入需要 1~3 秒的，一般人写不出来这么慢的 sql

[Alex5467]

订单的有些数据与本次请求无关的只是记录数据的插入操作完全可以做成异步的，还得排查一下是哪里慢了，整个看是看不出来的。

[zhuweiyou]

异步处理就行了，性能问题加机器。

[isnullstring]

是不是说漏，插表不会这么慢，连带业务处理时间了？

[cai88112]

@isnullstring 是的 插入挺快的

[securityCoding]

没啥并发的情况下写操作一般不会有多少耗时 , 重点看看读的索引吧

[securityCoding]

从根本上解决问题的思路是异步化 , 就是楼上说的各种中间件

[tingfang]

太慢了，先看看 SQL 有没有问题吧，redis 、RabbitMQ 异步这些可以先不考虑。

[axbx]

先检查一下是哪个地方处理最耗时，能优化就优化，实在不行再上消息中间件。

[cfcheng503]

弄个中间表不行吗

[Kili9]

先从业务逻辑和 sql 上找问题. 优化业务逻辑, 哪些该异步的就改成异步处理. 最直接的方法就是加服务器,集群,中间件

[seakingii]

先不要写入业务表，搞一套中间表机制，先保证数据能写入，处理逻辑放在后面。

[jimrok]

先落临时表，再异步处理，最后推送确认订单