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

2020 年 6 月 23 日
 mixtbkig
单台服务器

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

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

求教好的方案
5754 次点击
所在节点    Java
31 条回复
zhuweiyou
2020 年 6 月 23 日
异步处理就行了，性能问题加机器。
isnullstring
2020 年 6 月 23 日
是不是说漏，插表不会这么慢，连带业务处理时间了？
mixtbkig
2020 年 6 月 23 日
@isnullstring 是的 插入挺快的
securityCoding
2020 年 6 月 23 日
没啥并发的情况下写操作一般不会有多少耗时 , 重点看看读的索引吧
securityCoding
2020 年 6 月 23 日
从根本上解决问题的思路是异步化 , 就是楼上说的各种中间件
tingfang
2020 年 6 月 23 日
太慢了，先看看 SQL 有没有问题吧，redis 、RabbitMQ 异步这些可以先不考虑。
axbx
2020 年 6 月 23 日
先检查一下是哪个地方处理最耗时，能优化就优化，实在不行再上消息中间件。
cfcheng503
2020 年 6 月 23 日
弄个中间表不行吗
imwing
2020 年 6 月 23 日
先从业务逻辑和 sql 上找问题. 优化业务逻辑, 哪些该异步的就改成异步处理. 最直接的方法就是加服务器,集群,中间件
seakingii
2020 年 6 月 23 日
先不要写入业务表，搞一套中间表机制，先保证数据能写入，处理逻辑放在后面。
jimrok
2020 年 6 月 23 日
先落临时表，再异步处理，最后推送确认订单

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://study.congcong.us/t/683961

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX