在约定时间内安全可靠地重试
为什么需要异常重试
因为网络会存在抖动情况，造成请求失败，这个时候就需要重新发起，但是在catch捕获异常中处理，不太优雅，所以考虑再RPC框架层面去做这件事情
RPC框架重试机制
即当调用端失败的时候，RPC框架可以自行进行重试，用户可以设置是否重试及重试次数。
调用端在发起 RPC 调用时，会经过负载均衡，选择一个节点，之后它会向这个节点发送请求信息。当消息发送失败或收到异常消息时，我们就可以捕获异常，根据异常触发重试，重新通过负载均衡选择一个节点发送请求消息，并且记录请求的重试次数，当重试次数达到用户配置的重试次数的时候，就返回给调用端动态代理一个失败异常，否则就一直重试下去。
- 业务幂等
并不是对待所有的异常都会进行重试，需要区分业务异常还是非业务异常（例如网络异常）
可以重试的前提是 服务方提供的服务是幂等的。 - 重置超时时间
连续的异常重试并且每次处理的请求时间比较长，最终会导致请求处理的时间过长，超出用户设置的超时时间。
解决这个问题最直接的方式就是，在每次重试后都重置一下请求的超时时间。 - 摘除有问题的节点
发起重试、负载均衡选择节点的时候，去掉重试之前出现过问题的那个节点，以保证重试的成功率，避免重新打到原先的机器上 - 可重试的异常白名单
RPC 框架是不会知道哪些业务异常能够去进行异常重试的，我们可以加个重试异常的白名 单，用户可以将允许重试的异常加入到这个白名单中
异常重试就是为了尽最大可能保证接口可用率的一种手段，但这种策略只能用在幂等接口上，否则就会因为重试导致应用系统数据“写花”。