分布式系統(tǒng)具備的保護(hù)機(jī)制？

一、熔斷

熔斷一般是指依賴的外部接口出現(xiàn)故障的時(shí)斷絕和外部接口的關(guān)系；例如你的A服務(wù)里面的一個(gè)功能依賴B服務(wù)，這時(shí)候B服務(wù)出問題了，返回的很慢。這種情況可能會(huì)因?yàn)檫@么一個(gè)功能而拖慢了A服務(wù)里面的所有功能，因此我們這時(shí)候就需要熔斷！即當(dāng)發(fā)現(xiàn)A要調(diào)用這B時(shí)就直接返回錯(cuò)誤(或者返回其他默認(rèn)值啊啥的)，就不去請(qǐng)求B了。

雪崩效應(yīng)：在微服務(wù)架構(gòu)中，微服務(wù)是完成一個(gè)單一的業(yè)務(wù)功能，這樣做的好處是可以做到解耦，每個(gè)微服務(wù)可以獨(dú)立演進(jìn)。但是，一個(gè)應(yīng)用可能會(huì)有多個(gè)微服務(wù)組成，微服務(wù)之間的數(shù)據(jù)交互通過遠(yuǎn)程過程調(diào)用完成。這就帶來一個(gè)問題，假設(shè)微服務(wù)A調(diào)用微服務(wù)B和微服務(wù)C，微服務(wù)B和微服務(wù)C又調(diào)用其它的微服務(wù)，這就是所謂的“扇出”。如果扇出的鏈路上某個(gè)微服務(wù)的調(diào)用響應(yīng)時(shí)間過長(zhǎng)或者不可用，對(duì)微服務(wù)A的調(diào)用就會(huì)占用越來越多的系統(tǒng)資源，進(jìn)而引起系統(tǒng)崩潰，所謂的“雪崩效應(yīng)”。

熔斷機(jī)制是應(yīng)對(duì)雪崩效應(yīng)的一種微服務(wù)鏈路保護(hù)機(jī)制。在微服務(wù)架構(gòu)中，當(dāng)扇出鏈路的某個(gè)微服務(wù)不可用或者響應(yīng)時(shí)間太長(zhǎng)時(shí)，會(huì)進(jìn)行服務(wù)的降級(jí)，進(jìn)而熔斷該節(jié)點(diǎn)微服務(wù)的調(diào)用，快速返回錯(cuò)誤的響應(yīng)信息。當(dāng)檢測(cè)到該節(jié)點(diǎn)微服務(wù)調(diào)用響應(yīng)正常后，恢復(fù)調(diào)用鏈路。

二、降級(jí)

降級(jí)也就是服務(wù)降級(jí)，當(dāng)我們的服務(wù)器壓力劇增為了保證核心功能的可用性 ，而選擇性的降低一些功能的可用性，或者直接關(guān)閉該功能。這就是典型的丟車保帥了。就比如貼吧類型的網(wǎng)站，當(dāng)服務(wù)器吃不消的時(shí)候，可以選擇把發(fā)帖功能關(guān)閉，注冊(cè)功能關(guān)閉，改密碼，改頭像這些都關(guān)了，為了確保登錄和瀏覽帖子這種核心的功能。

熔斷與降級(jí)的區(qū)別：觸發(fā)原因不太一樣，服務(wù)熔斷一般是某個(gè)服務(wù)（下游服務(wù)）故障引起，而服務(wù)降級(jí)一般是從整體負(fù)荷考慮；

三、限流

限流的目的是通過對(duì)并發(fā)訪問/請(qǐng)求進(jìn)行限速或者一個(gè)時(shí)間窗口內(nèi)的的請(qǐng)求進(jìn)行限速來保護(hù)系統(tǒng)，一旦達(dá)到限制速率則可以拒絕服務(wù)（定向到錯(cuò)誤頁或告知資源沒有了）、排隊(duì)或等待（比如秒殺、評(píng)論、下單）、降級(jí)（返回兜底數(shù)據(jù)或默認(rèn)數(shù)據(jù)，如商品詳情頁庫存默認(rèn)有貨）。

漏桶算法：漏桶算法思路是請(qǐng)求先進(jìn)入到漏桶里，漏桶以一定的速度出水，當(dāng)水流入速度過大會(huì)直接溢出，可以看出漏桶算法能強(qiáng)行限制數(shù)據(jù)的傳輸速率。

?

令牌桶算法：令牌桶算法的原理是系統(tǒng)會(huì)以一個(gè)恒定的速度往桶里放入令牌，而如果請(qǐng)求需要被處理，則需要先從桶里獲取一個(gè)令牌，當(dāng)桶里沒有令牌可取時(shí)，則拒絕服務(wù)。相比于漏桶算法令牌桶的優(yōu)點(diǎn)是可以改變放令牌的速度. 一旦需要提高速率,則按需提高放入桶中的令牌的速率. 一般會(huì)定時(shí)(比如100毫秒)往桶中增加一定數(shù)量的令牌, 有些變種算法則實(shí)時(shí)的計(jì)算應(yīng)該增加的令牌的數(shù)量。Guava的RateLimiter就是采用該算法進(jìn)行限流控制。

?

計(jì)數(shù)器算法：計(jì)數(shù)器算法的核心就是在規(guī)定的時(shí)間內(nèi)限制請(qǐng)求次數(shù)；例如：對(duì)于A接口來說，我們1分鐘的訪問次數(shù)不能超過100個(gè)。在一開 始的時(shí)候，我們可以設(shè)置一個(gè)計(jì)數(shù)器counte=0，每當(dāng)一個(gè)請(qǐng)求過來的時(shí)候，counter就加1，如果counter的值大于100并且該請(qǐng)求與第一個(gè) 請(qǐng)求的間隔時(shí)間還在1分鐘之內(nèi)，那么說明請(qǐng)求數(shù)過多，拒絕請(qǐng)求；如果該請(qǐng)求與第一個(gè)請(qǐng)求的間隔時(shí)間大于1分鐘，且counter的值還在限流范圍內(nèi)，那么就重置 counter=0；

?

Semaphore限流：可以控制某個(gè)資源可被同時(shí)訪問的個(gè)數(shù)，acquire()獲取一個(gè)許可，如果沒有就等待，而release()釋放一個(gè)許可。

四、常用的web服務(wù)器

Nginx主要有兩種限流方式：

按連接數(shù)限流(ngx_http_limit_conn_module)（令牌算法實(shí)現(xiàn)）

按請(qǐng)求速率限流(ngx_http_limit_req_module)（漏桶算法實(shí)現(xiàn)）

tomcat 通過以下三個(gè)配置參數(shù)來進(jìn)行限流操作：

maxThreads（最大線程數(shù)）：每一次HTTP請(qǐng)求到達(dá)Web服務(wù)，tomcat都會(huì)創(chuàng)建一個(gè)線程來處理該請(qǐng)求，那么最大線程數(shù)決定了Web服務(wù)可以同時(shí)處理多少個(gè)請(qǐng)求，默認(rèn)200.

accepCount（最大等待數(shù)）：當(dāng)調(diào)用Web服務(wù)的HTTP請(qǐng)求數(shù)達(dá)到tomcat的最大線程數(shù)時(shí)，還有新的HTTP請(qǐng)求到來，這時(shí)tomcat會(huì)將該請(qǐng)求放在等待隊(duì)列中，這個(gè)acceptCount就是指能夠接受的最大等待數(shù)，默認(rèn)100.如果等待隊(duì)列也被放滿了，這個(gè)時(shí)候再來新的請(qǐng)求就會(huì)被tomcat拒絕（connection refused）。

maxConnections（最大連接數(shù)）：這個(gè)參數(shù)是指在同一時(shí)間，tomcat能夠接受的最大連接數(shù)。一般這個(gè)值要大于maxThreads+acceptCount。

在實(shí)際工作中對(duì)于流量入口的限流一般都是采用Nginx，tomcat一般會(huì)設(shè)置為適合當(dāng)前操作系統(tǒng)的最大連接數(shù)，具體的業(yè)務(wù)限流（某個(gè)服務(wù)接口）一般使用sentinel和hystrix。

五、hystrix

提供了線程池隔離(默認(rèn))與信號(hào)量隔離

六、sentinel

古之學(xué)者為己，今之學(xué)者為人

分類: 中間件

標(biāo)簽: 分布式