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

实际生产环境中轮询和异步通知到底那个更好点?

  •  
  •   chen0520 · 295 天前 · 2495 次点击
    这是一个创建于 295 天前的主题,其中的信息可能已经有所发展或是发生改变。

    今天为一个调整和同事争了好久,大概需求就是服务器同一个资源,要保证同时只能有一个服务在使用,我主张是一个向另一个申请,如果没在使用就立刻返回,如果再使用,就先提示占用,然后使用完了,再回调通知到对方,同事则坚持轮询对方的一个接口(接口返回当前的使用状态),理由是耦合,如果各自回调,2 个程序的耦合性就增加,而且回调也增加了代码复杂度,不易维护,仔细想想他说的确实有道理,但回调的处理真的有这么差么?我是觉得轮询确实有点不太优雅,看看大家的意见

    24 条回复    2023-06-08 14:03:14 +08:00
    FranzKafka95
        1
    FranzKafka95  
       295 天前 via Android
    效率上讲肯定是异步回调通知更好。
    IvanLi127
        2
    IvanLi127  
       295 天前 via Android
    看需求要不要即时性咯。
    另外,回调有重试么,没有的话轮询还得安排上
    dobelee
        3
    dobelee  
       295 天前
    两个结合,轮询兜底。
    lingalonely
        4
    lingalonely  
       295 天前
    看请求量,量大就回调,量小就轮询,轮询可以不定长轮询
    yuanmomo
        5
    yuanmomo  
       295 天前 via iPhone
    看时间成本啊,要是时间,人力成本都不允许,还要啥异步通知。

    你这个就有点像我之前看过的一个项目,没有用事务性消息。然后通过定时任务来保证数据的最终一致性。卧槽,最后,一般的项目,3w 行代码,然后那个 xxl-job 已经 16w 行代码了。项目太紧了,时间都腾不出来,谁还考虑引入新的技术,而且,当时华为云还不支持呢。

    所以,回调肯定更好,但是得考虑实现成本了。
    lightjiao
        6
    lightjiao  
       295 天前
    async await 来解决这种事情很简单
    Huelse
        7
    Huelse  
       295 天前
    得看你们用的什么框架和技术栈,不同技术栈有不同的优势圈,总之得方便查资料且资料够全。
    raycool
        8
    raycool  
       295 天前
    优雅用回调
    快速用轮询
    swulling
        9
    swulling  
       295 天前 via iPhone
    这个场景显然是抢锁啊,不应该用 callback 。
    ql562482472
        10
    ql562482472  
       295 天前
    回调需要自身保存状态,轮询不需要保存状态,所以轮询在设计理论上会比回调的设计更简单 简单就意味着健壮和优雅咯


    回调听起来很好很高大上 但是设计一下就知道里面费劲的地方太多了 可靠性还很难上去
    wangritian
        11
    wangritian  
       295 天前   ❤️ 1
    我的建议是所有服务连接同一个 redis ,同一资源使用相同 key ,做分布式锁
    yinmin
        12
    yinmin  
       295 天前
    轮询:写代码容易、易部署、效率低、不支持大流量。
    回调:客户端要搭一个服务器架构,部署麻烦、效率高、支持大流量。

    换一个思路:大厂的做法是用消息队列(类似 rabbitmq)。把服务器的干活需求放到队列里,服务器读队列干活。稳定、可扩展。
    hxndg
        13
    hxndg  
       295 天前
    我感觉你说的需求和回调或者轮训没直接关系,问题是抢锁,你们关注的是怎么触发。
    这种应该是任务提交,服务端控制并发一个,任务结束了通知到前面继续吧。
    hhjswf
        14
    hhjswf  
       295 天前 via Android
    回调好。但是你这方案不行。你通知对方后对方申请又被占用了,有可能导致饥饿。
    为什么不弄个队列排队使用资源,使用完了回调通知结果
    fatelight
        15
    fatelight  
       295 天前
    消息队列 MQ
    jorneyr
        16
    jorneyr  
       294 天前
    能用消息队列的就别轮询,代码简单很多。
    opengps
        17
    opengps  
       294 天前
    各有各的好处:
    轮训里藏着部分同步逻辑。
    异步不影响节奏,不回因为单轮执行周期长明显影响到下一个周期
    justRua
        18
    justRua  
       294 天前
    类分布式锁的一个场景,回调轮询都可以,如果实时性要求和请求量都不大轮询也没毛病。回调可以参考 zookeeper 的 watcher 机制
    chen0520
        19
    chen0520  
    OP
       294 天前
    @yinmin 其实现在的程序都是消费队列读取然后占用系统资源执行任务啊,再加一个消费队列协调?感觉怪怪的
    Vegetable
        20
    Vegetable  
       294 天前
    可惜,实际上轮询和回调并不冲突,你设计了回调也不可能因为对方不通知你就一直傻等,还是要轮询,因为要考虑回调功能本身不可靠的情况,最后就是回调和轮询都要做。
    bzzhou
        21
    bzzhou  
       294 天前
    基本来说,轮训是必须做的,哪怕有回调也得有轮询作为兜底方案;而且在性能不是瓶颈的情况下,轮训最简单可靠的方案。
    先基于这个实现了,有问题再上回调都问题不大。
    RoccoShi
        22
    RoccoShi  
       294 天前
    all in MQ
    auh
        23
    auh  
       294 天前
    优雅能当饭吃吗?低级。
    liuhailiang
        24
    liuhailiang  
       294 天前
    满足业务要求即可,业务没要求?那就怎么简单怎么做。。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1547 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 17:13 · PVG 01:13 · LAX 10:13 · JFK 13:13
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.