dubbo超時重試和服務降級

超時是針對消費端仍是服務端？
dubbo的超時是針對客戶端的
超時的實現原理是什麼？
dubbo默認採用了netty作爲網絡組件，它屬於一種NIO的模式。消費端發起遠程請求後，線程不會阻塞等待服務端的返回，而是立刻獲得一個ResponseFuture，消費端經過不斷的輪詢機制判斷結果是否有返回。由於是經過輪詢，輪詢有個須要特別注要的就是避免死循環，因此爲了解決這個問題就引入了超時機制，只在必定時間範圍內作輪詢，若是超時時間就返回超時異常。實現代碼在DefaultFuture中的get方法中。前端

public Object get(int timeout) throws RemotingException {
        if (timeout <= 0) {
            timeout = Constants.DEFAULT_TIMEOUT;
        }
        if (! isDone()) {
            long start = System.currentTimeMillis();
            lock.lock();
            try {
                while (! isDone()) {
                    done.await(timeout, TimeUnit.MILLISECONDS);
                    if (isDone() || System.currentTimeMillis() - start > timeout) {
                        break;
                    }
                }
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            } finally {
                lock.unlock();
            }
            if (! isDone()) {
                throw new TimeoutException(sent > 0, channel, getTimeoutMessage(false));
            }
        }
        return returnFromResponse();
    }

超時解決的是什麼問題？
當前端大量請求併發出現時，頗有能夠將業務線程池中的線程消費完，由於默認缺省的線程池是固定大小，對調用的服務設置超時時間，是爲了不由於某種緣由致使線程被長時間佔用，最終出現線程池用完返回拒絕服務的異常。
超時與服務降級
發生超時異常時，進而致使整個獲取產品明細的接口異常，這也就是日常說的強依賴。這類強依賴是超時不能解決的，解決方案通常是兩種：
調用時作異常捕獲，返回空值或者返回具體的錯誤碼，消費端根據不一樣的錯誤碼作不一樣的處理。
調用作服務降級，好比發生異常時返回一個mock的數據,dubbo默認支持mock。
只有經過作異常捕獲或者服務降級才能確保某些不重要的依賴出問題時不影響主服務的穩定性。而超時就能夠與服務降級結合起來用。
超時重試可能會致使服務器雪崩。web