V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
cai88112
V2EX  ›  Java

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

  •  1
     
  •   cai88112 · 2020-06-23 08:44:27 +08:00 · 4780 次点击
    这是一个创建于 1374 天前的主题,其中的信息可能已经有所发展或是发生改变。
    单台服务器

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

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

    求教好的方案
    zardly666
        1
    zardly666  
       2020-06-23 08:48:45 +08:00
    消息中间件就是做这个的呀 rabbitmq
    hand515
        2
    hand515  
       2020-06-23 08:54:08 +08:00
    如果单纯是插入 6 张表要 1~3s,我觉得应该从性能上入手,查找问题
    cai88112
        3
    cai88112  
    OP
       2020-06-23 08:54:22 +08:00
    @zardly666 单机用不太好吧,挂了的话,系统就彻底崩了吧
    swulling
        4
    swulling  
       2020-06-23 08:54:24 +08:00 via iPhone
    redis 做高可用就行了,不丢不就完了。

    简单点就主从同步,加一个监控避免从落后太对就够了。
    AngryPanda
        5
    AngryPanda  
       2020-06-23 08:56:17 +08:00 via Android
    同意二楼,你这写入速度也忒慢了
    crclz
        6
    crclz  
       2020-06-23 08:57:07 +08:00
    消息中间件没毛病哦
    skymei
        7
    skymei  
       2020-06-23 09:02:06 +08:00
    感觉可以考虑先优化现有的 sql,然后尝试改为异步
    sadfQED2
        8
    sadfQED2  
       2020-06-23 09:02:41 +08:00 via Android
    才 6 张表就要 1 到 3 秒??你应该先研究下为啥这么慢
    allanzhuo
        9
    allanzhuo  
       2020-06-23 09:03:44 +08:00 via Android
    1 到 3 秒应该有可以优化的地方
    cai88112
        10
    cai88112  
    OP
       2020-06-23 09:04:13 +08:00
    @skymei
    @AngryPanda
    @hand515 感谢,我再测试测试,sql 的问题
    cai88112
        11
    cai88112  
    OP
       2020-06-23 09:05:08 +08:00
    @sadfQED2 中间还有业务处理,可能是业务处理耗时
    thinkmore
        12
    thinkmore  
       2020-06-23 09:06:40 +08:00
    可能人家楼主只能有一台服务器,上中间件不合适。还是想想优化业务逻辑
    heyjei
        13
    heyjei  
       2020-06-23 09:12:46 +08:00
    先别急着 redis 和消息中间件,

    先按二楼的意见,看下为啥 6 张表而已,却要 1-3 秒?
    cai88112
        14
    cai88112  
    OP
       2020-06-23 09:16:48 +08:00
    @heyjei 嗯 谢谢,不着急,方案成熟了再搞
    我再看看,有没有优化空间
    leaderhyh
        15
    leaderhyh  
       2020-06-23 09:23:50 +08:00   ❤️ 1
    首先考虑最简单的通过提升硬件来 tps
    其次考虑优化业务逻辑, SQL 等, 可以通过压测找出性能瓶颈 是代码还是 SQL, 亦或是有其他的第三方请求
    最最最后才考虑改成异步, 因为异步返回的是处理中的中间态, 你可能还需要提供一个查询业务处理状态的接口
    如果确定改异步, 可以考虑在简单的验证后将请求体直接落库, job 异步处理即可
    JsonTu
        16
    JsonTu  
       2020-06-23 09:28:33 +08:00 via iPhone
    先记录下哪里耗时严重,如果是代码逻辑,看能不能优化,如果单插入 sql 耗时用消息中间件吧
    qq976739120
        17
    qq976739120  
       2020-06-23 10:00:21 +08:00   ❤️ 1
    1-3 秒.....你插入的是 excel 不是 mysql 吧....
    guanhui07
        18
    guanhui07  
       2020-06-23 10:22:07 +08:00
    太慢了 1-3 秒 排除逻辑 只插入到 Mysql 要这么久
    ty89
        19
    ty89  
       2020-06-23 10:24:01 +08:00
    好奇,如何实现插入需要 1~3 秒的,一般人写不出来这么慢的 sql
    Alex5467
        20
    Alex5467  
       2020-06-23 10:35:52 +08:00
    订单的有些数据与本次请求无关的只是记录数据的插入操作完全可以做成异步的,还得排查一下是哪里慢了,整个看是看不出来的。
    zhuweiyou
        21
    zhuweiyou  
       2020-06-23 10:59:17 +08:00
    异步处理就行了,性能问题加机器。
    isnullstring
        22
    isnullstring  
       2020-06-23 11:44:28 +08:00
    是不是说漏,插表不会这么慢,连带业务处理时间了?
    cai88112
        23
    cai88112  
    OP
       2020-06-23 12:14:09 +08:00
    @isnullstring 是的 插入挺快的
    securityCoding
        24
    securityCoding  
       2020-06-23 14:21:29 +08:00
    没啥并发的情况下写操作一般不会有多少耗时 , 重点看看读的索引吧
    securityCoding
        25
    securityCoding  
       2020-06-23 14:22:09 +08:00
    从根本上解决问题的思路是异步化 , 就是楼上说的各种中间件
    tingfang
        26
    tingfang  
       2020-06-23 14:31:02 +08:00
    太慢了,先看看 SQL 有没有问题吧,redis 、RabbitMQ 异步这些可以先不考虑。
    axbx
        27
    axbx  
       2020-06-23 15:48:49 +08:00
    先检查一下是哪个地方处理最耗时,能优化就优化,实在不行再上消息中间件。
    cfcheng503
        28
    cfcheng503  
       2020-06-23 17:15:26 +08:00
    弄个中间表不行吗
    Kili9
        29
    Kili9  
       2020-06-23 18:27:42 +08:00
    先从业务逻辑和 sql 上找问题. 优化业务逻辑, 哪些该异步的就改成异步处理. 最直接的方法就是加服务器,集群,中间件
    seakingii
        30
    seakingii  
       2020-06-23 20:35:03 +08:00
    先不要写入业务表,搞一套中间表机制,先保证数据能写入,处理逻辑放在后面。
    jimrok
        31
    jimrok  
       2020-06-23 20:37:14 +08:00
    先落临时表,再异步处理,最后推送确认订单
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1411 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 17:34 · PVG 01:34 · LAX 10:34 · JFK 13:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.