解決高併發的三把利器：降級、限流、快取。dubbo的服務降級，採用mock機制。其具有兩種降級處理方式：mock null降級處理，與mock class降級處理<dubbo:referenceid=
"demoservice"
mock
="return null"
inte***ce
="com..."
/>
<dubbo:referenceid=
"demoservice"
mock
="true"
inte***ce
="com..."
/>
//1、mock class demoservicemock，即介面類名稱+mock//2、和介面必須在同乙個包裡，即相同目錄下
public
class
demoservicemock
implements
demoservice
@override
public
void
testvoid()
}
為了防止某個消費者的qps，或者所有消費者的qps總和突然飆公升導致某些重要的服務失敗，系統可以對訪問流量進行限制，這種對集群的保護措施稱為服務限流。dubbo中可以實現現有的方案比較多，可以劃分為兩類：直接限流和間接限流
直接限流：通過對連線資料進行限制來到底限流的目的。（官方方案）
間限限流：通過一些非連線數量設定來到的限流的目的。
改屬性僅能設定在提供者端。可以設定為介面或方法級別。限制的是介面（或方法）併發執行數量。
<dubbo:service
inte***ce
="com...demoservice"
ref="demoservice"
executes
="10"
/>
該屬性僅可設定在提供者端 與用於對指定協議的連線數量進行限制
<dubbo:provide
protocol
="dubbo"
accepts
="10"
/>
<
dubbo:protocol
name
="dubbo"
port
="20880"
accepts
="10"
/>
可以設定在提供者端或消費者端。可以設定成介面級別和方法級別。
<dubbo:service
inte***ce
="com...demoservice"
ref="demoservice"
actives
="10"
/>
<dubbo:referenceid=
"demoservice"
inte***ce
="com..."
actives
="10"
/>
可以設定在提供者端或消費者端，限定連線的個數。可以設定成介面級別和方法級別。
僅可設定下消費者端，且不能設定方法級別。僅作用於dubbo服務暴漏協議。將長連線的建立推遲到消費者呼叫提供者時。
<dubbo:referenceid=
"demoservice"
inte***ce
="com..."
lazy
="true"
/>
<dubbo:consumer
lazy
="true"
/>
僅可設定下消費者端，可以設定在介面和方法級別上。僅作用於dubbo服務暴漏協議。其會使客戶端盡量向同乙個提供者發起呼叫，除非該提供者掛了，其後連線另乙個。
只要啟用了粘連連線，其會自動啟用延遲連線
其限制的是流向，而不是流量。
<dubbo:referenceid=
"demoservice"
inte***ce
="com..."
sticky
="true"
/>
可以設定在提供者端或消費者端。可以設定成介面級別和方法級別。
其限制的是流向，而不是流量。
<dubbo:service
inte***ce
="com...demoservice"
ref="demoservice"
loadbalance
="leastactive"
/>
dubbo 熔斷，限流，降級
1 寫在前面 1.1 名詞解釋 consumer表示服務呼叫方 provider標示服務提供方，dubbo裡面一般就這麼講。下面的a呼叫b服務，一般是泛指呼叫b服務裡面的乙個介面。1.2 拓撲圖 大寫字母表示不同的服務，後面的序號表示同乙個服務部署在不同機器的例項。2 從微觀角度思考 2.1 超時 ...
dubbo 熔斷，限流，降級
1.1 名詞解釋 consumer表示服務呼叫方 provider標示服務提供方，dubbo裡面一般就這麼講。下面的a呼叫b服務，一般是泛指呼叫b服務裡面的乙個介面。1.2 拓撲圖 大寫字母表示不同的服務，後面的序號表示同乙個服務部署在不同機器的例項。2.1 超時 timeout 在介面呼叫過程中，...
dubbo 服務降級
經歷過12306搶票的人應該經常會遇到這個問題 在搶票高峰的時候，明明票還有，但是查詢出來的列表卻是為空的 如果沒票列表也應該會呈現 等高峰過後再查詢，列表又恢復正常。個人猜測應該是查詢過程中出現了問題，要麼超時，要麼網路問題導致查詢失敗採用的服務降級處理。所以，最終呈現給使用者的並不是內部系統出錯...