批评一下

前几天和一个读者聊天，聊到了 Dubbo 。

他说他之前遇到了一个 Dubbo 的坑。

我问发生甚么事儿了？

然后他给我描述了一下前因后果，总结起来就八个字吧：超时之后，自动重试。

对此我就表达了两个观点。

• 读者对于使用框架的不熟悉，不知道 Dubbo 还有自动重试这回事。
• 是关于 Dubbo 这个自动重试功能，我觉得出发点很好，但是设计的不好。

第一个没啥说的，学艺不精，继续深造。

主要说说第二个。

有一说一，作为一个使用 Dubbo 多年的用户，根据我的使用经验我觉得 Dubbo 提供重试功能的想法是很好的，但是它错就错在不应该进行自动重试。

大部分情况下，我都会手动设置为 retries=0。

作为一个框架，当然可以要求使用者在充分了解相关特性的情况下再去使用，其中就包含需要了解它的自动重试的功能。

但是，是否需要进行重试，应该是由使用者自行决定的，框架或者工具类，不应该主动帮使用者去做这件事。

等等，这句话说的有点太绝对了。我改一下。

是否需要进行重试，应该是由使用者经过场景分析后自行决定的，框架或者工具类，不应该介入到业务层面，帮使用者去做这件事。

本文就拿出两个大家比较熟悉的例子，来进行一个简单的对比。

第一个例子就是 Dubbo 默认的集群容错策略 Failover Cluster，即失败自动切换。

第二个例子就是 apache 的 HttpClient。

一个是框架，一个是工具类，它们都支持重试，且都是默认开启了重试的。

但是从我的使用感受说来，Dubbo 的自动重试介入到了业务中，对于使用者是有感知的。HttpClient 的自动重试是网络层面的，对于使用者是无感知的。

但是，必须要再次强调的一点是：

Dubbo 在官网上声明的清清楚楚的，默认自动重试，通常用于读操作。

如果你使用不当导致数据错误，这事你不能怪官方，只能说这个设计有利有弊。

Dubbo重试几次

都说 Dubbo 会自动重试，那么是重试几次呢？

先直接看个例子，演示一下。

首先看看接口定义：

可以看到在接口实现里面，我睡眠了 5s ，目的是模拟接口超时的情况。

服务端的 xml 文件里面是这样配置的，超时时间设置为了 1000ms：

这就是一个原生态的 Dubbo Demo 项目。由于我们超时时间是 1000ms，即 1s，但接口处理需要 5s，所以调用必定会超时。

那么 Dubbo 默认的集群容错策略(Failover Cluster)，到底会重试几次，跑一下测试用例，一眼就能看出来：

你看这个测试用例的时间，跑了 3 s 226 ms，你先记住这个时间，我等下再说。

我们先关注重试次数。

有点看不太清楚，我把关键日志单独拿出来给大家看看：

从日志可以出，客户端重试了 3 次。最后一次重试的开始时间是：2020-12-11 22:41:05.094。

我们看看服务端的输出：

我就调用一次，这里数据库插入三次。凉凉。

而且你关注一下请求时间，每隔 1s 来一个请求。

我这里一直强调时间是为什么呢？

因为这里有一个知识点：1000ms 的超时时间，是一次调用的时间，而不是整个重试请求（三次）的时间。

之前面试的时候，有人问过我这个关于时间的问题。所以我就单独写一下。

然后我们把客户端的 xml 文件改造一下，指定 retries=0：

可以看到，只进行了一次调用。

到这里，我们还是把 Dubbo 当个黑盒在用。测试出来了它的自动重试次数是 3 次，可以通过 retries 参数进行指定。

接下来，我们扒一扒源码。