目錄

一、GateWay

二、服務(wù)調(diào)用OpenFeign

三、Sentinel

1. 流量控制（限流規(guī)則）

2. 隔離和降級

2.1?FeignClient整合Sentinel

2.2 線程隔離（艙壁模式）

2.3 熔斷降級

3. 授權(quán)規(guī)則

3.1 授權(quán)規(guī)則

3.2 自定義異常結(jié)果

4. 規(guī)則持久化

四、分布式事務(wù)seata

4.1 理論基礎(chǔ)

1.?CAP定理

2. BASE理論

3.?解決分布式事務(wù)的思路

4.2 初識Seata

1. Seata基礎(chǔ)知識?

2.?部署TC服務(wù)

3.?微服務(wù)集成seata

4.3?Seata的四種事務(wù)模式詳解

1.?XA模式

1）Seata的XA模型

2）XA模式優(yōu)缺點

3）實現(xiàn)XA模式

2.?AT模式★★★

2）AT與XA的區(qū)別

3）臟寫問題即解決方案

4）優(yōu)缺點

5）代碼實現(xiàn)

3.?TCC模式★★★

1）TCC模式原理

2）優(yōu)缺點

3）事務(wù)懸掛和空回滾

4）代碼實現(xiàn)TCC模式

4.?Saga 模式

四種模式對比★★★

4.4 高可用

五、分布式緩存Redis

5.1 Redis持久化

1. RDB持久化

1）執(zhí)行時機(jī)

2）RDB原理

3）小結(jié)

2. AOF持久化

3. RDB與AOF對比

5.2?Redis主從

1. 搭建主從架構(gòu)

2.?主從數(shù)據(jù)同步原理

2.1 全量同步

2.2 增量同步

2.3 主從同步優(yōu)化

2.4 小結(jié)

5.3 Redis哨兵

1 哨兵原理

1）哨兵的結(jié)構(gòu)和作用

2）集群監(jiān)控原理

3）集群故障恢復(fù)原理

4）小結(jié)

2.?搭建哨兵集群

3.?RedisTemplate

5.4 Redis分片集群

六、多級緩存

七、rabbitmq的高級特性（真清晰）

7.1 消息可靠性

7.2?死信交換機(jī)

1）私信交換機(jī)

2）TTL

3）延遲隊列

7.3 惰性隊列

1）消息堆積問題

2）惰性隊列

7.4 MQ集群

八、面試篇★★★

8.1 微服務(wù)常見面試題

8.2 Nacos源碼分析

1. 服務(wù)發(fā)現(xiàn)

2. 服務(wù)心跳

3.?服務(wù)發(fā)現(xiàn)

8.3?Sentinel源碼分析

1. Sentinel的線程隔離與Hystix的線程隔離有什么差別? （略）

2. Sentinel的限流與Gateway的限流有什么差別？

3. Sentinel源碼分析

4. Sentinel官網(wǎng)地址：

• 課程名稱：SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系統(tǒng)詳解springcloud微服務(wù)技術(shù)棧課程|黑馬程序員Java微服務(wù)
• 課程地址：微服務(wù)技術(shù)棧導(dǎo)學(xué)1_嗶哩嗶哩_bilibili

微服務(wù)其實是分布式架構(gòu)的最佳實踐方案，國內(nèi)最知名是SpringCloud和阿里巴巴的Dubbo。

一、GateWay

微服務(wù)內(nèi)部有相互調(diào)用關(guān)系時，使用Feign組件；外部有用戶訪問時，直接發(fā)請求到微服務(wù)。但為了安全，需要使用GateWay網(wǎng)關(guān)進(jìn)行身份認(rèn)證。網(wǎng)關(guān)功能：

• 身份認(rèn)證和權(quán)限校驗
• 服務(wù)路由、負(fù)載均衡
• 請求限流

?

服務(wù)調(diào)用 | RuoYi

基本介紹

• Feign

Feign 是Spring Cloud Netflix組件中的一量級Restful的 HTTP 服務(wù)客戶端，實現(xiàn)了負(fù)載均衡和 Rest 調(diào)用的開源框架，封裝了Ribbon和RestTemplate, 實現(xiàn)了WebService的面向接口編程，進(jìn)一步降低了項目的耦合度。

• 什么是服務(wù)調(diào)用

顧名思義，就是服務(wù)之間的接口互相調(diào)用，在微服務(wù)架構(gòu)中很多功能都需要調(diào)用多個服務(wù)才能完成某一項功能。

• 為什么要使用Feign

Feign 旨在使編寫 JAVA HTTP 客戶端變得更加簡單，F(xiàn)eign 簡化了RestTemplate代碼，實現(xiàn)了Ribbon負(fù)載均衡，使代碼變得更加簡潔，也少了客戶端調(diào)用的代碼，使用 Feign 實現(xiàn)負(fù)載均衡是首選方案，只需要你創(chuàng)建一個接口，然后在上面添加注解即可。
Feign 是聲明式服務(wù)調(diào)用組件，其核心就是：像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程方法，無感知遠(yuǎn)程 HTTP 請求。讓開發(fā)者調(diào)用遠(yuǎn)程接口就跟調(diào)用本地方法一樣的體驗，開發(fā)者完全無感知這是遠(yuǎn)程方法，無需關(guān)注與遠(yuǎn)程的交互細(xì)節(jié)，更無需關(guān)注分布式環(huán)境開發(fā)。

• Feign vs OpenFeign

Feign 內(nèi)置了Ribbon，用來做客戶端負(fù)載均衡調(diào)用服務(wù)注冊中心的服務(wù)。
Feign 支持的注解和用法參考官方文檔：https://github.com/OpenFeign/feign官方文檔，使用 Feign 的注解定義接口，然后調(diào)用這個接口，就可以調(diào)用服務(wù)注冊中心的服務(wù)。

Feign本身并不支持Spring MVC的注解，它有一套自己的注解，為了更方便的使用Spring Cloud孵化了OpenFeign。并且支持了Spring MVC的注解，如@RequestMapping，@PathVariable等等。
OpenFeign的@FeignClient可以解析Spring MVC的@RequestMapping注解下的接口，并通過動態(tài)代理方式產(chǎn)生實現(xiàn)類，實現(xiàn)類中做負(fù)載均衡調(diào)用服務(wù)。

二、服務(wù)調(diào)用OpenFeign

服務(wù)網(wǎng)關(guān) | RuoYi

?

分布式搜索

以下為【高級篇】知識點

?

三、Sentinel

1. 流量控制（限流規(guī)則）

限流是對服務(wù)故障的一種預(yù)防措施。線程隔離和熔斷降級是故障發(fā)生后的應(yīng)對。?

?

?

?

熱點參數(shù)限流，是一種更細(xì)粒度的流量控制。

2. 隔離和降級

限流是對服務(wù)故障的一種預(yù)防措施，但是一旦服務(wù)出現(xiàn)故障，就很容易把這些故障傳遞給其他依賴于它的服務(wù)，這樣很容易就產(chǎn)生了雪崩。所以，就要靠線程隔離（艙壁模式）和熔斷降級手段避免雪崩。

線程隔離之前講到過：調(diào)用者在調(diào)用服務(wù)提供者時，給每個調(diào)用的請求分配獨立線程池，出現(xiàn)故障時，最多消耗這個線程池內(nèi)資源，避免把調(diào)用者的所有資源耗盡。

熔斷降級：是在調(diào)用方這邊加入斷路器，統(tǒng)計對服務(wù)提供者的調(diào)用，如果調(diào)用的失敗比例過高，則熔斷該業(yè)務(wù)，不允許訪問該服務(wù)的提供者了。

可以看到，不管是線程隔離還是熔斷降級，都是對客戶端（調(diào)用方）的保護(hù)，需要在調(diào)用方 發(fā)起遠(yuǎn)程調(diào)用時做線程隔離、或者服務(wù)熔斷。而我們的微服務(wù)遠(yuǎn)程調(diào)用都是基于Feign來完成的，因此我們需要將Feign與Sentinel整合，在Feign里面實現(xiàn)線程隔離和服務(wù)熔斷。

2.1?FeignClient整合Sentinel

2.2 線程隔離（艙壁模式）

線程隔離有兩種方式實現(xiàn)：

• 線程池隔離

• 信號量隔離（Sentinel默認(rèn)采用）

信號量隔離的特點是？

• 基于計數(shù)器模式，簡單，開銷小

線程池隔離的特點是？

• 基于線程池模式，有額外開銷，但隔離控制更強(qiáng)

?

2.3 熔斷降級

熔斷降級是解決雪崩問題的重要手段。其思路是由斷路器統(tǒng)計服務(wù)調(diào)用的異常比例、慢請求比例，如果超出閾值則會熔斷該服務(wù)。即攔截訪問該服務(wù)的一切請求；而當(dāng)服務(wù)恢復(fù)時，斷路器會放行訪問該服務(wù)的請求。

斷路器控制熔斷和放行是通過狀態(tài)機(jī)來完成的：

?

狀態(tài)機(jī)包括三個狀態(tài)：

• closed：關(guān)閉狀態(tài)，斷路器放行所有請求，并開始統(tǒng)計異常比例、慢請求比例。超過閾值則切換到open狀態(tài)

• open：打開狀態(tài)，服務(wù)調(diào)用被熔斷，訪問被熔斷服務(wù)的請求會被拒絕，快速失敗，直接走降級邏輯。Open狀態(tài)5秒后會進(jìn)入half-open狀態(tài)

• half-open：半開狀態(tài)，放行一次請求，根據(jù)執(zhí)行結(jié)果來判斷接下來的操作。

  • 請求成功：則切換到closed狀態(tài)

  • 請求失?。簞t切換到open狀態(tài)

斷路器熔斷策略有三種：慢調(diào)用、異常比例、異常數(shù)。

?

?

3. 授權(quán)規(guī)則

3.1 授權(quán)規(guī)則

授權(quán)規(guī)則是對請求者的身份進(jìn)行判斷。疑問：前面不是講了所有請求都要經(jīng)過GateWay網(wǎng)關(guān)路由到微服務(wù)嘛，這個時候網(wǎng)關(guān)當(dāng)然可以對請求做身份認(rèn)證，但萬一公司出了內(nèi)鬼把微服務(wù)地址泄露給別人，這個時候他們就可以繞過網(wǎng)關(guān)直接訪問微服務(wù)了，那你網(wǎng)關(guān)做的再嚴(yán)密也沒用了，微服務(wù)赤裸裸的暴露在別人面前，于是，Sentinel的授權(quán)規(guī)則可以解決這個問題：

• 如果是從網(wǎng)關(guān)過來的請求，讓你通過；
• 如果是從其他地方（瀏覽器）過來的，則進(jìn)行攔截。

具體實現(xiàn)可以這樣做：

對于經(jīng)過GateWay網(wǎng)關(guān)的請求，在其請求頭設(shè)置一個值，這樣就可以將從網(wǎng)關(guān)和瀏覽器來的請求區(qū)分開，從而實現(xiàn)身份的判斷。

?

效果如下：

?

• 說明：如果不設(shè)置授權(quán)規(guī)則時，上圖中直接訪問微服務(wù)的請求就不會被攔截哦。自己搭建項目的時候記得驗證一下哦。
• 記住添加請求頭時實現(xiàn)的那個接口名稱。

3.2 自定義異常結(jié)果

默認(rèn)情況下，發(fā)生限流、降級、授權(quán)攔截時，都會拋出異常到調(diào)用方。異常結(jié)果都是flow limmiting（限流）。這樣不夠友好，無法得知是限流還是降級還是授權(quán)攔截。

而如果要自定義異常時的返回結(jié)果，需要實現(xiàn)BlockExceptionHandler接口。

4. 規(guī)則持久化

?

四、分布式事務(wù)seata

?

4.1 理論基礎(chǔ)

解決分布式事務(wù)問題，需要一些分布式系統(tǒng)的基礎(chǔ)知識作為理論指導(dǎo)。

1.?CAP定理

Consistency（一致性）：用戶訪問分布式系統(tǒng)中的任意節(jié)點，得到的數(shù)據(jù)必須一致。

Availability （可用性）：用戶訪問集群中的任意健康節(jié)點，必須能得到響應(yīng)，而不是超時或拒絕。

Partition（分區(qū)）：因為網(wǎng)絡(luò)故障或其它原因?qū)е路植际较到y(tǒng)中的部分節(jié)點與其它節(jié)點失去連接，形成獨立分區(qū)。 Tolerance（容錯）：在集群出現(xiàn)分區(qū)時，整個系統(tǒng)也要持續(xù)對外提供服務(wù)。

視頻147的18分鐘，老師真正講清楚了要么CP，要么AP的原因了。

2. BASE理論

在分布式系統(tǒng)下，因為分區(qū)不可避免，所以不得不在CP/AP之間作出選擇，但是一致性和可用性都非常重要，我一個都不想放棄，那怎么辦？BASE理論就是解決這個問題的。

BASE理論是對CAP的一種解決思路，包含三個思想：

• Basically Available （基本可用）：分布式系統(tǒng)在出現(xiàn)故障時，允許損失部分可用性，即保證核心可用。
• Soft State（軟狀態(tài)）：在一定時間內(nèi)，允許出現(xiàn)中間狀態(tài)，比如臨時的不一致狀態(tài)。
• Eventually Consistent（最終一致性）：雖然無法保證強(qiáng)一致性，但是在軟狀態(tài)結(jié)束后，最終達(dá)到數(shù)據(jù)一致。

3.?解決分布式事務(wù)的思路

分布式事務(wù)最大的問題是各個子事務(wù)的一致性問題，因此可以借鑒CAP定理和BASE理論：

• AP模式：各子事務(wù)分別執(zhí)行和提交，允許出現(xiàn)結(jié)果不一致，然后采用彌補(bǔ)措施恢復(fù)數(shù)據(jù)即可，實現(xiàn)最終一致。
• CP模式：各個子事務(wù)執(zhí)行后互相等待，同時提交，同時回滾，達(dá)成強(qiáng)一致。但事務(wù)等待過程中，處于弱可用狀態(tài)。

但不管是哪一種模式，都需要在子系統(tǒng)事務(wù)之間互相通訊，協(xié)調(diào)事務(wù)狀態(tài)，也就是需要一個事務(wù)協(xié)調(diào)者(TC)：

?

這里的子系統(tǒng)事務(wù)，稱為分支事務(wù)；有關(guān)聯(lián)的各個分支事務(wù)在一起稱為全局事務(wù)。

?

4.2 初識Seata

優(yōu)先官網(wǎng)學(xué)習(xí)：Seata 是什么？ | Apache Seata

分布式事務(wù) Seata 及其三種模式詳解 | Apache Seata

1. Seata基礎(chǔ)知識?

?

Seata 中有三大模塊，分別是 TM、RM 和 TC。 其中 TM 和 RM 是作為 Seata 的客戶端與業(yè)務(wù)系統(tǒng)集成在一起，TC 作為 Seata 的服務(wù)端獨立部署。?

?

在 Seata 中，分布式事務(wù)的執(zhí)行流程：

• TM 開啟分布式事務(wù)（TM 向 TC 注冊全局事務(wù)記錄）；
• 按業(yè)務(wù)場景，編排數(shù)據(jù)庫、服務(wù)等事務(wù)內(nèi)資源（RM 向 TC 匯報資源準(zhǔn)備狀態(tài)?）；
• TM 結(jié)束分布式事務(wù)，事務(wù)一階段結(jié)束（TM 通知 TC?提交/回滾分布式事務(wù)）；
• TC 匯總事務(wù)信息，決定分布式事務(wù)是提交還是回滾；
• TC 通知所有 RM 提交/回滾 資源，事務(wù)二階段結(jié)束；

Seata提供了四種不同的分布式事務(wù)解決方案：

• XA模式：強(qiáng)一致性分階段事務(wù)模式，犧牲了一定的可用性，無業(yè)務(wù)侵入
• TCC模式：最終一致的分階段事務(wù)模式，有業(yè)務(wù)侵入
• AT模式：最終一致的分階段事務(wù)模式，無業(yè)務(wù)侵入，也是Seata的默認(rèn)模式
• SAGA模式：長事務(wù)模式，有業(yè)務(wù)侵入

分布式事務(wù) Seata 及其三種模式詳解 | Apache Seata

2.?部署TC服務(wù)

TC：維護(hù)全局和分支事務(wù)的狀態(tài)，協(xié)調(diào)全局事務(wù)提交或回滾。

?

配置文件registry.conf修改后內(nèi)容如下：

registry {
  # tc服務(wù)的注冊中心類，這里選擇nacos，也可以是eureka、zookeeper等
  type = "nacos"

  nacos {
    # seata tc 服務(wù)注冊到 nacos的服務(wù)名稱，可以自定義
    application = "seata-tc-server"
    serverAddr = "127.0.0.1:8848"
    group = "DEFAULT_GROUP"
    namespace = ""
    cluster = "SH"
    username = "nacos"
    password = "nacos"
  }
}

config {
  # 讀取tc服務(wù)端的配置文件的方式，這里是從nacos配置中心讀取，這樣如果tc是集群，可以共享配置
  type = "nacos"
  # 配置nacos地址等信息
  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    group = "SEATA_GROUP"
    username = "nacos"
    password = "nacos"
    dataId = "seataServer.properties"
  }
}

3.?微服務(wù)集成seata

第一步：在微服務(wù)中引入seata依賴：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <exclusions>
        <!--版本較低，1.3.0，因此排除-->
        <exclusion>
            <artifactId>seata-spring-boot-starter</artifactId>
            <groupId>io.seata</groupId>
        </exclusion>
    </exclusions>
</dependency>
<!--seata starter 采用1.4.2版本-->
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <version>${seata.version}</version>
</dependency>

第二步如下：?

?

seata:
  registry: # TC服務(wù)注冊中心的配置，微服務(wù)根據(jù)這些信息去注冊中心獲取tc服務(wù)地址
    # 參考tc服務(wù)自己的registry.conf中的配置
    type: nacos
    nacos: # tc
      server-addr: 127.0.0.1:8848
      namespace: ""
      group: DEFAULT_GROUP
      application: seata-tc-server # tc服務(wù)在nacos中的服務(wù)名稱
      cluster: SH
  tx-service-group: seata-demo # 事務(wù)組，根據(jù)這個獲取tc服務(wù)的cluster名稱
  service:
    vgroup-mapping: # 事務(wù)組與TC服務(wù)cluster的映射關(guān)系
      seata-demo: SH

這兩步，每個微服務(wù)項目都需要做哦。?

總結(jié)：

?

4.3?Seata的四種事務(wù)模式詳解

1.?XA模式

XA 規(guī)范是 X/Open 組織定義的分布式事務(wù)處理（DTP，Distributed Transaction Processing）標(biāo)準(zhǔn)，XA 規(guī)范描述了全局的TM與局部的RM之間的接口，幾乎所有主流的數(shù)據(jù)庫都對XA 規(guī)范提供了支持。

XA是規(guī)范，目前主流數(shù)據(jù)庫都實現(xiàn)了這種規(guī)范，實現(xiàn)的原理都是基于兩階段提交。

一階段：

• 事務(wù)協(xié)調(diào)者通知每個事物參與者執(zhí)行本地事務(wù)

• 本地事務(wù)執(zhí)行完成后報告事務(wù)執(zhí)行狀態(tài)給事務(wù)協(xié)調(diào)者，此時事務(wù)不提交，繼續(xù)持有數(shù)據(jù)庫鎖

二階段：

• 事務(wù)協(xié)調(diào)者基于一階段的報告來判斷下一步操作

  • 如果一階段都成功，則通知所有事務(wù)參與者，提交事務(wù)

  • 如果一階段任意一個參與者失敗，則通知所有事務(wù)參與者回滾事務(wù)

1）Seata的XA模型

Seata對原始的XA模式做了簡單的封裝和改造，以適應(yīng)自己的事務(wù)模型，基本架構(gòu)如圖：

?

2）XA模式優(yōu)缺點

優(yōu)點：

• 事務(wù)的強(qiáng)一致性，滿足ACID原則。

• 常用數(shù)據(jù)庫都支持，實現(xiàn)簡單，并且沒有代碼侵入

缺點：

• 因為一階段需要鎖定數(shù)據(jù)庫資源，等待二階段結(jié)束才釋放，性能較差

• 依賴關(guān)系型數(shù)據(jù)庫實現(xiàn)事務(wù)

3）實現(xiàn)XA模式

Seata的starter已經(jīng)完成了XA模式的自動裝配，實現(xiàn)非常簡單，步驟如下：

第一步：修改application.yml文件（每個參與事務(wù)的微服務(wù)），開啟XA模式：

seata:
  data-source-proxy-mode: XA

第二步：給發(fā)起全局事務(wù)的入口方法添加@GlobalTransactional注解。

2.?AT模式★★★

AT模式同樣是分階段提交的事務(wù)模型，不過缺彌補(bǔ)了XA模型中資源鎖定周期過長的缺陷。

1）AT模式原理?

?

2）AT與XA的區(qū)別

簡述AT模式與XA模式最大的區(qū)別是什么？

• XA模式一階段不提交事務(wù)，鎖定資源；AT模式一階段直接提交，不鎖定資源。
• XA模式依賴數(shù)據(jù)庫機(jī)制實現(xiàn)回滾；AT模式利用數(shù)據(jù)快照實現(xiàn)數(shù)據(jù)回滾。
• XA模式強(qiáng)一致；AT模式最終一致。

3）臟寫問題即解決方案

臟寫問題，歸根結(jié)底是沒有隔離的原因。

解決思路就是引入了全局鎖的概念。在釋放DB鎖之前，先拿到全局鎖。避免同一時刻有另外一個事務(wù)來操作當(dāng)前數(shù)據(jù)。（全局鎖是由TC管理的，比數(shù)據(jù)庫DB鎖粒度更細(xì)，所以比XA模式效率高）

?

4）優(yōu)缺點

AT模式的優(yōu)點：

• 一階段完成直接提交事務(wù)，釋放數(shù)據(jù)庫資源，性能比較好

• 利用全局鎖實現(xiàn)讀寫隔離

• 沒有代碼侵入，框架自動完成回滾和提交

AT模式的缺點：

• 兩階段之間屬于軟狀態(tài)，屬于最終一致

• 框架的快照功能會影響性能，但比XA模式要好很多

5）代碼實現(xiàn)

AT模式中的快照生成、回滾等動作都是由框架自動完成，沒有任何代碼侵入，因此實現(xiàn)非常簡單。只不過，AT模式需要一個表來記錄全局鎖、另一張表來記錄數(shù)據(jù)快照undo_log。

?

AT模式是默認(rèn)的模式。

3.?TCC模式★★★

前面學(xué)的XA模式、AT模式都能實現(xiàn)一致性和隔離性。XA模式是強(qiáng)一致，AT是最終一致；隔離性上XA是一階段不提交，基于事務(wù)本身的特性來完成隔離，而AT模式是加了全局鎖，鎖定資源去隔離事務(wù)。本質(zhì)上看，這兩種都是通過加鎖來實現(xiàn)的。只要加鎖，就會有性能損耗，如果要追求極致的性能，就需要學(xué)習(xí)其他模式。TCC模式就不需要加鎖。

1）TCC模式原理

TCC模式與AT模式非常相似，每階段都是獨立事務(wù)，不同的是TCC通過人工編碼來實現(xiàn)數(shù)據(jù)恢復(fù)。需要實現(xiàn)三個方法：

• Try：資源的檢測和預(yù)留；
• Confirm：完成資源操作業(yè)務(wù)；要求 Try 成功 Confirm 一定要能成功。
• Cancel：預(yù)留資源釋放，可以理解為try的反向操作。

?

?

2）優(yōu)缺點

TCC模式的每個階段是做什么的？

• Try：資源檢查和預(yù)留

• Confirm：業(yè)務(wù)執(zhí)行和提交

• Cancel：預(yù)留資源的釋放

TCC的優(yōu)點是什么？

• 一階段完成直接提交事務(wù)，釋放數(shù)據(jù)庫資源，性能好

• 相比AT模型，無需生成快照，無需使用全局鎖，性能最強(qiáng)

• 不依賴數(shù)據(jù)庫事務(wù)，而是依賴補(bǔ)償操作，可以用于非事務(wù)型數(shù)據(jù)庫

TCC的缺點是什么？

• 有代碼侵入，需要人為編寫try、Confirm和Cancel接口，太麻煩

• 軟狀態(tài)，事務(wù)是最終一致

• 需要考慮Confirm和Cancel的失敗情況，做好冪等處理

3）事務(wù)懸掛和空回滾

?

4）代碼實現(xiàn)TCC模式

?

在視頻149的57分鐘處，老師說，為什么我們只改造一個服務(wù)？因為并不是所有的服務(wù)都適合TCC模式。比如我們這三個微服務(wù)，分別是下單、扣余額、扣庫存，“下單”是新增訂單的業(yè)務(wù)邏輯，因此是不需要Try（資源檢查和預(yù)留）的；“扣庫存”是可以用TCC模式實現(xiàn)的，不過這里我們只演示“扣余額”這個服務(wù)。那一個分布式事務(wù)中，既有AT模式，又有TCC模式，最終能行嗎？答案是可以的，它們都屬于Seata內(nèi)部的實現(xiàn)，而且都是分階段提交，一階段是直接提交，二階段做回滾等操作。

?

?

4.?Saga 模式

?

四種模式對比★★★

?

4.4 高可用

1. 高可用集群結(jié)構(gòu)

2. 實現(xiàn)高可用集群

五、分布式緩存Redis

?

5.1 Redis持久化

1. RDB持久化

RDB全稱Redis Database Backup file（Redis數(shù)據(jù)備份文件），也被叫做Redis數(shù)據(jù)快照。簡單來說就是把內(nèi)存中的所有數(shù)據(jù)都記錄到磁盤中。當(dāng)Redis實例故障重啟后，從磁盤讀取快照文件，恢復(fù)數(shù)據(jù)?？煺瘴募Q為RDB文件，默認(rèn)是保存在當(dāng)前運行目錄。

1）執(zhí)行時機(jī)

RDB持久化在四種情況下會執(zhí)行：

• 執(zhí)行save命令

• 執(zhí)行bgsave命令

• Redis停機(jī)時

• 觸發(fā)RDB條件時

• save命令會導(dǎo)致主進(jìn)程執(zhí)行RDB，這個過程中其它所有命令都會被阻塞。只有在數(shù)據(jù)遷移時可能用到。
• bgsave命令會開啟獨立進(jìn)程完成RDB，主進(jìn)程可以持續(xù)處理用戶請求，不受影響。
• Redis停機(jī)時會執(zhí)行一次save命令，實現(xiàn)RDB持久化。
• Redis內(nèi)部有觸發(fā)RDB的機(jī)制，可以在redis.conf文件中找到，格式如下：?

2）RDB原理

bgsave開始時會fork主進(jìn)程得到子進(jìn)程，子進(jìn)程共享主進(jìn)程的內(nèi)存數(shù)據(jù)。完成fork后讀取內(nèi)存數(shù)據(jù)并寫入 RDB 文件。

fork采用的是copy-on-write技術(shù)：

• 當(dāng)主進(jìn)程執(zhí)行讀操作時，訪問共享內(nèi)存；

• 當(dāng)主進(jìn)程執(zhí)行寫操作時，則會拷貝一份數(shù)據(jù)，執(zhí)行寫操作。

?

3）小結(jié)

RDB方式bgsave的基本流程？

• fork主進(jìn)程得到一個子進(jìn)程，共享內(nèi)存空間

• 子進(jìn)程讀取內(nèi)存數(shù)據(jù)并寫入新的RDB文件

• 用新RDB文件替換舊的RDB文件

RDB會在什么時候執(zhí)行？save 60 1000代表什么含義？

• 默認(rèn)是服務(wù)停止時

• 代表60秒內(nèi)至少執(zhí)行1000次修改則觸發(fā)RDB

RDB的缺點？

• RDB執(zhí)行間隔時間長，兩次RDB之間寫入數(shù)據(jù)有丟失的風(fēng)險

• fork子進(jìn)程、壓縮、寫出RDB文件都比較耗時

2. AOF持久化

AOF全稱為Append Only File（追加文件）。Redis處理的每一個寫命令都會記錄在AOF文件，可以看做是命令日志文件。

?

?

3. RDB與AOF對比

?

5.2?Redis主從

1. 搭建主從架構(gòu)

單節(jié)點Redis的并發(fā)能力是有上限的，要進(jìn)一步提高Redis的并發(fā)能力，就需要搭建主從集群，實現(xiàn)讀寫分離。

?

2.?主從數(shù)據(jù)同步原理

2.1 全量同步

主從第一次建立連接時，會執(zhí)行全量同步，將master節(jié)點的所有數(shù)據(jù)都拷貝給slave節(jié)點，流程：

?

完整流程描述：

• slave節(jié)點請求增量同步

• master節(jié)點判斷replid，發(fā)現(xiàn)不一致，拒絕增量同步

• master將完整內(nèi)存數(shù)據(jù)生成RDB，發(fā)送RDB到slave

• slave清空本地數(shù)據(jù)，加載master的RDB

• master將RDB期間的命令記錄在repl_baklog，并持續(xù)將log中的命令發(fā)送給slave

• slave執(zhí)行接收到的命令，保持與master之間的同步

2.2 增量同步

master怎么知道slave與自己的數(shù)據(jù)差異在哪里呢?

這就要說到全量同步時的repl_baklog文件了。這個文件是一個固定大小的數(shù)組，只不過數(shù)組是環(huán)形，也就是說角標(biāo)到達(dá)數(shù)組末尾后，會再次從0開始讀寫，這樣數(shù)組頭部的數(shù)據(jù)就會被覆蓋。

repl_baklog中會記錄Redis處理過的命令日志及offset，包括master當(dāng)前的offset，和slave已經(jīng)拷貝到的offset。slave與master的offset之間的差異，就是salve需要增量拷貝的數(shù)據(jù)了。

2.3 主從同步優(yōu)化

主從同步可以保證主從數(shù)據(jù)的一致性，非常重要。

可以從以下幾個方面來優(yōu)化Redis主從就集群：

• 在master中配置repl-diskless-sync yes啟用無磁盤復(fù)制，避免全量同步時的磁盤IO。

• Redis單節(jié)點上的內(nèi)存占用不要太大，減少RDB導(dǎo)致的過多磁盤IO

• 適當(dāng)提高repl_baklog的大小，發(fā)現(xiàn)slave宕機(jī)時盡快實現(xiàn)故障恢復(fù)，盡可能避免全量同步

• 限制一個master上的slave節(jié)點數(shù)量，如果實在是太多slave，則可以采用主-從-從鏈?zhǔn)浇Y(jié)構(gòu)，減少master壓力

主從從架構(gòu)圖：

?

2.4 小結(jié)

簡述全量同步和增量同步區(qū)別？

• 全量同步：master將完整內(nèi)存數(shù)據(jù)生成RDB，發(fā)送RDB到slave。后續(xù)命令則記錄在repl_baklog，逐個發(fā)送給slave。

• 增量同步：slave提交自己的offset到master，master獲取repl_baklog中從offset之后的命令給slave

什么時候執(zhí)行全量同步？

• slave節(jié)點第一次連接master節(jié)點時

• slave節(jié)點斷開時間太久，repl_baklog中的offset已經(jīng)被覆蓋時

什么時候執(zhí)行增量同步？

• slave節(jié)點斷開又恢復(fù)，并且在repl_baklog中能找到offset時

5.3 Redis哨兵

slave節(jié)點宕機(jī)恢復(fù)后可以找master節(jié)點同步數(shù)據(jù)，那master節(jié)點宕機(jī)怎么辦？Redis提供了哨兵（Sentinel）機(jī)制來實現(xiàn)主從集群的自動故障恢復(fù)。

1 哨兵原理

1）哨兵的結(jié)構(gòu)和作用

?

2）集群監(jiān)控原理

Sentinel基于心跳機(jī)制監(jiān)測服務(wù)狀態(tài)，每隔1秒向集群的每個實例發(fā)送ping命令：

• 主觀下線：如果某sentinel節(jié)點發(fā)現(xiàn)某實例未在規(guī)定時間響應(yīng)，則認(rèn)為該實例主觀下線。
• 客觀下線：若超過指定數(shù)量（quorum）的sentinel都認(rèn)為該實例主觀下線，則該實例客觀下線。quorum值最好超過Sentinel實例數(shù)量的一半。

3）集群故障恢復(fù)原理

一旦發(fā)現(xiàn)master故障，sentinel需要在salve中選擇一個作為新的master，選擇依據(jù)是這樣的：

• 首先會判斷slave節(jié)點與master節(jié)點斷開時間長短，如果超過指定值（down-after-milliseconds * 10）則會排除該slave節(jié)點

• 然后判斷slave節(jié)點的slave-priority值，越小優(yōu)先級越高，如果是0則永不參與選舉

• 如果slave-prority一樣，則判斷slave節(jié)點的offset值，越大說明數(shù)據(jù)越新，優(yōu)先級越高

• 最后是判斷slave節(jié)點的運行id大小，越小優(yōu)先級越高。

當(dāng)選出一個新的master后，該如何實現(xiàn)切換呢？

流程如下：

• sentinel給備選的slave1節(jié)點發(fā)送slaveof no one命令，讓該節(jié)點成為master

• sentinel給所有其它slave發(fā)送slaveof 192.168.150.101 7002 命令，讓這些slave成為新master的從節(jié)點，開始從新的master上同步數(shù)據(jù)。

• 最后，sentinel將故障節(jié)點標(biāo)記為slave，當(dāng)故障節(jié)點恢復(fù)后會自動成為新的master的slave節(jié)點

4）小結(jié)

Sentinel的三個作用是什么？

• 監(jiān)控

• 故障轉(zhuǎn)移

• 通知

Sentinel如何判斷一個redis實例是否健康？

• 每隔1秒發(fā)送一次ping命令，如果超過一定時間沒有相向則認(rèn)為是主觀下線

• 如果大多數(shù)sentinel都認(rèn)為實例主觀下線，則判定服務(wù)下線

故障轉(zhuǎn)移步驟有哪些？

• 首先選定一個slave作為新的master，執(zhí)行slaveof no one

• 然后讓所有節(jié)點都執(zhí)行slaveof 新master

• 修改故障節(jié)點配置，添加slaveof 新master

2.?搭建哨兵集群

?

3.?RedisTemplate

在Sentinel集群監(jiān)管下的Redis主從集群，其節(jié)點會因為自動故障轉(zhuǎn)移而發(fā)生變化，Redis的客戶端必須感知這種變化，及時更新連接信息。Spring的RedisTemplate底層利用lettuce實現(xiàn)了節(jié)點的感知和自動切換。

下面，我們通過一個測試來實現(xiàn)RedisTemplate集成哨兵機(jī)制。

第一步：引入課前資料提供的Demo工程，并添加依賴：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

第二步：在配置文件application.yml中指定redis的sentinel相關(guān)信息：

spring:
  redis:
    sentinel:
      master: mymaster
      nodes:
        - 192.168.150.101:27001
        - 192.168.150.101:27002
        - 192.168.150.101:27003

第三步：配置讀寫分離；

在項目的啟動類中，添加一個新的bean：

@Bean
public LettuceClientConfigurationBuilderCustomizer clientConfigurationBuilderCustomizer(){
 ? ?return clientConfigurationBuilder -> clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
}

這個bean中配置的就是讀寫策略，包括四種：

• MASTER：從主節(jié)點讀取

• MASTER_PREFERRED：優(yōu)先從master節(jié)點讀取，master不可用才讀取replica

• REPLICA：從slave（replica）節(jié)點讀取

• REPLICA _PREFERRED：優(yōu)先從slave（replica）節(jié)點讀取，所有的slave都不可用才讀取master

5.4 Redis分片集群

?

分片集群不再需要哨兵了，節(jié)點之間會自動路由，具有哨兵機(jī)制所有的功能。

更多內(nèi)容詳見講義。

• 搭建分片集群
• 散列插槽
• 集群伸縮
• 故障轉(zhuǎn)移
• RedisTemplate訪問分片集群

六、多級緩存

6.1 傳統(tǒng)緩存存在的問題

傳統(tǒng)的緩存策略一般是請求到達(dá)Tomcat后，先查詢Redis，如果未命中則查詢數(shù)據(jù)庫，如圖：

?

存在下面的問題：

• 請求要經(jīng)過Tomcat處理，Tomcat的性能成為整個系統(tǒng)的瓶頸
• Redis緩存失效時，會對數(shù)據(jù)庫產(chǎn)生沖擊

6.2 多級緩存?

?

多級緩存就是充分利用請求處理的每個環(huán)節(jié)，分別添加緩存，減輕Tomcat壓力，提升服務(wù)性能：

• 瀏覽器訪問靜態(tài)資源時，優(yōu)先讀取瀏覽器本地緩存

• 訪問非靜態(tài)資源（ajax查詢數(shù)據(jù)）時，訪問服務(wù)端

• 請求到達(dá)Nginx后，優(yōu)先讀取Nginx本地緩存

• 如果Nginx本地緩存未命中，則去直接查詢Redis（不經(jīng)過Tomcat）

• 如果Redis查詢未命中，則查詢Tomcat

• 請求進(jìn)入Tomcat后，優(yōu)先查詢JVM進(jìn)程緩存

• 如果JVM進(jìn)程緩存未命中，則查詢數(shù)據(jù)庫

本講內(nèi)容，詳見講義：

• JVM進(jìn)程緩存
• Lua語法入門
• 實現(xiàn)多級緩存
• 緩存同步

七、rabbitmq的高級特性（真清晰）

消息隊列在使用過程中，面臨著很多實際問題需要思考：

?

7.1 消息可靠性

消息從發(fā)送，到消費者接收，會經(jīng)理多個過程：

?

其中的每一步都可能導(dǎo)致消息丟失，常見的丟失原因包括：

• 發(fā)送時丟失：

  • 生產(chǎn)者發(fā)送的消息未送達(dá)exchange

  • 消息到達(dá)exchange后未到達(dá)queue

• MQ宕機(jī)，queue將消息丟失

• consumer接收到消息后未消費就宕機(jī)

針對這些問題，RabbitMQ分別給出了解決方案：

• 生產(chǎn)者確認(rèn)機(jī)制

• mq持久化

• 消費者確認(rèn)機(jī)制

• 失敗重試機(jī)制

總結(jié)：

如何確保RabbitMQ消息的可靠性？

• 開啟生產(chǎn)者確認(rèn)機(jī)制，確保生產(chǎn)者的消息能到達(dá)隊列

• 開啟持久化功能，確保消息未消費前在隊列中不會丟失

• 開啟消費者確認(rèn)機(jī)制為auto，由spring確認(rèn)消息處理成功后完成ack

• 開啟消費者失敗重試機(jī)制，并設(shè)置MessageRecoverer，多次重試失敗后將消息投遞到異常交換機(jī)，交由人工處理

7.2?死信交換機(jī)

1）私信交換機(jī)

什么是死信？

當(dāng)一個隊列中的消息滿足下列情況之一時，可以成為死信（dead letter）：

• 消費者使用basic.reject或 basic.nack聲明消費失敗，并且消息的requeue參數(shù)設(shè)置為false

• 消息是一個過期消息，超時無人消費

• 要投遞的隊列消息滿了，無法投遞

如果這個包含死信的隊列配置了dead-letter-exchange屬性，指定了一個交換機(jī)，那么隊列中的死信就會投遞到這個交換機(jī)中，而這個交換機(jī)稱為死信交換機(jī)（Dead Letter Exchange，檢查DLX）。

總結(jié)

什么樣的消息會成為死信？

• 消息被消費者reject或者返回nack

• 消息超時未消費

• 隊列滿了

死信交換機(jī)的使用場景是什么？

• 如果隊列綁定了死信交換機(jī)，死信會投遞到死信交換機(jī)；

• 可以利用死信交換機(jī)收集所有消費者處理失敗的消息（死信），交由人工處理，進(jìn)一步提高消息隊列的可靠性。

2）TTL

消息超時的兩種方式是？

• 給隊列設(shè)置ttl屬性，進(jìn)入隊列后超過ttl時間的消息變?yōu)樗佬?/p>

• 給消息設(shè)置ttl屬性，隊列接收到消息超過ttl時間后變?yōu)樗佬?/p>

如何實現(xiàn)發(fā)送一個消息20秒后消費者才收到消息？

• 給消息的目標(biāo)隊列指定死信交換機(jī)

• 將消費者監(jiān)聽的隊列綁定到死信交換機(jī)

• 發(fā)送消息時給消息設(shè)置超時時間為20秒

3）延遲隊列

利用TTL結(jié)合死信交換機(jī)，我們實現(xiàn)了消息發(fā)出后，消費者延遲收到消息的效果。這種消息模式就稱為延遲隊列（Delay Queue）模式。

延遲隊列的使用場景包括：

• 延遲發(fā)送短信

• 用戶下單，如果用戶在15 分鐘內(nèi)未支付，則自動取消

• 預(yù)約工作會議，20分鐘后自動通知所有參會人員

因為延遲隊列的需求非常多，所以RabbitMQ的官方也推出了一個插件，原生支持延遲隊列效果。這個插件就是DelayExchange插件。參考RabbitMQ的插件列表頁面：Community Plugins | RabbitMQ

DelayExchange原理

DelayExchange需要將一個交換機(jī)聲明為delayed類型。當(dāng)我們發(fā)送消息到delayExchange時，流程如下：

• 接收消息

• 判斷消息是否具備x-delay屬性

• 如果有x-delay屬性，說明是延遲消息，持久化到硬盤，讀取x-delay值，作為延遲時間

• 返回routing not found結(jié)果給消息發(fā)送者

• x-delay時間到期后，重新投遞消息到指定隊列

7.3 惰性隊列

1）消息堆積問題

當(dāng)生產(chǎn)者發(fā)送消息的速度超過了消費者處理消息的速度，就會導(dǎo)致隊列中的消息堆積，直到隊列存儲消息達(dá)到上限。之后發(fā)送的消息就會成為死信，可能會被丟棄，這就是消息堆積問題。

解決消息堆積有兩種思路：

• 增加更多消費者，提高消費速度。也就是我們之前說的work queue模式

• 擴(kuò)大隊列容積，提高堆積上限

要提升隊列容積，把消息保存在內(nèi)存中顯然是不行的。

2）惰性隊列

從RabbitMQ的3.6.0版本開始，就增加了Lazy Queues的概念，也就是惰性隊列。惰性隊列的特征如下：

• 接收到消息后直接存入磁盤而非內(nèi)存

• 消費者要消費消息時才會從磁盤中讀取并加載到內(nèi)存

• 支持?jǐn)?shù)百萬條的消息存儲

總結(jié)

消息堆積問題的解決方案？

• 隊列上綁定多個消費者，提高消費速度

• 使用惰性隊列，可以再mq中保存更多消息

惰性隊列的優(yōu)點有哪些？

• 基于磁盤存儲，消息上限高

• 沒有間歇性的page-out，性能比較穩(wěn)定

惰性隊列的缺點有哪些？

• 基于磁盤存儲，消息時效性會降低

• 性能受限于磁盤的IO

7.4 MQ集群

RabbitMQ的是基于Erlang語言編寫，而Erlang又是一個面向并發(fā)的語言，天然支持集群模式。RabbitMQ的集群有兩種模式：

• 普通集群：是一種分布式集群，將隊列分散到集群的各個節(jié)點，從而提高整個集群的并發(fā)能力。
• 鏡像集群：是一種主從集群，普通集群的基礎(chǔ)上，添加了主從備份功能，提高集群的數(shù)據(jù)可用性。

鏡像集群雖然支持主從，但主從同步并不是強(qiáng)一致的，某些情況下可能有數(shù)據(jù)丟失的風(fēng)險。因此在RabbitMQ的3.8版本以后，推出了新的功能：仲裁隊列來代替鏡像集群，底層采用Raft協(xié)議確保主從的數(shù)據(jù)一致性。

八、面試篇★★★

?

8.1 微服務(wù)常見面試題

分為微服務(wù)篇，RabbitMQ篇，Redis篇。

8.2 Nacos源碼分析

分為三大塊：服務(wù)注冊、服務(wù)心跳、服務(wù)發(fā)現(xiàn)。

1. 服務(wù)發(fā)現(xiàn)

?

?

• Nacos的注冊表結(jié)構(gòu)是什么樣的？

  • 答：Nacos是多級存儲模型，最外層通過namespace來實現(xiàn)環(huán)境隔離，然后是group分組，分組下就是服務(wù)，一個服務(wù)有可以分為不同的集群，集群中包含多個實例。因此其注冊表結(jié)構(gòu)為一個Map，類型是：

    Map<String, Map<String, Service>>，

    外層key是namespace_id，內(nèi)層key是group+serviceName.

    Service內(nèi)部維護(hù)一個Map，結(jié)構(gòu)是：Map<String,Cluster>，key是clusterName，值是集群信息

    Cluster內(nèi)部維護(hù)一個Set集合，元素是Instance類型，代表集群中的多個實例。

• Nacos如何保證并發(fā)寫的安全性？

  • 答：首先，在注冊實例時，會對service加鎖，不同service之間本身就不存在并發(fā)寫問題，互不影響。相同service時通過鎖來互斥。并且，在更新實例列表時，是基于異步的線程池來完成，而線程池的線程數(shù)量為1.

• Nacos如何避免并發(fā)讀寫的沖突？

  • 答：Nacos在更新實例列表時，會采用CopyOnWrite技術(shù)，首先將Old實例列表拷貝一份，然后更新拷貝的實例列表，再用更新后的實例列表來覆蓋舊的實例列表。

• Nacos如何應(yīng)對阿里內(nèi)部數(shù)十萬服務(wù)的并發(fā)寫請求？

  • 答：Nacos內(nèi)部會將服務(wù)注冊的任務(wù)放入阻塞隊列，采用線程池異步來完成實例更新，從而提高并發(fā)寫能力。

2. 服務(wù)心跳

Nacos的實例分為臨時實例和永久實例兩種，可以通過在yaml 文件配置：

spring:
  application:
    name: order-service
  cloud:
    nacos:
      discovery:
        ephemeral: false # 設(shè)置實例為永久實例。true：臨時; false：永久
      server-addr: 192.168.150.1:8845

臨時實例基于心跳方式做健康檢測，而永久實例則是由Nacos主動探測實例狀態(tài)。

Nacos的健康檢測有兩種模式：

• 臨時實例：

  • 采用客戶端心跳檢測模式，心跳周期5秒

  • 心跳間隔超過15秒則標(biāo)記為不健康

  • 心跳間隔超過30秒則從服務(wù)列表刪除

• 永久實例：

  • 采用服務(wù)端主動健康檢測方式

  • 周期為2000 + 5000毫秒內(nèi)的隨機(jī)數(shù)

  • 檢測異常只會標(biāo)記為不健康，不會刪除

那么為什么Nacos有臨時和永久兩種實例呢？

以淘寶為例，雙十一大促期間，流量會比平常高出很多，此時服務(wù)肯定需要增加更多實例來應(yīng)對高并發(fā)，而這些實例在雙十一之后就無需繼續(xù)使用了，采用臨時實例比較合適。而對于服務(wù)的一些常備實例，則使用永久實例更合適。

與eureka相比，Nacos與Eureka在臨時實例上都是基于心跳模式實現(xiàn)，差別不大，主要是心跳周期不同，eureka是30秒，Nacos是5秒。

另外，Nacos支持永久實例，而Eureka不支持，Eureka只提供了心跳模式的健康監(jiān)測，而沒有主動檢測功能。

3.?服務(wù)發(fā)現(xiàn)

Nacos的服務(wù)發(fā)現(xiàn)分為兩種模式：

• 模式一：主動拉取模式，消費者定期主動從Nacos拉取服務(wù)列表并緩存起來，再服務(wù)調(diào)用時優(yōu)先讀取本地緩存中的服務(wù)列表。

• 模式二：訂閱模式，消費者訂閱Nacos中的服務(wù)列表，并基于UDP協(xié)議來接收服務(wù)變更通知。當(dāng)Nacos中的服務(wù)列表更新時，會發(fā)送UDP廣播給所有訂閱者。

與Eureka相比，Nacos的訂閱模式服務(wù)狀態(tài)更新更及時，消費者更容易及時發(fā)現(xiàn)服務(wù)列表的變化，剔除故障服務(wù)。

8.3?Sentinel源碼分析

1. Sentinel的線程隔離與Hystix的線程隔離有什么差別? （略）

2. Sentinel的限流與Gateway的限流有什么差別？

?

?

?

?

?

3. Sentinel源碼分析

?

Sentinel實現(xiàn)限流、隔離、降級、熔斷等功能，本質(zhì)要做的就是兩件事情：

• 統(tǒng)計數(shù)據(jù)：統(tǒng)計某個資源的訪問數(shù)據(jù)（QPS、RT等信息）

• 規(guī)則判斷：判斷限流規(guī)則、隔離規(guī)則、降級規(guī)則、熔斷規(guī)則是否滿足

這里的資源就是希望被Sentinel保護(hù)的業(yè)務(wù)，例如項目中定義的controller方法就是默認(rèn)被Sentinel保護(hù)的資源。

實現(xiàn)上述功能的核心骨架是一個叫做ProcessorSlotChain的類。這個類基于責(zé)任鏈模式來設(shè)計，將不同的功能（限流、降級、系統(tǒng)保護(hù)）封裝為一個個的Slot，請求進(jìn)入后逐個執(zhí)行即可。

其工作流如圖：

?

責(zé)任鏈中的Slot也分為兩大類：

• 統(tǒng)計數(shù)據(jù)構(gòu)建部分（statistic）

  • NodeSelectorSlot：負(fù)責(zé)構(gòu)建簇點鏈路中的節(jié)點（DefaultNode），將這些節(jié)點形成鏈路樹

  • ClusterBuilderSlot：負(fù)責(zé)構(gòu)建某個資源的ClusterNode，ClusterNode可以保存資源的運行信息（響應(yīng)時間、QPS、block 數(shù)目、線程數(shù)、異常數(shù)等）以及來源信息（origin名稱）

  • StatisticSlot：負(fù)責(zé)統(tǒng)計實時調(diào)用數(shù)據(jù)，包括運行信息、來源信息等

• 規(guī)則判斷部分（rule checking）

  • AuthoritySlot：負(fù)責(zé)授權(quán)規(guī)則（來源控制）

  • SystemSlot：負(fù)責(zé)系統(tǒng)保護(hù)規(guī)則

  • ParamFlowSlot：負(fù)責(zé)熱點參數(shù)限流規(guī)則

  • FlowSlot：負(fù)責(zé)限流規(guī)則

  • DegradeSlot：負(fù)責(zé)降級規(guī)則

4. Sentinel官網(wǎng)地址：

basic-implementation | Sentinel

Sentinel工作主流程 · alibaba/Sentinel Wiki · GitHub文章來源地址http://www.zghlxwxcb.cn/news/detail-859237.html

到了這里，關(guān)于黑馬微服務(wù)課程1的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！