What is Sisyphus

sisyphus 綜合了 spring-retry 和 gauva-retrying 的優(yōu)勢(shì)，使用起來(lái)也非常靈活。

為什么選擇這個(gè)名字

我覺(jué)得重試做的事情和西西弗斯很相似。

一遍遍的重復(fù)，可能徒勞無(wú)功，但是樂(lè)此不疲。

人一定要想象西西弗斯的快樂(lè)?！涌?/p>

其他原因

以前看了 java retry 的相關(guān)框架,
雖然覺(jué)得其中有很多不足之處。但是沒(méi)有任何重復(fù)造輪子的沖動(dòng)，覺(jué)得是徒勞無(wú)功的。

當(dāng)然這段時(shí)間也看了 Netty 的接口設(shè)計(jì)，和 Hibernate-Validator 的接口設(shè)計(jì)，覺(jué)得非常的巧妙。

覺(jué)得把這些東西結(jié)合，可以寫(xiě)出一個(gè)還不錯(cuò)的框架，就寫(xiě)了起來(lái)。

至少，sisyphus 是快樂(lè)的。

關(guān)于版本

這次的框架版本采用了比較保守的方式，使用 0.0.X。

原因有兩個(gè)：

（1）我認(rèn)為前期出于實(shí)驗(yàn)階段。代碼并不成熟，自測(cè)也不充分。所以不適合用于生產(chǎn)。

（2）這樣可以快速迭代，而不至于為了追求更好導(dǎo)致版本特性遲遲無(wú)法迭代。

版本特性

我用了 5 個(gè)版本，實(shí)現(xiàn)了主要的特性：

（1）基于 fluent 接口聲明式調(diào)用

（2）基于 annotation 的代理實(shí)現(xiàn)

（3）spring 的整合實(shí)現(xiàn)

（4）自定義注解的實(shí)現(xiàn)

未完成的工作

• 更方便的工具類(lèi)。
• 使用文檔
• 測(cè)試代碼

感受

想法是很容易產(chǎn)生的，但是想把它變成一個(gè)穩(wěn)定的框架需要很長(zhǎng)的時(shí)間錘煉。

為什么選擇 sisyphus

作為開(kāi)發(fā)者，我們一般都會(huì)選擇比較著名的框架。

比如 guava-retrying spring-retry。

或者干脆自己寫(xiě)一個(gè)。

為什么不是 guava-retrying/spring-retry

java retry 這篇文章中我列舉了常見(jiàn)的實(shí)現(xiàn)方式
以及上述的兩種框架，也講述了其中的不足。

guava-retrying 優(yōu)缺點(diǎn)

優(yōu)點(diǎn)

• 使用靈活
• fluent 優(yōu)雅寫(xiě)法
• 提供足夠多的實(shí)現(xiàn)

缺點(diǎn)

沒(méi)有默認(rèn)基于注解的實(shí)現(xiàn)

重試策略設(shè)計(jì)并不友好

spring-retry

優(yōu)點(diǎn)使用簡(jiǎn)單

缺點(diǎn)

• 重試條件單一
• 重試等待策略單一
• 無(wú)法自定義注解

為什么不自己寫(xiě)一個(gè)

個(gè)人感受

我作為一名開(kāi)發(fā)，平時(shí)說(shuō)實(shí)在的，看到重試。

我肯定會(huì)偷懶寫(xiě)一個(gè) for 循環(huán)，重試幾次就結(jié)束了。

因?yàn)闀r(shí)間不允許。

如果你更勤快一點(diǎn)，就可以選擇 spring-retry/guava-retrying。如果你熟悉他們的優(yōu)缺點(diǎn)的話。

如果你渴望創(chuàng)造

sisyphus 所有的實(shí)現(xiàn)都是基于接口的。

你完全可以實(shí)現(xiàn)自己的實(shí)現(xiàn)，所有的東西基本完全可以被替換。

當(dāng)然一些常見(jiàn)的策略實(shí)現(xiàn)，項(xiàng)目的基本框架都有詳盡的注釋?zhuān)?dāng)做參考也可以有一點(diǎn)幫助。

sisyphus 做的更多的事情

netty 的靈感

參考了 netty 的設(shè)計(jì)，保證接口實(shí)現(xiàn)的一致性。

而且 sisyphus 還做了更多，還保證了接口和注解之間的一致性。

使用引導(dǎo)類(lèi)，保證使用時(shí)的便利性，后期拓展的靈活性。

hibernate-validator

hibernate-validator 的作者是我知道為數(shù)不多的對(duì)于 java 注解應(yīng)用很棒的開(kāi)發(fā)者。（雖然所知甚少）

自定義注解就是從這個(gè)框架中學(xué)來(lái)的。

與 spring 為伍

spring 基本與我們的代碼形影不離，所以你可以很簡(jiǎn)單的結(jié)合 spring.

就像你使用 spring-retry 一樣。

快速開(kāi)始

需要

jdk1.7+

maven 3.x+

maven 引入

sisyphus 使用 maven 管理 jar，

<plugin>
    <groupId>com.github.houbb</groupId>
    <artifactId>sisyphus-core</artifactId>
    <version>0.0.6</version>
</plugin>

編碼

作為入門(mén)案例，我們首先介紹些簡(jiǎn)單靈活的聲明式編程

public void helloTest() {
    Retryer.<String>newInstance()
            .callable(new Callable<String>() {
                @Override
                public String call() throws Exception {
                    System.out.println("called...");
                    throw new RuntimeException();
                }
            }).retryCall();
}

代碼簡(jiǎn)介

Retryer.<String>newInstance() 創(chuàng)建引導(dǎo)類(lèi)的實(shí)例，String 是 callable 也就是待重試方法的返回值類(lèi)型。

callable() 指定待重試的方法實(shí)現(xiàn)。

retryCall() 觸發(fā)重試調(diào)用。

日志信息

• called...
• called...
• called...

以及一些異常信息。

等價(jià)配置

上面的配置其實(shí)有很多默認(rèn)值，如下：

/**
 * 默認(rèn)配置測(cè)試
 */
@Test(expected = RuntimeException.class)
public void defaultConfigTest() {
    Retryer.<String>newInstance()
            .maxAttempt(3)
            .listen(RetryListens.noListen())
            .recover(Recovers.noRecover())
            .condition(RetryConditions.hasExceptionCause())
            .retryWaitContext(RetryWaiter.<String>retryWait(NoRetryWait.class).context())
            .callable(new Callable<String>() {
                @Override
                public String call() throws Exception {
                    System.out.println("called...");
                    throw new RuntimeException();
                }
            }).retryCall();
}

這些默認(rèn)值都是可以配置的。

比如什么時(shí)候觸發(fā)重試？重試幾次？多久觸發(fā)一次重試？這些都會(huì)在下面的章節(jié)進(jìn)行詳細(xì)講解。

小結(jié)

本文簡(jiǎn)單介紹了重試框架的設(shè)計(jì)緣由，及其使用入門(mén)。

java 重試框架 sisyphus 開(kāi)源地址

到此這篇關(guān)于java 重試框架 sisyphus 入門(mén)簡(jiǎn)介的文章就介紹到這了,更多相關(guān)java 重試框架 sisyphus 內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論