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

Sat, 24 Apr 2021 12:23:10 +0000

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

源码语言：Java

源码出品：Alibaba

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

源码分析：

---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模块中；

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

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。其处理逻辑是：

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

源码借鉴：

概念定义清楚，从领域建模的角度，区分开来各种概念的含义，面向对象，对象定义清楚，准确定义。
对于各个Bean的AutoConfiguration，集中进行管理，且当用户无自定义时候，需要提供默认的注入实现；—这是开发框架和非框架的本质区别；
按模块做成各个模块之间的独立，模块的边界定义清晰；

Retry | Liao Lile

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