[[202009]]

導(dǎo)語

Raft算法是一種分布式一致性算法。與paxos相比，它更易理解和工程化。我們完整實(shí)現(xiàn)了該算法并將其應(yīng)用在自研的高可靠消息中間件CMQ中，同時(shí)沉淀出對(duì)外通用的Raft算法庫。本文主要介紹Raft算法的原理、工程化時(shí)遇到的問題與解決方案、以及改進(jìn)性能的措施。

一 背景介紹

分布式系統(tǒng)是指一組獨(dú)立的計(jì)算機(jī)，通過網(wǎng)絡(luò)協(xié)同工作的系統(tǒng)，客戶看來就如同單臺(tái)機(jī)器在工作。隨著互聯(lián)網(wǎng)時(shí)代數(shù)據(jù)規(guī)模的爆發(fā)式增長，傳統(tǒng)的單機(jī)系統(tǒng)在性能和可用性上已經(jīng)無法勝任，分布式系統(tǒng)具有擴(kuò)展性強(qiáng)，可用性高，廉價(jià)高效等優(yōu)點(diǎn)，得以廣泛應(yīng)用。

但與單機(jī)系統(tǒng)相比，分布式系統(tǒng)在實(shí)現(xiàn)上要復(fù)雜很多。CAP理論是分布式系統(tǒng)的理論基石，它提出在以下3個(gè)要素中：

Consistency(強(qiáng)一致性)：任何客戶端都可以讀取到其他客戶端最近的更新。

Availability(可用性)： 系統(tǒng)一直處于可服務(wù)狀態(tài)。

Partition-tolenrance(分區(qū)可容忍性)：單機(jī)故障或網(wǎng)絡(luò)分區(qū)，系統(tǒng)仍然可以保證強(qiáng)一致性和可用性。

一個(gè)分布式系統(tǒng)最多只能滿足其中2個(gè)要素。對(duì)于分布式系統(tǒng)而言，P顯然是必不可少的，那么只能在AP和CP之間權(quán)衡。AP系統(tǒng)犧牲強(qiáng)一致性，這在某些業(yè)務(wù)場景下(如金融類)是不可接受的，CP系統(tǒng)可以滿足這類需求，問題的關(guān)鍵在于會(huì)犧牲多少可用性。傳統(tǒng)的主備強(qiáng)同步模式雖然可以保證一致性，但一旦機(jī)器故障或網(wǎng)絡(luò)分區(qū)系統(tǒng)將變得不可用。paxos和raft等一致性算法的提出，彌補(bǔ)了這一缺陷。它們在保證CP的前提下，只要求大多數(shù)節(jié)點(diǎn)可以正?；ヂ?lián)，系統(tǒng)便可以一直處于可用狀態(tài)，可用性上顯著提高。paxos的理論性偏強(qiáng)，開發(fā)者需要自己處理很多細(xì)節(jié)，這也是它有很多變種的原因，相對(duì)而言raft更易理解和工程化，一經(jīng)提出便廣受歡迎。

在我們關(guān)注的消息中間件領(lǐng)域，金融支付類業(yè)務(wù)往往對(duì)數(shù)據(jù)的強(qiáng)一致性和高可靠性有嚴(yán)格要求。強(qiáng)一致性：A給B轉(zhuǎn)賬100元，系統(tǒng)返回A轉(zhuǎn)賬成功。此后B查詢余額時(shí)應(yīng)該能顯示收到100元，如果發(fā)現(xiàn)并未收到或隔一段時(shí)間后才收到，那這樣的系統(tǒng)非強(qiáng)一致性;高可靠性：一個(gè)請求如果返回客戶成功，那么需要保證請求結(jié)果不丟失。

在對(duì)主流的消息中間件進(jìn)行調(diào)研后，發(fā)現(xiàn)它們在應(yīng)對(duì)這種場景時(shí)都存在一定的不足：

RabbitMQ：一個(gè)請求需要在所有節(jié)點(diǎn)上處理2次才能保證一致性，性能不高。

Kafka：kafka主要應(yīng)用在日志、大數(shù)據(jù)等方向，少量丟失數(shù)據(jù)業(yè)務(wù)可以忍受，但不適合要求數(shù)據(jù)高可靠性的系統(tǒng)。

RocketMQ：未采用一致性算法，如果配置成異步模式可能丟失數(shù)據(jù)，同步模式下節(jié)點(diǎn)故障或網(wǎng)絡(luò)分區(qū)都會(huì)影響可用性。

SQS：只提供最終一致性，不保證強(qiáng)一致性。

鑒于以上分析，我們設(shè)計(jì)開發(fā)了基于Raft的強(qiáng)一致高可靠消息中間件CMQ。接下來會(huì)詳細(xì)介紹raft算法原理細(xì)節(jié)、如何應(yīng)用在CMQ中在保證消息可靠不丟失以及實(shí)現(xiàn)過程中我們在性能方面所作的優(yōu)化。

二 Raft算法核心原理

2.1 概述

raft算法是Diego Ongaro博士在論文《In Search of an Understandable Consensus Algorithm》,2014 USENIX中***提出，算法主要包括選舉和日志同步兩部分:

***階段 選舉：

• 從集群中選出一個(gè)合適的節(jié)點(diǎn)作為Leader。

第二階段 日志同步：

• 選舉出的Leader接收客戶端請求，將其轉(zhuǎn)為raft日志。
• Leader將日志同步到其他節(jié)點(diǎn)，當(dāng)大多數(shù)節(jié)點(diǎn)寫入成功后，日志變?yōu)镃ommitted，一經(jīng)Committed日志便不會(huì)再被篡改。
• Leader故障時(shí)，切換到***階段，重新選舉。

以下是貫穿raft算法的重要術(shù)語：

Term： 節(jié)點(diǎn)當(dāng)前所處的周期，可以看作一個(gè)文明所處的時(shí)代。

votedFor： 當(dāng)前Term的投票信息，每個(gè)節(jié)點(diǎn)在給定的Term上只能投票一次。

Entry： raft日志中的基本單元，包含index、term和user_data。其中index在日志文件中順序分配，term為創(chuàng)建該entry的leader term，user_data 業(yè)務(wù)數(shù)據(jù)。

State : 節(jié)點(diǎn)角色(Leader、Candidate、Follower之一)。

CommitIndex：已提交到的日志Index。

State Machine：狀態(tài)機(jī)。業(yè)務(wù)模塊，與Raft交互。

ApplyIndex：已應(yīng)用到的日志Index。

ElectionTime：選舉超時(shí)時(shí)間。

節(jié)點(diǎn)之間通過RPC通信來完成選舉和日志同步，發(fā)送方在發(fā)送RPC時(shí)會(huì)攜帶自身的Term，接收方在處理RPC時(shí)有以下兩條通用規(guī)則：

• RPC中的RTerm大于自身當(dāng)前Term，更新自身Term = RTerm、votedFor = null，轉(zhuǎn)為Follower。
• RPC中的RTerm小于自身當(dāng)前Term，拒絕請求，響應(yīng)包中攜帶自身的Term。

2.2 選舉

Raft算法屬于強(qiáng)Leader模式，只有Leader可以處理客戶端的請求，Leader通過心跳維持自身地位，除非Leader故障或網(wǎng)絡(luò)異常，否則Leader保持不變。選舉階段的目的就是為了從集群中選出合適的Leader節(jié)點(diǎn)。

選舉流程：

1.節(jié)點(diǎn)初始狀態(tài)均為Follower，F(xiàn)ollower只被動(dòng)接收請求，如果ElectionTime到期時(shí)仍未收到Leader的AppendEntry RPC，F(xiàn)ollower認(rèn)為當(dāng)前沒有Leader，轉(zhuǎn)為Candidate。

2.Candidate在集群中廣播RequestVote RPC，嘗試競選Leader，其他節(jié)點(diǎn)收到后首先判斷是否同意本次選舉，并將結(jié)果返回給Candidate。如果Candidate收到大多數(shù)節(jié)點(diǎn)的同意響應(yīng)，轉(zhuǎn)為Leader。

3.Leader接收客戶端請求，將其轉(zhuǎn)為Entry追加到日志文件，同時(shí)通過AppendEntry RPC同步日志Entry給其他節(jié)點(diǎn)。

下面通過一個(gè)案例詳細(xì)說明選舉流程。

1)初始狀態(tài)：3個(gè)節(jié)點(diǎn)組成的集群，初始均為Follower狀態(tài)，圖中方格部分代表節(jié)點(diǎn)的raft日志。

2)發(fā)起選舉：節(jié)點(diǎn)1選舉定時(shí)器先到期，轉(zhuǎn)為Candidate，Term自增，更新voteFor=1(投票給自己)，接著廣播RequestVote RPC給集群中其他節(jié)點(diǎn)，RequestVote RPC會(huì)攜帶節(jié)點(diǎn)的日志信息。

3)響應(yīng)選舉：節(jié)點(diǎn)2和3收到RequestVote RPC后，根據(jù)RPC規(guī)則，更新term和voteFor(term:6 , voteFor:null );然后判斷是否同意本次選舉，如果已投票給別人，則拒絕本次選舉(這里voteFor：null 未投票)，如果RequestVote RPC中的日志沒有自身全，也拒絕，否則同意(這里節(jié)點(diǎn)1的日志比2、3都更全);***通過voteReply RPC響應(yīng)投票結(jié)果。

4)選舉完成：由于節(jié)點(diǎn)2和3都同意本次選舉，所以節(jié)點(diǎn)1在收到任何一個(gè)的voteReply RPC便轉(zhuǎn)為Leader(大多數(shù)同意即可)。

選舉超時(shí)值：

在選舉時(shí)可能會(huì)出現(xiàn)兩個(gè)節(jié)點(diǎn)的選舉定時(shí)器同時(shí)到期并發(fā)起選舉，各自得到一半選票導(dǎo)致選舉失敗，選舉失敗意味著系統(tǒng)沒有Leader，不可服務(wù)。如果選舉定時(shí)器是定值，很可能兩者再次同時(shí)到期。為了降低沖突的概率，選舉超時(shí)值采用隨機(jī)值的方式。此外，選舉超時(shí)值如果過大會(huì)導(dǎo)致Leader故障會(huì)很久才會(huì)再次選舉。選舉超時(shí)值通常取300ms~600ms之間的隨機(jī)值。

2.3日志同步

選舉階段完成后，Leader節(jié)點(diǎn)開始接收客戶端請求，將請求封裝成Entry追加到raft日志文件末尾，之后同步Entry到其他Follower節(jié)點(diǎn)。當(dāng)大多數(shù)節(jié)點(diǎn)寫入成功后，該Entry被標(biāo)記為committed，raft算法保證了committed的Entry一定不會(huì)再被修改。

日志同步具體流程：

1)Leader上為每個(gè)節(jié)點(diǎn)維護(hù)NextIndex、MatchIndex，NextIndex表示待發(fā)往該節(jié)點(diǎn)的Entry index，MatchIndex表示該節(jié)點(diǎn)已匹配的Entry index，同時(shí)每個(gè)節(jié)點(diǎn)維護(hù)CommitIndex表示當(dāng)前已提交的Entry index。轉(zhuǎn)為Leader后會(huì)將所有節(jié)點(diǎn)的NextIndex置為自己***一條日志index+1，MatchIndex全置0，同時(shí)將自身CommitIndex置0。

2)Leader節(jié)點(diǎn)不斷將user_data轉(zhuǎn)為Entry追加到日志文件末尾，Entry包含index、term和user_data，其中index在日志文件中從1開始順序分配，term為Leader當(dāng)前的term。

3)Leader通過AppendEntry RPC將Entry同步到Followers，F(xiàn)ollower收到后校驗(yàn)該Entry之前的日志是否已匹配。如匹配則直接寫入Entry，返回成功;否則刪除不匹配的日志，返回失敗。校驗(yàn)是通過在AppendEntry RPC中攜帶待寫入Entry的前一條entry信息完成。

4)當(dāng)Follower返回成功時(shí)，更新對(duì)應(yīng)節(jié)點(diǎn)的NextIndex和MatchIndex，繼續(xù)發(fā)送后續(xù)的Entry。如果MatchIndex更新后，大多數(shù)節(jié)點(diǎn)的MatchIndex已大于CommitIndex，則更新CommitIndex。Follower返回失敗時(shí)回退NextIndex繼續(xù)發(fā)送，直到Follower返回成功。

5)Leader每次AppendEntry RPC中會(huì)攜帶當(dāng)前***的LeaderCommitIndex，F(xiàn)ollower寫入成功時(shí)會(huì)將自身CommitIndex更新為Min(LastLogIndex,LeaderCommitIndex)。

同步過程中每次日志的寫入均需刷盤以保證宕機(jī)時(shí)數(shù)據(jù)不丟失。

下面通過一個(gè)例子介紹日志同步基本流程：

1)初始狀態(tài)所有節(jié)點(diǎn)的Term=2，CommitIndex=2，接著Leader收到一條y←9的請求，轉(zhuǎn)為Entry寫入日志的末尾，Entry的index =3 term =1。

2)Leader通過AppendEntry RPC同步該Entry給2個(gè)Follower，RPC中包含前一條Entry信息(index=2 term =1)，F(xiàn)ollower收到后首先校驗(yàn)前一條Entry是否與自身匹配(這里匹配成功)，之后寫入該Entry，返回Leader成功。

3)Leader在收到Follower的回包后，更新相應(yīng)節(jié)點(diǎn)的NextIndex和MatchIndex，這時(shí)大多數(shù)節(jié)點(diǎn)MatchIndex已經(jīng)大于CommitIndex，所以Leader更新CommitIndex=3。

4)Leader繼續(xù)發(fā)送AppendEntry到Follower，此時(shí)由于沒有新Entry，所以RPC中entry信息為空，LeaderCommitIndex為3。Follower收到后更新CommitIndex=3 (Min(3,3))。

日志沖突：

在日志同步的過程中，可能會(huì)出現(xiàn)節(jié)點(diǎn)之間日志不一致的問題。例如Follower寫日志過慢、Leader切換導(dǎo)致舊Leader上未提交的臟數(shù)據(jù)等場景下都會(huì)發(fā)生。在Raft算法中，日志沖突時(shí)以Leader的日志為準(zhǔn)，F(xiàn)ollower刪除不匹配部分。

如下圖所示，F(xiàn)ollower節(jié)點(diǎn)與Leader節(jié)點(diǎn)的日志都存在不一致問題，其中(a)、(b)節(jié)點(diǎn)日志不全，(c)、(d)、(e)、(f)有沖突日志。Leader首先從index=11(***一條Entry index +1)開始發(fā)送AppendEntry RPC,Follower均返回不匹配，Leader收到后不斷回退。(a)、(b)在找到***條匹配的日志后正常同步，(c)、(d)、(e)、(f)在這個(gè)過程中會(huì)逐步刪除不一致的日志，最終所有節(jié)點(diǎn)的日志都與Leader一致。成為Leader節(jié)點(diǎn)后不會(huì)修改和刪除已存在的日志，只會(huì)追加新的日志。

2.4 算法證明

Raft算法的2個(gè)核心屬性：

1)已提交的日志不會(huì)再修改;(可靠性)

2)所有節(jié)點(diǎn)上的數(shù)據(jù)一致。(一致性)

具體證明如下：

1)Leader Completeness：給定Term上提交的日志一定存在于后續(xù)更高Term的 Leader上。(日志不丟失)

• 選舉出的Leader一定包含當(dāng)前已提交所有日志：已提交的日志存在于大多數(shù)節(jié)點(diǎn)上，而同意選舉的前提是候選者的日志必須夠全或更新。一個(gè)不包含已提交日志的節(jié)點(diǎn)必然不會(huì)得到大多數(shù)節(jié)點(diǎn)的選票(這些節(jié)點(diǎn)上都有已提交的日志，不滿足日志足夠全的前提)，也就無法成為Leader。
• Leader節(jié)點(diǎn)不修改和刪除已存在日志(算法的約束)。

綜上所述，選舉和日志同步時(shí)都不會(huì)破壞已提交的日志，得證。

2)State Machine Safety：所有節(jié)點(diǎn)的數(shù)據(jù)最終一致。

根據(jù)Leader Completeness可知已提交的日志不會(huì)再修改，業(yè)務(wù)的狀態(tài)機(jī)依次取出Entry中的user_data應(yīng)用，最終所有節(jié)點(diǎn)的數(shù)據(jù)一致。

2.5集群管理

Raft算法中充分考慮了工程化中集群管理問題，支持動(dòng)態(tài)的添加節(jié)點(diǎn)到集群，剔除故障節(jié)點(diǎn)等。下面詳細(xì)描述添加和刪除節(jié)點(diǎn)流程。

• 添加節(jié)點(diǎn)

如下圖所示，集群中包含A B C，A為Leader，現(xiàn)在添加節(jié)點(diǎn)D。

1)清空D節(jié)點(diǎn)上的所有數(shù)據(jù)，避免有臟數(shù)據(jù)。

2)Leader將存量的日志通過AppendEntry RPC同步到D，使D的數(shù)據(jù)跟上其他節(jié)點(diǎn)。

3)待D的日志追上后，Leader A創(chuàng)建一條Config Entry，其中集群信息包含ABCD。

4)Leader A將Config Entry同步給B C D，F(xiàn)ollower收到后應(yīng)用，之后所有節(jié)點(diǎn)的集群信息都變?yōu)锳BCD，添加完成。

注：在步驟2過程中,Leader仍在不斷接收客戶請求生成Entry，所以只要D與A日志相差不大即認(rèn)為D已追上。

• 刪除節(jié)點(diǎn)

如下圖所示，集群中原來包含A B C D，A為Leader，現(xiàn)在剔除節(jié)點(diǎn)D。

1) Leader A創(chuàng)建一條Config Entry，其中集群信息為ABC。

2) A將日志通過AppendEntry RPC同步給節(jié)點(diǎn)B C。

3) A B C在應(yīng)用該日志后集群信息變?yōu)锳BC，A不再發(fā)送AppendEntry給D，D從集群中移除。

4) 此時(shí)D的集群信息依舊為ABCD，在選舉超時(shí)到期后，發(fā)起選舉，為了防止D的干擾，引入額外機(jī)制：所有節(jié)點(diǎn)在正常接收Leader的AppendEntry時(shí)，拒絕其他節(jié)點(diǎn)發(fā)來的選舉請求。

5) 將D的數(shù)據(jù)清空并下線。

2.5 Raft應(yīng)用

我們用State Matchine統(tǒng)一表示業(yè)務(wù)模塊，其通過ApplyIndex維護(hù)已應(yīng)用到的日志index。以下為Raft與狀態(tài)機(jī)交互的流程：

1)客戶端請求發(fā)往Leader節(jié)點(diǎn)。

2)Leader節(jié)點(diǎn)的Raft模塊將請求轉(zhuǎn)為Entry并同步到Followers。

3)大多數(shù)節(jié)點(diǎn)寫入成功后Raft模塊更新CommitIndex。

4)各節(jié)點(diǎn)的State Machine順序讀取ApplyIndex+1到CimmitIndex之間的Entry，取出其中的user_data并應(yīng)用，完成后更新ApplyIndex。

5)Leader 上的State Machine通知客戶端操作成功。

6)如此循環(huán)。

2.6 快照管理

在節(jié)點(diǎn)重啟時(shí)，由于無法得知State Matchine當(dāng)前ApplyIndex(除非每次應(yīng)用完日志都持久化ApplyIndex，還要保證是原子操作，代價(jià)較大)，所以必須清空State Matchine的數(shù)據(jù)，將ApplyIndex置為0,，從頭開始應(yīng)用日志，代價(jià)太大，可以通過定期創(chuàng)建快照的方式解決該問題。如下圖所示：

1) 在應(yīng)用完Entry 5 后，將當(dāng)前State Matchine的數(shù)據(jù)連同Entry信息寫入快照文件。

2) 如果節(jié)點(diǎn)重啟，首先從快照文件中恢復(fù)State Matchine，等價(jià)于應(yīng)用了截止到Entry 5為止的所有Entry，但效率明顯提高。

3) 將ApplyIndex置為5，之后從Entry 6繼續(xù)應(yīng)用日志，數(shù)據(jù)和重啟前一致。

快照的優(yōu)點(diǎn)：

• 降低重啟耗時(shí)：通過snapshot +　raft log恢復(fù)，無需從***條Entry開始。
• 節(jié)省空間：快照做完后即可刪除快照點(diǎn)之前的Raft日志。

2.7異常場景及處理

Raft具有很強(qiáng)的容錯(cuò)性，只要大多數(shù)節(jié)點(diǎn)正?；ヂ?lián)，即可保證系統(tǒng)的一致性和可用性，下面是一些常見的異常情況，以及他們的影響及處理：

可以看到異常情況對(duì)系統(tǒng)的影響很小，即使是Leader故障也可以在極短的時(shí)間內(nèi)恢復(fù)，任何情況下系統(tǒng)都一直保持強(qiáng)一致性，為此犧牲了部分可用性(大多數(shù)節(jié)點(diǎn)故障時(shí)，概率極低)。不過，Leader故障時(shí)新的Leader可能會(huì)包含舊Leader未提交或已提交但尚未通知客戶端的日志，由于算法規(guī)定成為Leader后不允許刪除日志，所以這部分日志會(huì)被新Leader同步并提交，但由于連接信息丟失，客戶端無法得知該情況，當(dāng)發(fā)起重試后會(huì)出現(xiàn)重復(fù)數(shù)據(jù)，需要有冪等性保證。此外，raft的核心算法都是圍繞Leader展開，網(wǎng)絡(luò)分區(qū)時(shí)可能出現(xiàn)偽Leader問題，也需要特殊考慮。

以下是網(wǎng)絡(luò)分區(qū)時(shí)產(chǎn)生偽Leader 的過程：

上述情況下，Leader與2個(gè)Follower網(wǎng)絡(luò)異常，而2個(gè)Follower之間通信正常，由于收不到Leader的心跳，其中一個(gè)Follower發(fā)起選舉并成為Leader，原Leader成為偽Leader，接下來我們分析該場景下是否會(huì)影響系統(tǒng)的一致性：

寫一致性：發(fā)往新Leader的寫請求可以被提交，而發(fā)往偽Leader的請求無法得到提交，只有一個(gè)Leader在正常處理寫請求，所以不影響寫一致性。

讀一致性：如果讀請求不經(jīng)過Raft同步，那么當(dāng)客戶端的寫請求被發(fā)往新Leader并執(zhí)行成功后，讀請求發(fā)往了偽Leader并得到結(jié)果，就會(huì)造成數(shù)據(jù)不一致。有兩種方案可以解決該問題：

讀請求也經(jīng)過Raft同步，這樣就不會(huì)有不一致的問題，但會(huì)增加系統(tǒng)負(fù)載。

讀請求收到后，Leader節(jié)點(diǎn)等待大多數(shù)節(jié)點(diǎn)再次響應(yīng)心跳RPC，接著返回結(jié)果。

因?yàn)榇蠖鄶?shù)節(jié)點(diǎn)響應(yīng)心跳，說明當(dāng)前一定沒有另一個(gè)Leader存在(大多數(shù)節(jié)點(diǎn)還與當(dāng)前Leader維持租約，新Leader需要得到大多數(shù)投票)。

2.8 小結(jié)

Raft算法具備強(qiáng)一致、高可靠、高可用等優(yōu)點(diǎn)，具體體現(xiàn)在：

強(qiáng)一致性：雖然所有節(jié)點(diǎn)的數(shù)據(jù)并非實(shí)時(shí)一致，但Raft算法保證Leader節(jié)點(diǎn)的數(shù)據(jù)最全，同時(shí)所有請求都由Leader處理，所以在客戶端角度看是強(qiáng)一致性的。

高可靠性：Raft算法保證了Committed的日志不會(huì)被修改，State Matchine只應(yīng)用Committed的日志，所以當(dāng)客戶端收到請求成功即代表數(shù)據(jù)不再改變。Committed日志在大多數(shù)節(jié)點(diǎn)上冗余存儲(chǔ)，少于一半的磁盤故障數(shù)據(jù)不會(huì)丟失。

高可用性：從Raft算法原理可以看出，選舉和日志同步都只需要大多數(shù)的節(jié)點(diǎn)正?；ヂ?lián)即可，所以少量節(jié)點(diǎn)故障或網(wǎng)絡(luò)異常不會(huì)影響系統(tǒng)的可用性。即使Leader故障，在選舉超時(shí)到期后，集群自發(fā)選舉新Leader，無需人工干預(yù)，不可用時(shí)間極小。但Leader故障時(shí)存在重復(fù)數(shù)據(jù)問題，需要業(yè)務(wù)去重或冪等性保證。

高性能：與必須將數(shù)據(jù)寫到所有節(jié)點(diǎn)才能返回客戶端成功的算法相比，Raft算法只需要大多數(shù)節(jié)點(diǎn)成功即可，少量節(jié)點(diǎn)處理緩慢不會(huì)延緩整體系統(tǒng)運(yùn)行。

原文鏈接：https://cloud.tencent.com/community/article/678192

【本文是51CTO專欄作者“騰訊云技術(shù)社區(qū)”的原創(chuàng)稿件，轉(zhuǎn)載請通過51CTO聯(lián)系原作者獲取授權(quán)】

戳這里，看該作者更多好文