这是一个创建于 514 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天为一个调整和同事争了好久，大概需求就是服务器同一个资源，要保证同时只能有一个服务在使用，我主张是一个向另一个申请，如果没在使用就立刻返回，如果再使用，就先提示占用，然后使用完了，再回调通知到对方，同事则坚持轮询对方的一个接口（接口返回当前的使用状态），理由是耦合，如果各自回调，2 个程序的耦合性就增加，而且回调也增加了代码复杂度，不易维护，仔细想想他说的确实有道理，但回调的处理真的有这么差么？我是觉得轮询确实有点不太优雅，看看大家的意见
 |
1
FranzKafka95 2023-06-07 23:15:47 +08:00 via Android
效率上讲肯定是异步回调通知更好。
|
 |
2
IvanLi127 2023-06-07 23:21:04 +08:00 via Android
看需求要不要即时性咯。
另外，回调有重试么，没有的话轮询还得安排上 |
 |
3
dobelee 2023-06-07 23:26:12 +08:00
两个结合，轮询兜底。
|
 |
4
lingalonely 2023-06-07 23:31:12 +08:00
看请求量，量大就回调，量小就轮询，轮询可以不定长轮询
|
 |
5
yuanmomo 2023-06-07 23:31:54 +08:00 via iPhone
看时间成本啊，要是时间，人力成本都不允许，还要啥异步通知。
你这个就有点像我之前看过的一个项目，没有用事务性消息。然后通过定时任务来保证数据的最终一致性。卧槽，最后，一般的项目，3w 行代码，然后那个 xxl-job 已经 16w 行代码了。项目太紧了，时间都腾不出来，谁还考虑引入新的技术，而且，当时华为云还不支持呢。 所以，回调肯定更好，但是得考虑实现成本了。 |
 |
6
lightjiao 2023-06-07 23:32:21 +08:00
async await 来解决这种事情很简单
|
 |
7
Huelse 2023-06-07 23:36:35 +08:00
得看你们用的什么框架和技术栈，不同技术栈有不同的优势圈，总之得方便查资料且资料够全。
|
 |
8
raycool 2023-06-07 23:42:01 +08:00
优雅用回调
快速用轮询 |
 |
9
swulling 2023-06-07 23:49:55 +08:00 via iPhone
这个场景显然是抢锁啊，不应该用 callback 。
|
 |
10
ql562482472 2023-06-07 23:50:11 +08:00
回调需要自身保存状态，轮询不需要保存状态，所以轮询在设计理论上会比回调的设计更简单 简单就意味着健壮和优雅咯
回调听起来很好很高大上 但是设计一下就知道里面费劲的地方太多了 可靠性还很难上去 |
 |
11
wangritian 2023-06-07 23:50:38 +08:00  1
我的建议是所有服务连接同一个 redis ，同一资源使用相同 key ，做分布式锁
|
 |
12
yinmin 2023-06-07 23:57:25 +08:00
轮询：写代码容易、易部署、效率低、不支持大流量。
回调：客户端要搭一个服务器架构，部署麻烦、效率高、支持大流量。 换一个思路：大厂的做法是用消息队列(类似 rabbitmq)。把服务器的干活需求放到队列里，服务器读队列干活。稳定、可扩展。 |
 |
13
hxndg 2023-06-07 23:58:44 +08:00
我感觉你说的需求和回调或者轮训没直接关系，问题是抢锁，你们关注的是怎么触发。
这种应该是任务提交，服务端控制并发一个，任务结束了通知到前面继续吧。 |
 |
14
hhjswf 2023-06-08 00:08:06 +08:00 via Android
回调好。但是你这方案不行。你通知对方后对方申请又被占用了，有可能导致饥饿。
为什么不弄个队列排队使用资源，使用完了回调通知结果 |
 |
15
pC0oc4EbCSsJUy4W 2023-06-08 00:14:26 +08:00
消息队列 MQ
|
 |
16
jorneyr 2023-06-08 08:11:25 +08:00
能用消息队列的就别轮询，代码简单很多。
|
 |
17
opengps 2023-06-08 08:23:53 +08:00
各有各的好处：
轮训里藏着部分同步逻辑。 异步不影响节奏，不回因为单轮执行周期长明显影响到下一个周期 |
 |
18
justRua 2023-06-08 09:47:31 +08:00
类分布式锁的一个场景，回调轮询都可以，如果实时性要求和请求量都不大轮询也没毛病。回调可以参考 zookeeper 的 watcher 机制
|
 |
20
Vegetable 2023-06-08 10:03:37 +08:00
可惜，实际上轮询和回调并不冲突，你设计了回调也不可能因为对方不通知你就一直傻等，还是要轮询，因为要考虑回调功能本身不可靠的情况，最后就是回调和轮询都要做。
|
 |
21
bzzhou 2023-06-08 10:38:42 +08:00
基本来说，轮训是必须做的，哪怕有回调也得有轮询作为兜底方案；而且在性能不是瓶颈的情况下，轮训最简单可靠的方案。
先基于这个实现了，有问题再上回调都问题不大。 |
 |
22
RoccoShi 2023-06-08 11:02:12 +08:00
all in MQ
|
 |
23
auh 2023-06-08 11:24:10 +08:00
优雅能当饭吃吗？低级。
|
 |
24
liuhailiang 2023-06-08 14:03:14 +08:00
满足业务要求即可，业务没要求？那就怎么简单怎么做。。
|
Select Language