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

[chen0520]

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

[FranzKafka95]

效率上讲肯定是异步回调通知更好。

[IvanLi127]

看需求要不要即时性咯。
另外，回调有重试么，没有的话轮询还得安排上

[dobelee]

两个结合，轮询兜底。

[lingalonely]

看请求量，量大就回调，量小就轮询，轮询可以不定长轮询

[yuanmomo]

看时间成本啊，要是时间，人力成本都不允许，还要啥异步通知。

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

所以，回调肯定更好，但是得考虑实现成本了。

[lightjiao]

async await 来解决这种事情很简单

[Huelse]

得看你们用的什么框架和技术栈，不同技术栈有不同的优势圈，总之得方便查资料且资料够全。

[raycool]

优雅用回调
快速用轮询

[swulling]

这个场景显然是抢锁啊，不应该用 callback 。

[ql562482472]

回调需要自身保存状态，轮询不需要保存状态，所以轮询在设计理论上会比回调的设计更简单 简单就意味着健壮和优雅咯


回调听起来很好很高大上 但是设计一下就知道里面费劲的地方太多了 可靠性还很难上去

[wangritian]

我的建议是所有服务连接同一个 redis ，同一资源使用相同 key ，做分布式锁

[yinmin]

轮询：写代码容易、易部署、效率低、不支持大流量。
回调：客户端要搭一个服务器架构，部署麻烦、效率高、支持大流量。

换一个思路：大厂的做法是用消息队列(类似 rabbitmq)。把服务器的干活需求放到队列里，服务器读队列干活。稳定、可扩展。

[hxndg]

我感觉你说的需求和回调或者轮训没直接关系，问题是抢锁，你们关注的是怎么触发。
这种应该是任务提交，服务端控制并发一个，任务结束了通知到前面继续吧。

[hhjswf]

回调好。但是你这方案不行。你通知对方后对方申请又被占用了，有可能导致饥饿。
为什么不弄个队列排队使用资源，使用完了回调通知结果

[pC0oc4EbCSsJUy4W]

消息队列 MQ

[jorneyr]

能用消息队列的就别轮询，代码简单很多。

[opengps]

各有各的好处：
轮训里藏着部分同步逻辑。
异步不影响节奏，不回因为单轮执行周期长明显影响到下一个周期

[justRua]

类分布式锁的一个场景，回调轮询都可以，如果实时性要求和请求量都不大轮询也没毛病。回调可以参考 zookeeper 的 watcher 机制

[chen0520]

@yinmin 其实现在的程序都是消费队列读取然后占用系统资源执行任务啊，再加一个消费队列协调？感觉怪怪的

[Vegetable]

可惜，实际上轮询和回调并不冲突，你设计了回调也不可能因为对方不通知你就一直傻等，还是要轮询，因为要考虑回调功能本身不可靠的情况，最后就是回调和轮询都要做。