本文探讨了RPC调用中异常重试的必要性，介绍了RPC框架如何实现重试机制，包括在网络异常时捕获并判断异常以决定是否重试。同时，强调了业务逻辑必须是幂等性的要求，以避免重试导致的问题。此外，讨论了如何在重试过程中确保请求在约定时间内安全可靠地完成，如重置超时时间和避免选择已出现问题的节点。最后，提出了优化方案，如异常白名单，允许用户配置可重试的特定业务异常。
一、为什么需要异常重试？
一次 RPC 调用，去调用远程的一个服务，比如用户的登录操作，会先对用户的用户名以及密码进行验证，验证成功之后会获取用户的基本信息。当通过远程的用户服务来获取用户基本信息的时候，恰好网络出现了问题，比如网络突然抖了一下，导致请求失败了，而这个请求希望它能够尽可能地执行成功，那这时要怎么做呢？
需要重新发起一次 RPC 调用，那代码中该如何处理呢？是在代码逻辑里 catch 一下，失败了就再发起一次调用吗？这样做显然不够优雅吧。这时就可以考虑使用 RPC 框架的重试机制。
二、RPC 框架的重试机制
就是当调用端发起的请求失败时，RPC 框架自身可以进行重试，再重新发送请求，用户可以自行设置是否开启重试以及重试的次数。
那这个机制是如何实现的呢？
调用端在发起 RPC 调用时，会经过负载均衡，选择一个节点，之后它会向这个节点发送请求信息。当消息发送失败或收到异常消息时，我们就可以捕获异常，根据异常触发重试，重新通过负载均衡选择一个节点发送请求消息，并且记录请求的重试次数，当重试次数达到用户配置的重试次数的时候，就返回给调用端动态代理一个失败异常，否则就一直重试下去。
RPC 框架的重试机制就是调用端发现请求失败时捕获异常，之后触发重试，那是不是所有的异常都要触发重试呢？
当然不是了
最低0.47元/天 解锁文章
扫一扫
1053
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
