开源地址 : https://github.com/byteblogs168/x-retry
X-RETRY 基于服务治理的思想我们开发了重试治理的功能，支持动态配置，接入方式基本无需入侵业务代码，并使用多种策略结合的方式在链路层面控制重试放大效应，兼顾易用性、灵活性、安全性的分布式异常重试服务平台
https://www.byteblogs.com/chat
使用过程中有任何问题，或者对项目有什么想法或者建议，可以加入社群，跟群友一起交流讨论
添加注解开启X-RETRY功能
为需要重试的方法添加重试注解
属性
类型
必须指定
默认值
描述
scene
String
是
无
场景
include
Throwable
否
无
包含的异常
exclude
Throwable
否
无
排除的异常
retryStrategy
RetryType
是
LOCAL_REMOTE
重试策略
retryMethod
RetryMethod
是
RetryAnnotationMethod
重试处理入口
bizId
BizIdGenerate
是
SimpleBizIdGenerate
自定义业务id，默认为hash(param),传入成员列表，全部拼接取hash
bizNo
String
否
无
bizNo spel表达式
localTimes
int
是
3
本地重试次数 次数必须大于等于1
localInterval
int
是
2
本地重试间隔时间(s)
数据库脚本位置
##项目部署
如果你已经正确按照系统了，那么你可以输入
会出现登陆页面:
输入用户名: admin, 密码: 123456
仪表盘直观展示系统的任务量、调度量、在线节点展示等
统计当前系统总的任务量
已经调度成功的异常数据
处于调度中的异常数据
调度次数超过配置的最大执行次数的异常数据
展示系统触发调度的总数量
包括调度客户端执行失败、调度超时等异常执行的数据
调用客户端执行重试成功的数据
实时展示当前活跃的客户端与服务端
通过新建按钮配置点开配置组、场景、通知界面
每个系统对应一个组，服务端通过一致性hash环来分配当前已启用的Group在集群中哪节点上消费
场景负责管理收集重试现场的数据，比如 方法名、参数、类等信息; 对照代码 中可以理解为需要重试的方法; 每个业务服务对应N个场景值，即系统配置的最小单位。
及时告知系统管理人员，系统运行状态，如出现大量重试的数据、或者大量重试失败的数据
查询当前处理重试中的数据，存在三种状态
支持的搜索条件:
支持的搜索条件:
支持的搜索条件:
死信队列数据迁移至重试任务重，并删除死信队列数据
搜索系统用户信息 支持的搜索条件:
为系统新增用户
客户端核心能力
服务端核心能力
单机重试管控
单机多注解嵌套方法,通过标记重试现场入口，发生异常重试只重试现场入口，防止每个方法都重试, 从而避免了重试风暴
链路重试管控
重试流速管控
通过路由策略和限流措施对每个组的集群进行流量控制
- 标记重试流量
DDL 是“ Deadline Request 调用链超时”的简称，我们知道 TCP/IP 协议中的 TTL 用于判断数据包在网络中的时间是否太长而应被丢弃，DDL 与之类似， 它是一种全链路式的调用超时，可以用来判断当前的 RPC 请求是否还需要继续下去。如下图，在 RPC 请求调用链中会带上超时时间， 并且每经过一层就减去该层处理的时间，如果剩下的时间已经小于等于 0 ，则可以不需要再请求下游，直接返回失败即可。
如果每层都配置重试可能导致调用量指数级扩大，这样对底层服务来说压力是非常之大的, 通过对流量的标记 ，用户可以判断是否是重试的流量来判断是否继续处理，我们使用 Google SRE 中提出的内部使用特殊错误码的方式来实现：
这种方式理想情况下只有最下一层发生重试，它的上游收到错误码后都不会重试，但是这种策略依赖于业务方传递错误码， 对业务代码有一定入侵，而且通常业务方的代码差异很大， 调用 RPC 的方式和场景也各不相同，需要业务方配合进行大量改造， 很可能因为漏改等原因导致没有把从下游拿到的错误码传递给上游。
如果对你有帮助的别忘记start哦~!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
