关于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
架构级的冥等性的好处是对程序员的依赖性降低了，对架构师的能力有依赖，但一般来说，架构师能力总是强于程序员的，所以架构师更靠谱些吧。