這篇文章主要講解了“怎么使用SOFAStack”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么使用SOFAStack”吧！

目前成都創(chuàng)新互聯(lián)公司已為成百上千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬空間、網(wǎng)站托管維護(hù)、企業(yè)網(wǎng)站設(shè)計(jì)、城步網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

一、背景知識(shí)：Raft 共識(shí)性算法是什么？

Raft 是一種分布式系統(tǒng)中易于理解的共識(shí)算法，該協(xié)議本質(zhì)上是 Paxos 算法的精簡版，而不同的是依靠 Raft 模塊化的拆分以及更加簡化的設(shè)計(jì)，其實(shí)現(xiàn)起來更加容易和方便。[1]

模塊化的拆分主要體現(xiàn)在 Raft 把一致性協(xié)議劃分為如下幾部分：

1. Leader 選舉；

2. Membership 變更；

3. 日志復(fù)制；

4. Snapshot。

而更加簡化的設(shè)計(jì)則體現(xiàn)在：Raft 不允許類似 Paxos 中的亂序提交、簡化系統(tǒng)中的角色狀態(tài)（算法定義 Leader、Follower 和 Candidate 三種角色）、限制僅 Leader 可寫入、采用隨機(jī)超時(shí)觸發(fā) Leader Election 機(jī)制來避免“瓜分選票”等等。[2]

1.1 Raft 算法的整體結(jié)構(gòu)概覽

cdn.nlark.com/yuque/0/2019/png/439987/1565080443481-be36948c-ecee-46cc-ad3a-c5c9d5b5799c.png">

從上面的 Raft 算法整體結(jié)構(gòu)圖中可以看出，整個(gè)分布式系統(tǒng)中同一時(shí)刻有且僅有一個(gè) Leader 角色的節(jié)點(diǎn)（如圖最右邊的服務(wù)器），只有 Leader 節(jié)點(diǎn)可以接受 Client 發(fā)送過來的請(qǐng)求。Leader 節(jié)點(diǎn)負(fù)責(zé)主動(dòng)與所有 Follower 節(jié)點(diǎn)進(jìn)行網(wǎng)絡(luò)通信（如圖左邊兩個(gè)服務(wù)器），負(fù)責(zé)將本地的日志發(fā)送給所有 Follower 節(jié)點(diǎn)，并收集分布式系統(tǒng)中多數(shù)派的 Follower 節(jié)點(diǎn)的響應(yīng)。此外，Leader 節(jié)點(diǎn)，還需向所有 Follower 節(jié)點(diǎn)主動(dòng)發(fā)送心跳維持領(lǐng)導(dǎo)地位（即：保持存在感）。

所以，只要各個(gè)節(jié)點(diǎn)上的日志保持內(nèi)容和順序是一致的，那么節(jié)點(diǎn)上的狀態(tài)機(jī)就能以相同的順序執(zhí)行相同的命令，這樣它們執(zhí)行的結(jié)果也都是一樣的。

1.2 Raft 算法的三種角色及轉(zhuǎn)換

1. Follower：完全被動(dòng)，不能發(fā)送任何請(qǐng)求，只接受并響應(yīng)來自 Leader 和 Candidate 的 Message，每個(gè)節(jié)點(diǎn)啟動(dòng)后的初始狀態(tài)一般都是 Follower；

2. Leader：處理所有來自客戶端的請(qǐng)求、復(fù)制 Log 到所有 Follower，并且與 Follower 保持心跳請(qǐng)求；

3. Candidate：節(jié)點(diǎn)競選 Leader 時(shí)的狀態(tài)。Follower 節(jié)點(diǎn)在參與選舉之前，會(huì)將自己的狀態(tài)轉(zhuǎn)換為 Candidate。

1.3 任期與邏輯時(shí)鐘概念

1. 時(shí)間被劃分為多個(gè)任期 term（如同總統(tǒng)選舉一樣），term id 按時(shí)間軸單調(diào)遞增；

2. 每一個(gè)任期開始后要做的第一件事都是選舉 Leader 節(jié)點(diǎn)，選舉成功之后，Leader 負(fù)責(zé)在該任期內(nèi)管理整個(gè)分布式集群，“日志復(fù)制”、“通過心跳維護(hù)自己的角色”；

3. 每個(gè)任期至多只有一個(gè) Leader 節(jié)點(diǎn)，也可能沒有 Leader (由于“分票”導(dǎo)致)。

1.4 Raft 算法的實(shí)際應(yīng)用實(shí)現(xiàn)

目前，Raft 算法已經(jīng)成熟地應(yīng)用于諸多知名的開源項(xiàng)目中。業(yè)界非常著名的 Etcd(Kubernetes 高可用強(qiáng)一致性的服務(wù)發(fā)現(xiàn)組件)和 TiKV (高性能開源 KV 存儲(chǔ))均是 Raft 算法的實(shí)現(xiàn)。

二、BC-MQ 基于 Raft 的高可用設(shè)計(jì)

為滿足企業(yè)上云和構(gòu)建萬物相連的物聯(lián)網(wǎng)業(yè)務(wù)需求，中國移動(dòng)蘇州研發(fā)中心結(jié)合自身在云計(jì)算產(chǎn)品和技術(shù)的較多積累，研發(fā)了大云消息隊(duì)列中間件產(chǎn)品 BC-MQ。該產(chǎn)品基于 Apache 開源社區(qū)的 RocketMQ 內(nèi)核，同時(shí)結(jié)合云端 PAAS 產(chǎn)品架構(gòu)和消息中間件的應(yīng)用業(yè)務(wù)需求進(jìn)行深度優(yōu)化和定制化的研發(fā)，提供了一款可以滿足于云端場景的高性能、高可靠、低延遲和高可用的工業(yè)級(jí)產(chǎn)品。

本節(jié)從解決原有高可用技術(shù)方案的問題視角出發(fā)，同時(shí)結(jié)合選型 SOFAJRaft 庫的緣由，將詳細(xì)闡述 BC-MQ 產(chǎn)品中的安全認(rèn)證和 API 計(jì)量采集服務(wù)的高可用設(shè)計(jì)方案（注：這里不會(huì)涉及到安全認(rèn)證和 API 計(jì)量采集組件本身的技術(shù)方案細(xì)節(jié)）。

2.1 GlusterFS+Keepalived 高可用方案與問題

1. GlusterFS+Keepalived 高可用設(shè)計(jì)方案

在BC-MQ原有的方案中，多組安全認(rèn)證服務(wù)各自獨(dú)立部署組建集群，各個(gè)安全認(rèn)證服務(wù)相互獨(dú)立，沒有主從關(guān)聯(lián)，服務(wù)本身無狀態(tài)，可水平任意擴(kuò)展。安全認(rèn)證服務(wù)的高可用依賴于RPC通信的客戶端保證，其主要通過負(fù)載均衡算法從安全認(rèn)證服務(wù)集群選擇一個(gè)節(jié)點(diǎn)發(fā)送RPC請(qǐng)求來實(shí)現(xiàn)租戶級(jí)鑒權(quán)認(rèn)證元數(shù)據(jù)的獲取。在生產(chǎn)環(huán)境中，如果出現(xiàn)其中一個(gè)安全認(rèn)證節(jié)點(diǎn)宕機(jī)不可用時(shí)，客戶端的RPC通信層能夠及時(shí)感知并從本地的Node列表中剔除不可用節(jié)點(diǎn)。

集群中有狀態(tài)的租戶級(jí)安全認(rèn)證元數(shù)據(jù)的強(qiáng)一致性由GlusterFS分布式文件存儲(chǔ)的同步機(jī)制來保證。安全認(rèn)證服務(wù)組建高可用集群的具體設(shè)計(jì)方案圖如下所示：

而 BC-MQ 中 API 計(jì)量采集服務(wù)組件的高可用性則是依靠 Keepalived 組件的冷備模式結(jié)合 GlusterFS 分布式文件存儲(chǔ)的同步機(jī)制共同保證，從而在一定程度上解決了 API 計(jì)量采集服務(wù)的單點(diǎn)不可用問題。API 計(jì)量采集服務(wù)的具體高可用設(shè)計(jì)方案圖如下所示：

2. GlusterFS+Keepalived 高可用方案遇到的問題

初步看上面的這種高可用技術(shù)方案挺完美的。但是經(jīng)過驗(yàn)證和仔細(xì)推敲后就發(fā)現(xiàn)在生產(chǎn)環(huán)境中可能會(huì)存在如下幾個(gè)問題：

1. 上面所述的高可用設(shè)計(jì)方案中引入了 GlusterFS 分布式文件存儲(chǔ)系統(tǒng)和 Keepalived 組件，這增加了系統(tǒng)整體的運(yùn)維復(fù)雜度，給運(yùn)維人員帶來很多人工介入排查和部署的工作負(fù)擔(dān)；另一方面，GlusterFS 和 Keepalived 本身的可靠性、穩(wěn)定性和性能指標(biāo)等問題也需要軟件研發(fā)人員重點(diǎn)關(guān)注，這增加了系統(tǒng)整體設(shè)計(jì)的復(fù)雜度；

2. 在實(shí)際的生產(chǎn)環(huán)境中，Keepalived 組件采用冷備方式作為高可用方案需要考慮主機(jī)故障宕機(jī)后切換到備機(jī)的時(shí)間成本消耗。在這段時(shí)間內(nèi)，API 計(jì)量服務(wù)是短暫不可用的。因此，Keepalived 組件的主備切換會(huì)造成業(yè)務(wù)感知影響，導(dǎo)致一些業(yè)務(wù)的風(fēng)險(xiǎn)發(fā)生。

2.2 基于 SOFAJRaft 庫的高可用設(shè)計(jì)方案

由于“GlusterFS+Keepalived”的高可用方案存在上一節(jié)闡述的兩個(gè)問題，所以我們考慮是否可以采用其他的高可用方案來解決這兩個(gè)問題？目標(biāo)：即使生產(chǎn)環(huán)境出現(xiàn)部分節(jié)點(diǎn)故障后，安全認(rèn)證和 API 計(jì)量組件依舊能夠正常提供服務(wù)，做到業(yè)務(wù)無感知。

為了實(shí)現(xiàn)當(dāng)分布式集群中的部分節(jié)點(diǎn)出現(xiàn)故障停服后，集群仍然能夠自動(dòng)選主繼續(xù)正常對(duì)外提供服務(wù)，使得故障對(duì)外部業(yè)務(wù)不會(huì)產(chǎn)生任何影響，同時(shí)高可用方案又不能依賴外部系統(tǒng)，那我們也就想到了 Raft 算法。Raft 算法設(shè)計(jì)，簡潔易懂，沒有任何外部依賴，可以完成一個(gè)高可靠、高可用、強(qiáng)一致的數(shù)據(jù)復(fù)制系統(tǒng)，解決我們前面遇到的問題。

業(yè)界有一些 Raft 算法的實(shí)現(xiàn)，目前比較流行的主要有百度開源的Braft和螞蟻金服開源的 SOFAJRaft。從官方 Github 上對(duì)兩款開源 Raft 實(shí)現(xiàn)框架支持的功能和特性來看，基本相近，但 Braft 是 C/C++ 語言實(shí)現(xiàn)的，而 SOFAJRaft 是 JAVA 語言實(shí)現(xiàn)的，因此我們從技術(shù)棧、集成難易和運(yùn)維成本等角度綜合考慮，最終選擇了 SOFAJRaft。

1. 為何技術(shù)選型 SOFAJRaft 庫？

SOFAJRaft 是一個(gè)基于 Raft 一致性算法的生產(chǎn)級(jí)高性能 JAVA 實(shí)現(xiàn)，支持 MULTI-RAFT-GROUP，適用于高負(fù)載低延遲的場景。使用 SOFAJRaft，使用者可以更加專注于自己的業(yè)務(wù)領(lǐng)域，由 SOFAJRaft 負(fù)責(zé)處理所有與 Raft 算法相關(guān)的技術(shù)難題，并且 SOFAJRaft 比較易于使用，用戶可以通過 Github 上的幾個(gè)示例在很短的時(shí)間內(nèi)掌握并使用它。下面先簡單介紹下 SOFAJRaft 的特性和增強(qiáng)功能點(diǎn)：

其中：

1. Membership change 成員管理：集群內(nèi)成員的加入和退出不會(huì)影響集群對(duì)外提供服務(wù)。

2. Transfer leader：除了集群根據(jù)算法自動(dòng)選出 Leader 之外，還支持通過指令強(qiáng)制指定一個(gè)節(jié)點(diǎn)成為 Leader。

3. Fault tolerance 容錯(cuò)性：當(dāng)集群內(nèi)有節(jié)點(diǎn)因?yàn)楦鞣N原因不能正常運(yùn)行時(shí)，不會(huì)影響整個(gè)集群的正常工作。

4. 多數(shù)派故障恢復(fù)：當(dāng)集群內(nèi)半數(shù)以上的節(jié)點(diǎn)都不能正常服務(wù)的時(shí)候，正常的做法是等待集群自動(dòng)恢復(fù)，不過 SOFAJRaft 也提供了 Reset 的指令，可以讓整個(gè)集群立即重建。

5. Metrics：SOFAJRaft 內(nèi)置了基于 Metrics 類庫的性能指標(biāo)統(tǒng)計(jì)，具有豐富的性能統(tǒng)計(jì)指標(biāo)，利用這些指標(biāo)數(shù)據(jù)可以幫助用戶更容易找出系統(tǒng)性能瓶頸。

為了提供支持生產(chǎn)環(huán)境運(yùn)行的高性能，SOFAJRaft 主要做了如下幾部分的性能優(yōu)化，其中：

1. 并行 append log：在 SOFAJRaft 中 Leader 本地持久化 Log 和向 Follower 發(fā)送 Log 是并行的。

2. 并發(fā)復(fù)制 Leader 向所有 Follwers 發(fā)送 Log 也是完全相互獨(dú)立和并發(fā)的。

3. 異步化：SOFAJRaft 中整個(gè)鏈路幾乎沒有任何阻塞，完全異步的，是一個(gè)完全的 Callback 編程模型。

因此，綜上所述我們最終選用 SOFAJRaft 的理由如下：

1. SOFAJRaft 基于 JAVA 實(shí)現(xiàn)，能夠很方便的與 BC-MQ 中安全認(rèn)證服務(wù)和 API 計(jì)量服務(wù)組件進(jìn)行集成。

2. SOFAJRaft 作為一個(gè)實(shí)現(xiàn) Raft 協(xié)議的框架，提供了易于實(shí)現(xiàn)的狀態(tài)機(jī)接口，只需要實(shí)現(xiàn)它提供的接口即可完成高可用的改造。

3. 從實(shí)際的驗(yàn)證結(jié)果來說，SOFAJRaft 的性能和穩(wěn)定性能夠完全滿足甚至超過我們的預(yù)期。

4. SOFAJRaft 的功能性能夠解決上面篇幅中 BC-MQ 原有“GlusterFS+Keepalived”高可用方案中所遇到的問題。

2. BC-MQ 組件集成 SOFAJRaft 的優(yōu)化設(shè)計(jì)

BC-MQ在集成SOFAJRaft庫后在部署架構(gòu)、數(shù)據(jù)持久化和高可用模式上都進(jìn)行了能力升級(jí)，較好地解決了“GlusterFS+Keepalived”中的問題。

1. 部署架構(gòu)：集成SOFAJRaft庫后，BC-MQ的安全認(rèn)證和API計(jì)量服務(wù)的高可用部署不再依賴“GlusterFS+Keepalived”這兩個(gè)外部組件；安全認(rèn)證和API計(jì)量服務(wù)組件按照配置文件獨(dú)立部署組成相應(yīng)的RaftGroup即可對(duì)外提供服務(wù)；

2. 數(shù)據(jù)持久化：數(shù)據(jù)的強(qiáng)一致性不再依賴“GlusterFS分布式文件存儲(chǔ)”。通過SOFAJRaft的日志復(fù)制和狀態(tài)機(jī)，實(shí)現(xiàn)集群中Leader節(jié)點(diǎn)和Follower節(jié)點(diǎn)的數(shù)據(jù)同步保證主備節(jié)點(diǎn)的數(shù)據(jù)一致性；

3. 高可用模式：從原有的“KeepaLived冷備切換”轉(zhuǎn)變?yōu)椤癛aft自動(dòng)Leader選舉”，發(fā)生故障后，API計(jì)量服務(wù)仍然能夠?qū)ν庹Ｌ峁┓?wù)，故障轉(zhuǎn)移的過程無需運(yùn)維人員介入；

組件服務(wù)端的狀態(tài)機(jī)接口實(shí)現(xiàn)

針對(duì)具體的業(yè)務(wù)應(yīng)用而言（對(duì) BC-MQ 來說，就是 API 計(jì)量統(tǒng)計(jì)和安全認(rèn)證鑒權(quán)），狀態(tài)機(jī)（StateMachine）是業(yè)務(wù)邏輯實(shí)現(xiàn)的主要接口，狀態(tài)機(jī)運(yùn)行在每個(gè)Raft節(jié)點(diǎn)上，提交的 任務(wù) Task 如果成功，最終都會(huì)復(fù)制應(yīng)用到分布式集群中的每個(gè)節(jié)點(diǎn)的狀態(tài)機(jī)上。

在 SOFAJRaft 中提供了一個(gè)已經(jīng)具備絕大部分默認(rèn)實(shí)現(xiàn)的抽象適配類— StateMachineAdapter，直接繼承它可以使得業(yè)務(wù)應(yīng)用避免實(shí)現(xiàn)所有的接口。我們根據(jù) BC-MQ 組件改造的需求，對(duì)部分接口做了如下的實(shí)現(xiàn)：

1. void onApply(Iterator iter)：該方法是 SOFAJRaft 中最為核心的接口。在整個(gè)分布式集群環(huán)境中，待同步的數(shù)據(jù)會(huì)封裝成 LogEntry 復(fù)制到其他節(jié)點(diǎn)。在數(shù)據(jù)同步完成之后，進(jìn)程會(huì)提交到自身狀態(tài)機(jī)的這個(gè)方法中執(zhí)行。在 BC-MQ 中，API 計(jì)量采集服務(wù)在計(jì)量統(tǒng)計(jì)數(shù)據(jù)日志同步至 Follower 節(jié)點(diǎn)后，SOFAJRaft 在業(yè)務(wù)狀態(tài)機(jī)的 onApply 方法中調(diào)用 API 計(jì)量采集服務(wù)組件的存儲(chǔ)接口進(jìn)行持久化。

2. void onLeaderStart(long term)/void onLeaderStop(Status status)：這個(gè)兩個(gè)方法是在節(jié)點(diǎn)通過選舉成為 Leader 和失去 Leader 資格時(shí)調(diào)用，BC-MQ 的安全認(rèn)證和 API 計(jì)量服務(wù)組件本身也維護(hù)了 Raft 的角色狀態(tài)（這里的角色狀態(tài)與 SOFAJRaft 本身的是保持一致的）。在節(jié)點(diǎn)的角色發(fā)生轉(zhuǎn)變的時(shí)候，需要調(diào)用這個(gè)方法，將組件的角色和狀態(tài)轉(zhuǎn)變一致。這樣實(shí)現(xiàn)主要是與 BC-MQ 的業(yè)務(wù)場景相關(guān)，在集群中經(jīng)過重新選舉后節(jié)點(diǎn)角色轉(zhuǎn)變時(shí)，只有API 計(jì)量組件服務(wù)的 Leader 節(jié)點(diǎn)才能夠執(zhí)行消息隊(duì)列的 API 計(jì)量采集相關(guān)的定時(shí)任務(wù)。

3. void onSnapshotSave(SnapshotWriter writer, Closure done)/boolean onSnapshotLoad(SnapshotReader reader)：這兩個(gè)方法是 SOFAJRaft 快照相關(guān)的接口調(diào)用，快照本身的作用就是在有新的節(jié)點(diǎn)加入到 SOFAJRaft Group 時(shí)，不需要加載全部的 Log 日志數(shù)據(jù)，而只需要從最近的 index 開始加載，這可以節(jié)省從 Leader 節(jié)點(diǎn)同步大量日志信息所造成的網(wǎng)絡(luò)通信開銷。BC-MQ 的安全認(rèn)證和 API 計(jì)量采集服務(wù)組件實(shí)現(xiàn)了這兩個(gè)方法，用于實(shí)現(xiàn)快照的特性。

客戶端請(qǐng)求重定向機(jī)制優(yōu)化

SOFAJRaft 中默認(rèn)只有 Leader 節(jié)點(diǎn)能夠被客戶端訪問到，所有的日志提交都需要先提交到集群的 Leader 節(jié)點(diǎn)，然后由Leader節(jié)點(diǎn)同步到其他的 Follower 節(jié)點(diǎn)。BC-MQ 的安全認(rèn)證服務(wù)和 API 計(jì)量服務(wù)組件通過 SOFAJRaft 改造后，在 BC-MQ 中原有的客戶端 RPC 請(qǐng)求訪問方式也需要經(jīng)過一些優(yōu)化設(shè)計(jì)，為了讓客戶端能夠?qū)崟r(shí)感知到分布式集群環(huán)境中當(dāng)前的 Leader 節(jié)點(diǎn)，因此需要在客戶端緩存一個(gè)集群的節(jié)點(diǎn)列表 NodeList 和 LeaderId。

僅僅在客戶端維護(hù)一個(gè)本地緩存還不夠，因?yàn)槿绻褐械?Leader 節(jié)點(diǎn)出現(xiàn)了宕機(jī)的故障時(shí)，集群會(huì)發(fā)生重新選舉，那么客戶端緩存的 Leader 節(jié)點(diǎn)信息就會(huì)過期，這就需要客戶端就能夠感知到 Leader 節(jié)點(diǎn)的變化。為解決這個(gè)問題，我們采用了 RPC 請(qǐng)求重定向機(jī)制來保證，一旦RPC請(qǐng)求發(fā)送到了集群中的 Follower 節(jié)點(diǎn)，那么 Follower 會(huì)將該請(qǐng)求重定向到 Leader。以下為 BC-MQ 客戶端通信重定向機(jī)制優(yōu)化設(shè)計(jì)圖：

三、BC-MQ 的高可用與節(jié)點(diǎn)管理性驗(yàn)證

下面展示的是 BC-MQ 的安全認(rèn)證服務(wù)和 API 計(jì)量服務(wù)組件的部分測試用例，從用例的實(shí)際執(zhí)行情況來看，與我們的預(yù)期結(jié)果完全一致可以滿足生產(chǎn)環(huán)境高可用的業(yè)務(wù)場景。

序號(hào)	具體業(yè)務(wù)場景	預(yù)期結(jié)果	實(shí)際結(jié)果
1	安全認(rèn)證組件3節(jié)點(diǎn)部署，Kill掉其中1個(gè)節(jié)點(diǎn)，客戶端持續(xù)發(fā)布/訂閱帶鑒權(quán)的消息	安全認(rèn)證組件Leader角色轉(zhuǎn)換，客戶端發(fā)布/訂閱帶鑒權(quán)消息無任何影響	與預(yù)期一致
2	安全認(rèn)證的5節(jié)點(diǎn)部署，Kill掉其中2個(gè)節(jié)點(diǎn)，客戶端持續(xù)發(fā)布/訂閱帶鑒權(quán)的消息	安全認(rèn)證組件Leader角色轉(zhuǎn)換，客戶端發(fā)布/訂閱帶鑒權(quán)消息無任何影響	與預(yù)期一致
3	API計(jì)量組件3節(jié)點(diǎn)部署，Kill掉其1個(gè)節(jié)點(diǎn)，客戶端持續(xù)；發(fā)布/訂閱帶鑒權(quán)的消息	API計(jì)量組件Leader角色轉(zhuǎn)換，輸出的API計(jì)量文件正確	與預(yù)期一致
4	API計(jì)量組件5節(jié)點(diǎn)部署，Kill掉其2個(gè)節(jié)點(diǎn)，客戶端持續(xù)發(fā)布/訂閱帶鑒權(quán)的消息	API計(jì)量組件Leader角色轉(zhuǎn)換，輸出的API計(jì)量文件正確	與預(yù)期一致
5	在集群中模擬出現(xiàn)網(wǎng)絡(luò)分區(qū)（對(duì)稱/非對(duì)稱）的場景，安全認(rèn)證服務(wù)集群是否會(huì)出現(xiàn)腦裂現(xiàn)象，鑒權(quán)認(rèn)證數(shù)據(jù)是否正確	網(wǎng)絡(luò)分區(qū)（對(duì)稱/非對(duì)稱）場景下，集群不會(huì)出現(xiàn)腦裂，并且鑒權(quán)數(shù)據(jù)是正確的	與預(yù)期一致
6	在集群中模擬出現(xiàn)網(wǎng)絡(luò)分區(qū)（對(duì)稱/非對(duì)稱）的場景，API計(jì)量服務(wù)集群是否會(huì)出現(xiàn)腦裂現(xiàn)象，API計(jì)量數(shù)據(jù)是否正確	網(wǎng)絡(luò)分區(qū)（對(duì)稱/非對(duì)稱）場景下，集群不會(huì)出現(xiàn)腦裂，并且API計(jì)量數(shù)據(jù)是正確的	與預(yù)期一致
7	在3節(jié)點(diǎn)組成的安全認(rèn)證服務(wù)集群的負(fù)載工作的場景下，向該RaftGroup添加1/2節(jié)點(diǎn)，客戶端持續(xù)發(fā)布/訂閱帶鑒權(quán)的消息	客戶端發(fā)布/訂閱帶鑒權(quán)消息無任何影響	與預(yù)期一致
8	在5節(jié)點(diǎn)組成的安全認(rèn)證服務(wù)集群的負(fù)載工作的場景下，移除該RaftGroup中的1/2節(jié)點(diǎn)，客戶端持續(xù)發(fā)布/訂閱帶鑒權(quán)的消息	客戶端發(fā)布/訂閱帶鑒權(quán)消息無任何影響	與預(yù)期一致

感謝各位的閱讀，以上就是“怎么使用SOFAStack”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)怎么使用SOFAStack這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

當(dāng)前標(biāo)題：怎么使用SOFAStack
當(dāng)前網(wǎng)址：http://vcdvsql.cn/article14/jhjjge.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供標(biāo)簽優(yōu)化、商城網(wǎng)站、定制網(wǎng)站、虛擬主機(jī)、品牌網(wǎng)站制作、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)