easy-retry 一种存储介质可扩展的持久化重试方案

源码地址：alibaba/easy-retry: easy-retry (github.com)

源码语言：Java

源码出品：Alibaba

源码关联分析： houbb/sisyphus: The java retry framework.(支持注解的 java 重试框架) (github.com)

源码分析：

1、其目录树结构为：

---easy-retry-common

---easy-retry-core

---easy-retry-extensions

| ---easy-retry-mybatis-extension

| ---easy-retry-spring-extension

---easy-retry-starters

| ---easy-retry-memory-starter

| ---easy-retry-mybatis-starter

| ---easy-retry-starter-common

目前支持两种模式的重试，包括持久化到mysql依赖mybatis和内存数据版本，分别需要以来easy-retry-mybatis-starter和easy-retry-memoery-starter模块。

重试的最基本的interface以及model定义在easy-retry-common中，retry逻辑的具体默认实现在easy-retry-core模块中；

2、该重试的模块中定义的核心概念有：

Retryable支持重试的注解，支持定义是否重新抛出异常，以及SpelExpression来驱动重试判定

RetryInfo 通过@Retryable注解绑定获取执行的executor和executorMethod信息绑定到RetryInfo上；

RetryTask 对于重试任务的定义，重要的领域模型。其在框架中的convert关系：retryInfo->retryTask->retryTaskPo

RetryConfiguration 重试的配置，如果没有自定义的则框架默认的重试机制。支持灵活的自定义内容，包含有：

• 获取重试任务
• 重试信息序列化器获取，默认是 Hessian
• 重试机制的定义
• 重试执行器，执行驱动业务
• 重试最大次数
• 重试事件监听
• 任务结果序列化器，配合SPEL表达式决策是否需要重试，默认是 Hessian

Retryer重试的基本Call定义，@FunctionalInterface 函数式接口声明

RetryContext，重试的上下文内容，上下文内容来自于RetryConfiguration，目前只有一种实现，即MaxAttemptsPersistenceRetryContext；绑定具体的task和task executor method

RetryContainer 重试的容器承载，目前一种实现，即SimpleRetryContainer。其通过一个生产-消费者设计模式，实现了retryTask的生产和消费，用于对retryTask的管理；

RetryContext和RetryContainer目前都托管在RetryLifeCycle中管理，在启动和关闭时候做相关资源的处理；RetryContainer中是一个优先队列装的是RetryContext，RetryContex中承载了RetryTask，而RetryTask的优先级最终反应到RetryContext上。而任务的优先级通过任务重试的背压机制设置，避免失败的任务频繁的重试；

RetryFilter，重试的过滤器，在过滤器中可以针对RetryContext进行相关的拦截统一处理；其中有一个确保线程安全的过滤器；

RetryInterceptor 切面的切入，该切入点做了BeforeRetryProcess和OnRetryProcess切入动作，两个process针对正常场景和异常场景定义了相关处理方法，来决策是否需要进行重试；

RetryProcessor，拦截面切入的动作定义

RetryStrategy，具体的重试策略，包括等待策略以及结束策略

RetryEvent，重试的事件，包括重试前的重试对象获取前后事件，以及重试中的失败、成功、等待事件等；

RetryListener，事件的监听者；

RetryExecutor，重试的执行器，在上下文中依赖于RetryConfiguration和RetryTask关联，确定task的执行器；当前的executor实现了PersistencRetryExecutor。其处理逻辑是：

1. RetryContainer从当前优先队列中获取最优先的任务对应的RetryContext上下文信息，送入executor中执行。
2. executor判断当前任务是否需要立即执行还是继续等待，决定于背压模式下的时间设定。
3. 如果可以执行，则更新当前的retryTask状态为handling
4. 执行器执行对应的filter逻辑，filter逻辑返回对应的信息，filter链中最后一个处理逻辑为冲RetryContext取出Invocation信息并且invoke对应的method。
5. 依据filter chain的返回结果后者会抛出异常，针对这两个结果进行判定，决策当前的执行是否需要重试，如果需要重试再决策是否已经达到最大重试次数或者进入背压逻辑，返回该次的结果；
6. 依据上述的状态结果，进行事件广播，相关的Retrylisterner即会被调用；