关于dubbo服务超时的讨论

时间:2023-03-08 15:35:58
关于dubbo服务超时的讨论

呵呵,偷点懒,直接把QQ上的讨论发下来。


huxin  10:35:19
你们现在超时了是咋办的,首先超时了,回复用户肯定是要的

huxin  10:36:14
超时了用户实际是不知道这业务是成功还失败了
后续你们如何处理

一棵小草  10:37:27
幂等性。根据业务来的
huxin  10:37:31
一种是用户在某个时间主动再来发起这个业务
一种是系统的监听机制发现业务成功主动推过来告知用户
huxin  10:38:43
当用户在某个时间主动再来发起这个业务的时候,服务必须要保证幂等性
huxin  10:39:37
那么你们有具体的幂等性机制吗,还是这个幂等性是要通过查数据库,从业务角度去完成呢
如果是这样,那么幂等性就强依赖业务代码了
huxin  10:40:29
就要强依赖程序员的逻辑了,检查起来就比较累,程序员素质高,幂等性就保证的好,反之就差。你测的时候还得分析他的业务代码,才能判断幂等性是不是保证了
一棵小草  10:42:17
是的

huxin  10:42:35
所以我认为,这个幂等性得从架构上来保证,至于程序愿意在业务层面上再保证那再好不过了

huxin  10:43:38
至于程序员愿意在业务层面上再保证那再好不过了
这样就是双保险

一棵小草  10:43:56
你觉得架构上怎么保证啊

huxin  10:44:18
可以用全局业务编号的机制
你要干一件事,先领一个号,这个号类似于MD5码,你同样的一次业务永远会是这个编号

huxin  10:46:17
这样我不管你的代码管不管业务的幂等性,架构上是把了一道关的
我检查冥等性的代码是所有业务可以共用的
huxin  10:47:41
程序员如果愿意在业务层面上再保证一次冥等性那再好不过了


huxin  10:48:47
以上就是我的服务超时解决方案

huxin  10:53:39
架构级的冥等性的好处是对程序员的依赖性降低了,对架构师的能力有依赖,但一般来说,架构师能力总是强于程序员的,所以架构师更靠谱些吧。