應(yīng)用場景

交易、金融等事務(wù)系統(tǒng)往往會有各種下游，絕大多數(shù)時候我們會以同步方式進行訪問，如調(diào)用RPC、HTTP等。 這些下游在通常延時相對穩(wěn)定，但有時可能出現(xiàn)極端的超大延時，這些極端case可能具備特定的業(yè)務(wù)特征，也有可能單純是硬件、網(wǎng)絡(luò)的問題造成，最終表現(xiàn)在系統(tǒng)P99或者P999的延時出現(xiàn)了突刺，如果是面向C端的場景，也會向用戶報出一些系統(tǒng)錯誤，造成用戶體驗的下降。 一種簡易的解決方案是，針對關(guān)鍵的下游節(jié)點增加超時控制。在特定時間內(nèi)，如果下游到期還未返回，不再暴露系統(tǒng)級錯誤，而是做特殊化處理，比如返回「處理中」狀態(tài)。

Go實現(xiàn)方案

設(shè)計一個方法，使用閉包，傳入時間和執(zhí)行的任務(wù)，如果任務(wù)執(zhí)行完未到時間，則直接返回，否則通知調(diào)用者超時。 為了保證代碼簡介和使用簡單，我們僅定義一個Wrapper方法，方法定義如下 func TimeoutControlWrapper(duration time.Duration, fn func()) (timeout bool)

官方包time有一個After方法，可以在指定時間內(nèi)，返回一個channel，基于此來判斷是否超時。 另外，在Wrapper方法里異步化執(zhí)行目標方法，執(zhí)行完成后寫入一個finish信號通知。 同時監(jiān)聽這兩個channel，判斷是否超時，代碼如下

func TimeoutControlWrapper(duration time.Duration, fn func()) (timeout bool) {
        finish := make(chan struct{})
        go func() {
                fn()
                finish <- struct{}{}
        }()

        select {
        case <-finish:
                return false
        case <-time.After(duration):
                return true
        }
}

結(jié)合場景，假設(shè)系統(tǒng)會調(diào)用一個支付系統(tǒng)的接口，接口本身延時不穩(wěn)定，因此我們套用TimeoutControlWrapper

func CallPaymentSystem(param PayParam) (payStatus PayStatus) {
    var payStatus PayStatus
    timeout := TimeoutControlWrapper(time.Second, func() {
        payStatus = PaymentSystemRPC.Pay(param)
    })
    if timeout {
        warn()    // WARN告警
        return  PROCESSING  // 返回處理中
    }
    return payStatus
}

延伸思考

上述通過一個簡單的Wrapper，來實現(xiàn)調(diào)用下游時的超時控制。但在引入的場景里，實現(xiàn)上是不嚴謹?shù)?。哪怕不增加超時控制，我們也無法確認請求是否真實到達了下游系統(tǒng)，這本質(zhì)上是一個分布式事務(wù)的問題，需要我們設(shè)計更加健全的系統(tǒng)能力保證一致性，比如通過消息的方式、補償機制、增加對賬系統(tǒng)。

到此這篇關(guān)于Go實現(xiàn)超時控制的具體使用的文章就介紹到這了,更多相關(guān)Go 超時控制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論