2022年系統(tǒng)分析師案例真題及答案解析試題一(共25分)閱讀以下關(guān)于軟件系統(tǒng)分析與建模的敘述，在答題紙上回答問題1至問題3o某軟件公司擬開發(fā)一套博客系統(tǒng)，要求能夠向用戶提供一個(gè)便捷發(fā)布自已心得，及時(shí)有效的與他人進(jìn)行交流的平臺(tái)。新用戶發(fā)布個(gè)人博客之前，需要?jiǎng)?chuàng)建一個(gè)新的博客賬戶，以下為新用戶注冊的操作行為：Q)向系統(tǒng)請求創(chuàng)建一個(gè)新的博客賬戶；輸入個(gè)人詳細(xì)信息：使用證件數(shù)據(jù)庫驗(yàn)證個(gè)人詳細(xì)信息；選擇賬戶類型；身份驗(yàn)證成功，創(chuàng)建新的博客賬戶；用戶身份信息驗(yàn)證不成功：以電子郵件的方式將賬戶詳細(xì)信息發(fā)送給用戶；博客賬戶申請被拒絕。問題1(6分)在結(jié)構(gòu)化和面向?qū)ο蟮能浖治鲞^程中，通常會(huì)使用到數(shù)據(jù)流圖、活動(dòng)圖和流程圖，請分別描述這三種模型的特點(diǎn)和適用場景。問題2(9分)采用用例圖和用例描述建模系統(tǒng)需求，請使用題干給出的(a)?(h),完善"博客賬戶創(chuàng)建用例描述”中的(1)?(6),如表1-1所示。將正確答案填在答題紙上。表1-1博客賬戶創(chuàng)建用例描述用例名稱創(chuàng)建一個(gè)新的博客賬戶相關(guān)的需求新用戶的個(gè)人資料通過證件數(shù)據(jù)庫驗(yàn)證成功后,CMS系統(tǒng)將允許用戶創(chuàng)建一個(gè)新的博客賬戶.上下文目標(biāo)新用戶請求創(chuàng)建一個(gè)新的博客賬戶前置條件新用戶具有真實(shí)有效的身份證明成功的結(jié)束條件為新用戶創(chuàng)建博客賬戶失敗的結(jié)束條件創(chuàng)建博客賬戶的申請被拒絕主要參與者新用戶次要參與者作者證件數(shù)據(jù)庫觸發(fā)器新用戶向CMS請求建立個(gè)新的博客賬戶基本流程步驟1(1)2(2)3(3)4(4)5身份驗(yàn)證成功，創(chuàng)建新的博客賬戶6(5)擴(kuò)展流程1用戶身份信息驗(yàn)證不成功2⑹問題3（10分）需求評(píng)審是通過將需求規(guī)格說明書遞交給相關(guān)人員檢查，以發(fā)現(xiàn)其中存在缺陷的過程。在需求工程中，需求評(píng)審是一個(gè)非常重要的過程。結(jié)合題干案例，請用300字以內(nèi)的文字簡要說明需求評(píng)審的內(nèi)容及作用。（試題二至試題五選答二個(gè)）試題二（共25分）閱讀以下關(guān)于系統(tǒng)設(shè)計(jì)的敘述，在答題紙上回答問題1至問題3o某軟件公司為某企業(yè)開發(fā)一套在線辦公自動(dòng)化系統(tǒng)，以提升企業(yè)管理服務(wù)的質(zhì)量和效率。公司決定采用面向?qū)ο蠓椒ㄩ_發(fā)該系統(tǒng)，張工負(fù)責(zé)對員工請假審批業(yè)務(wù)進(jìn)行了分析，具體描述如下：企業(yè)員工通過請假申請頁面提出請假申請后，首先由部門經(jīng)理進(jìn)行審核，若請假理由不合理,部門經(jīng)理拒絕請假申請，將申請退回給員工，員工對請假申請表進(jìn)行修改再次提交，或放棄請假申請。若請假理由合理，且請假天數(shù)小于等于3天，則部門經(jīng)理直接批準(zhǔn)請假申請，生成請假批準(zhǔn)單，申請結(jié)束。若請假天數(shù)大于3天，則在部門經(jīng)理批準(zhǔn)請假申請后，需要提交給副總經(jīng)理審核批準(zhǔn)。副總經(jīng)理若認(rèn)為該申請合理，則審核通過，生成請假批準(zhǔn)單，流程結(jié)束；若副總經(jīng)理認(rèn)為申請不合理，則拒絕請假申請，將請假申請退回給員工。問題1（11分）識(shí)別設(shè)計(jì)類是面向?qū)ο笤O(shè)計(jì)過程中的重要環(huán)節(jié)之一，設(shè)計(jì)類表達(dá)了類的職責(zé)，即該類所承擔(dān)的任務(wù)。請用300字以內(nèi)的文字說明設(shè)計(jì)類通常包含哪3種類型，以及每種類型的主要職責(zé)，并從題干描述案例涉及的具體類為每種類型的設(shè)計(jì)類舉出兩個(gè)實(shí)例。問題2（6分）識(shí)別類之間的關(guān)系是面向?qū)ο蠓治鲞^程中的重要環(huán)節(jié)之一，常見的類之間關(guān)系包括泛化關(guān)系、關(guān)聯(lián)關(guān)系、聚合關(guān)系、組合關(guān)系等。請用300字以內(nèi)的文字對泛化關(guān)系和關(guān)聯(lián)關(guān)系的內(nèi)涵進(jìn)行描述，并根據(jù)題干具體類的描述為這兩種關(guān)系各舉出一種實(shí)例。問題3（8分）在面向?qū)ο蟮脑O(shè)計(jì)過程中，狀態(tài)圖描述了一個(gè)實(shí)體基于事件反應(yīng)的動(dòng)態(tài)行為。請根據(jù)題干描試題三（共25分）閱讀以下關(guān)于基于模型的系統(tǒng)工程方法的描述，在答題紙上回答問題1至問題3。某公司長期從事宇航系統(tǒng)的研制任務(wù)。隨著宇航系統(tǒng)能力的不斷提升，軟件的規(guī)模急劇增加,對應(yīng)的缺陷密度呈現(xiàn)出兒何增長，失效問題越來越嚴(yán)重。為了保證產(chǎn)品的質(zhì)量，公司領(lǐng)導(dǎo)要求在重點(diǎn)項(xiàng)目中實(shí)施基于模型的系統(tǒng)工程（MBSE）。由于輔助動(dòng)力控制系統(tǒng)關(guān)系著飛行器的飛行安全，有必要作為試點(diǎn)工程首先實(shí)施MBSE方法。王工作為安該系統(tǒng)的主要負(fù)責(zé)人，承擔(dān)起了此項(xiàng)工作。問題1（10分）王工以前一直負(fù)責(zé)用傳統(tǒng)開發(fā)方法進(jìn)行系統(tǒng)設(shè)計(jì)，深知基于文本的系統(tǒng)設(shè)計(jì)方式存在天然的局限性。王工接到指示后，研究fMBSE的相關(guān)理論基礎(chǔ)和工程實(shí)現(xiàn)方法，提出了用\IBSE方法設(shè)計(jì)輔助動(dòng)力控制系統(tǒng)的實(shí)施方案。請用300字以內(nèi)的文字說明什么是MBSE方法，并列舉出三個(gè)基于文本設(shè)計(jì)方式的局限性。問題2(9分)MBSE的核心技術(shù)是模型方法論，王工對目前主流建模方法Harmony-SE(harmonyforSystemEngineering)方法、RUP-SE(RationalUnifiedProcessforSystem)方法和VitechMBSE方法進(jìn)行了分析、對比，鑒于該系統(tǒng)具備安全攸關(guān)系統(tǒng)的特殊性，強(qiáng)調(diào)驗(yàn)證的有效性，王工認(rèn)為Harmony-SE方法比較適合宇航環(huán)境開發(fā)。圖3-1給出了Hannony-SE方法的產(chǎn)品生命周期結(jié)構(gòu)。請根據(jù)以下三種有關(guān)建模方式的描述，判定哪種描述是Harmony-SE方法的正確說明？并簡要說明王工在本項(xiàng)目中選擇Harmony-SE方法的理由。描述1：一種面向?qū)ο蟮脑O(shè)計(jì)方法，可以將設(shè)計(jì)工作按照角色、工件和任務(wù)類型進(jìn)行分解,生成新的分解結(jié)構(gòu)，實(shí)現(xiàn)并行設(shè)計(jì)與迭代開發(fā)。描述2：系統(tǒng)模型貫穿系統(tǒng)研發(fā)的整個(gè)生命周期，能夠較好處理復(fù)雜與整體問題。描述3：—種并行系統(tǒng)工程活動(dòng)，由四個(gè)基本系統(tǒng)工程活動(dòng)組而成，這四種活動(dòng)通過公共系統(tǒng)設(shè)計(jì)庫相關(guān)聯(lián)。圖3-1Harmony-SE建模方法的全產(chǎn)品生命周期問題3(6分)MBSE方法可以通過軟硬件建模來預(yù)先評(píng)估系統(tǒng)的可靠性。王工帶領(lǐng)項(xiàng)目成員針對其負(fù)責(zé)的輔助動(dòng)力控制系統(tǒng)中的進(jìn)排氣門控制器組件開展了基于MBSE系統(tǒng)分析工作。圖3-2給出了進(jìn)排氣門控制器的可靠性分布圖。

王工指出：系統(tǒng)是由軟碩件組成，以往考慮可靠性指標(biāo)僅僅關(guān)注硬件失效問題，而不考慮軟件失效對系統(tǒng)可靠性的影響。如果不考慮軟件失效對系統(tǒng)可靠性的影響，本系統(tǒng)可靠性的MTTF（MeanTimeToFailure,平均失效前時(shí)間）應(yīng)該為125.9h（參考公式）:異治+占話+詁。嘶曲心異治+占話+詁。嘶曲心請對照圖3-3給出的考慮軟件失效情況下的系統(tǒng)可靠性分布圖（這里，假設(shè)SYS1軟件非?？煽?，系統(tǒng)僅僅將圈中的軟件可靠性加入系統(tǒng)可靠性的評(píng)估過程），說明此時(shí)的系統(tǒng)可靠性應(yīng)大于還是小于不考慮軟件失效的MTTF?并計(jì)算出此時(shí)的系統(tǒng)可靠性（MTTF）是多少？、nr%、nr%圖3.3勺堆軟件失效借況下的系統(tǒng)可轎性分布圖試題四（共25分）閱讀以下關(guān)于微服務(wù)架構(gòu)中的數(shù)據(jù)管理的敘述，在答題紙上回答問題1至問題3o某大型電商平臺(tái)構(gòu)建了一個(gè)在線B2B商店系統(tǒng)。該系統(tǒng)采用微服務(wù)架構(gòu)，將系統(tǒng)功能分解為多個(gè)松散耦合且可獨(dú)立部署的較小組件或服務(wù)。最終設(shè)計(jì)的系統(tǒng)包括了電商系統(tǒng)中常見的服務(wù)：客戶服務(wù)、訂單服務(wù)、支付服務(wù)等，其中：客戶服務(wù)負(fù)責(zé)對客戶相關(guān)的信息進(jìn)行管理和維護(hù)；訂單服務(wù)負(fù)責(zé)對訂單信息的管理和維護(hù)：支付服務(wù)負(fù)責(zé)對在線支付功能和信息的管理和維護(hù)等。為了確保微服務(wù)之間的松耦合，每個(gè)服務(wù)都有自己的數(shù)據(jù)庫，其中訂單服務(wù)使用了NoSQL數(shù)據(jù)庫，客戶服務(wù)和支付服務(wù)使用了關(guān)系數(shù)據(jù)庫。李工認(rèn)為由于不同服務(wù)使用了各自的不同數(shù)據(jù)庫，使得跨服務(wù)操作可能存在數(shù)據(jù)不-致。比如訂單與支付的數(shù)據(jù)?致性問題，系統(tǒng)通過訂單服務(wù)在本地NoSQL數(shù)據(jù)庫中創(chuàng)建訂單記錄,同時(shí)在支付服務(wù)的關(guān)系數(shù)據(jù)庫中創(chuàng)建支付記錄，且必須保證訂單記錄和支付記錄的?致性,該問題在系統(tǒng)構(gòu)建時(shí)需要考慮。問題1（7分）李工建議采用兩階段提交協(xié)議（2PC）來解決服務(wù)數(shù)據(jù)的一致性問題。請用200字以內(nèi)的文字簡要說明2PC；說明2PC是否能解決該問題，并簡要解釋原因。問題2（8分）王工建議采用分布式數(shù)據(jù)管理方案，用事件驅(qū)動(dòng)架構(gòu)來解決服務(wù)數(shù)據(jù)的一致性問題，在訂單服務(wù)和支付服務(wù)之間通過可靠的消息隊(duì)列實(shí)現(xiàn)事件的傳遞，其基本操作步驟如下，請?zhí)顚懫渲械目瞻滋帯＃?） 訂單服務(wù)接收訂購請求，創(chuàng)建一個(gè)訂單，該記錄狀態(tài)為（a）,發(fā)布一個(gè)“創(chuàng)建訂單”事件；（2） （b）接收“創(chuàng)建訂單”事件，記錄（c）,發(fā)布一個(gè)“支付完成事件；（3） 訂單服務(wù)接收“支付完成”事件，修改訂單記錄狀態(tài)為（d）<>問題3（10分）李工提出王工的方案會(huì)有數(shù)據(jù)庫更新和發(fā)布事件的原子性問題，例如訂單服務(wù)創(chuàng)建訂單記錄和發(fā)布“創(chuàng)建訂單”事件需要原子性保障，否則會(huì)出現(xiàn)數(shù)據(jù)不一致狀態(tài)。王工認(rèn)為可以使用本地事務(wù)發(fā)布事件的方法來解決該問題。請給出使用本地事務(wù)發(fā)布事件的基本方法，并說明該方法的缺點(diǎn)。試題五（共25分）閱讀以下關(guān)于web系統(tǒng)設(shè)計(jì)的敘述，在答題紙上回答問題1至問題3。某公司擬開發(fā)一個(gè)食品供應(yīng)鏈溯源系統(tǒng)，該系統(tǒng)需要提供從原材料供應(yīng)商、加工商、物流、分銷商、零售商、消費(fèi)者的食品供應(yīng)鏈全流程溯源。該公司組建了項(xiàng)目組，并召開了項(xiàng)目開發(fā)討論會(huì)。會(huì)上，張工提出通過二維碼掃描獲取食品信息，采用中心化數(shù)據(jù)庫作為數(shù)據(jù)存儲(chǔ)媒介；李工提出使用中心化數(shù)據(jù)庫容易產(chǎn)生數(shù)據(jù)信任、溯源追責(zé)困難等問題，建議建立區(qū)塊鏈和數(shù)據(jù)庫的映射存儲(chǔ)，提供存儲(chǔ)和查詢操作功能，并提出采用數(shù)據(jù)接入層、數(shù)據(jù)核心層、應(yīng)用表示層三層體系架構(gòu)實(shí)現(xiàn)該食品溯源系統(tǒng)。問題1（6分）去中心化和開放性是區(qū)塊鏈的重要特征，請用200字以內(nèi)的文字簡要說明什么是區(qū)塊鏈的去中心化和開放性。問題2（7分）

分布式交易賬本、哈希散列函數(shù)、公私鑰簽名、時(shí)間戳就是區(qū)塊鏈的核心技術(shù)，請從上述技術(shù)中選擇兩種最適合解決數(shù)據(jù)信任問題的技術(shù)，并用300字以內(nèi)的文字說明原因。問題3(12分)根據(jù)李工的建議，該系統(tǒng)將采用三層架構(gòu)。請從下面給出的(a)?(m)候選項(xiàng)中進(jìn)行選擇,補(bǔ)充完善圖5-1中(1)?(6)處空白的內(nèi)容，完成該系統(tǒng)的架構(gòu)設(shè)計(jì)方案。溯源查詢網(wǎng)頁微信溯源小程序Node.js；(5)(2):(1)傳感器網(wǎng)絡(luò)數(shù)據(jù)上傳APP食品供應(yīng)鏈溯源系統(tǒng)架構(gòu)圖5-1web3.js生長壞境數(shù)據(jù)數(shù)據(jù)接入層(b)智能合約(c)Socket(d)4G/Wifi應(yīng)用表示層(f)數(shù)據(jù)庫溯源查詢網(wǎng)頁微信溯源小程序Node.js；(5)(2):(1)傳感器網(wǎng)絡(luò)數(shù)據(jù)上傳APP食品供應(yīng)鏈溯源系統(tǒng)架構(gòu)圖5-1web3.js生長壞境數(shù)據(jù)數(shù)據(jù)接入層(b)智能合約(c)Socket(d)4G/Wifi應(yīng)用表示層(f)數(shù)據(jù)庫(g)MVC(h)數(shù)據(jù)核心層傳感器網(wǎng)絡(luò)(j)區(qū)塊鏈網(wǎng)絡(luò)(k)4G/Wifi(1)JDBC業(yè)務(wù)邏輯層2022年上半年系統(tǒng)分析師上午真題及答案解析試題一(共25分)問題1(6分)數(shù)據(jù)流圖：特點(diǎn)：是表達(dá)系統(tǒng)內(nèi)數(shù)據(jù)的流動(dòng)并通過數(shù)據(jù)流描述系統(tǒng)功能數(shù)據(jù)的一種方法。強(qiáng)調(diào)系統(tǒng)中的數(shù)據(jù)流動(dòng)。由數(shù)據(jù)流、外部實(shí)體、加工、數(shù)據(jù)存儲(chǔ)組成。適用場景：SA方法中的重要工具，為系統(tǒng)做功能建模?；顒?dòng)圖：特點(diǎn)：將進(jìn)程或其他計(jì)算結(jié)構(gòu)展示為計(jì)算內(nèi)部一步步的控制流和數(shù)據(jù)流。活動(dòng)圖專注于系統(tǒng)的動(dòng)態(tài)視圖。它對系統(tǒng)的功能建模和業(yè)務(wù)流程建模特別重要，并強(qiáng)調(diào)對象間的控制流程。適用場景：面向?qū)ο蠓治雠c設(shè)計(jì)建模。流程圖：特點(diǎn)：反映現(xiàn)有系統(tǒng)各部門的業(yè)務(wù)處理過程和它們之間的業(yè)務(wù)分工與聯(lián)系，以及連接各部門的物流、信息流的傳遞和流動(dòng)關(guān)系。是描述業(yè)務(wù)處理過程的方法。適用場景：結(jié)構(gòu)化需求分析與結(jié)構(gòu)化設(shè)計(jì)，為系統(tǒng)梳理業(yè)務(wù)流程。問題2(9分)(a) (2)(d) (3)(b) (4)(c) (5)(g) (6)(h)問題3(10分)1?需求評(píng)審的內(nèi)容：需求規(guī)格說明書正確地描述了預(yù)期的、滿足項(xiàng)目干系人需求的系統(tǒng)行為和特征。需求規(guī)格說明書中的軟件需求是從系統(tǒng)需求、業(yè)務(wù)規(guī)格和其他來源中正確推導(dǎo)而來的。需求是完整的和高質(zhì)量的。需求的表示在所有地方都是一致的。需求為繼續(xù)進(jìn)行系統(tǒng)設(shè)計(jì)、實(shí)現(xiàn)和測試提供了足夠的基礎(chǔ)。需求評(píng)審的作用發(fā)現(xiàn)遺漏的需求；發(fā)現(xiàn)用戶沒有達(dá)成共識(shí)的需求；發(fā)現(xiàn)二義性需求；降低因需求不一致帶來的風(fēng)險(xiǎn)，提高軟件質(zhì)量。試題二(共25分)問題1(11分)實(shí)體類：實(shí)體對象的抽象，通常來自域模型(現(xiàn)實(shí)世界)，用來描述具體的實(shí)體，通常映射到數(shù)據(jù)庫表格與文件中。案例中的員工、請假單是實(shí)體類。邊界類：邊界對象的抽象，通常是用來完成參與者(用戶、外部系統(tǒng))與系統(tǒng)之間交互的對象，例如：From、對話框、菜單、接口等。案例中的請假申請頁面，請假批準(zhǔn)單是邊界類?？刂祁悾嚎刂茖ο蟮某橄?，主要用來體現(xiàn)應(yīng)用程序的執(zhí)行邏輯，將其抽象出來，可以使變化不影響用戶界面和數(shù)據(jù)庫中的表。案例中的提交請假、審核批準(zhǔn)是控制類。問題2（6分）泛化描述了一般元素和特殊元素之間的關(guān)系，是父類和子類之間的關(guān)系。員工，部門經(jīng)理的關(guān)系就是泛化關(guān)系。關(guān)聯(lián)關(guān)系描述了給定類的單獨(dú)對象之間語義上的連接。關(guān)聯(lián)提供了不同類之間的對象可以相互作用的連接。員工與請假記錄之間的關(guān)系就是關(guān)聯(lián)關(guān)系。問題3（8分）@）部門經(jīng)理拒絕請假申請 （b）請假天數(shù)大于3天（c）副總經(jīng)理拒絕請假申請 （d）請假天數(shù)小于等于3天試題三（共25分）問題1（10分）基于模型的系統(tǒng)工程（MBSE）是一種形式化的方法，用于支持與復(fù)雜系統(tǒng)的開發(fā)相關(guān)的需求，設(shè)計(jì)，分析，驗(yàn)證和確認(rèn)。與以文檔為中心的工程，MBSE將模型放在系統(tǒng)設(shè)計(jì)的中心。MBSE是向以模型為中心的一系列方法轉(zhuǎn)變這一長期趨勢的一部分，這些方法被應(yīng)用于機(jī)械、電子和軟件等工程領(lǐng)域，以期望取代原來系統(tǒng)工程師們所擅長的以文檔為中心的方法，并通過完全融入系統(tǒng)工程過程來影響未來系統(tǒng)工程的實(shí)踐?；谖臋n的設(shè)計(jì)方法的局限性主要有：（1） 在基于文檔的方法中，許多文檔是由不同的作者生成的，以從各種利益相關(guān)者的觀點(diǎn)（例如系統(tǒng)行為，軟件，硬件，安全，安全性或其他學(xué)科）中捕獲系統(tǒng)的設(shè)計(jì)。不利于利益相關(guān)者之間的溝通，容易產(chǎn)生歧義。（2） 開發(fā)復(fù)雜系統(tǒng)的能力有限，基于文本的設(shè)計(jì)方案無法進(jìn)行前期仿真驗(yàn)證。（3） 自然語言容易引入形容詞等模糊描述，很難保證準(zhǔn)確性。問題2（9分）正確的描述是“描述2”。描述1是對RUP-SE方法的描述。描述3是對vitechMBSE方法的描述。根據(jù)王工對MBSE的研究，RUP-SE是一種面向?qū)ο蟮脑O(shè)計(jì)方法，vitechMBSE方法是一種并行系統(tǒng)，并不滿足宇航系統(tǒng)所要求的髙安全性和強(qiáng)調(diào)驗(yàn)證性的要求。而Harmony-SE建模方法是貫穿系統(tǒng)研發(fā)的整個(gè)生命周期，用于支持與復(fù)雜系統(tǒng)的開發(fā)相關(guān)的需求、設(shè)計(jì)、分析、驗(yàn)證和確認(rèn)。符合宇航系統(tǒng)所描述的安全性和驗(yàn)證性的要求。問題3（6分）（1） 小于不考慮軟件失效的MTTFo（2） 系統(tǒng)可靠性的計(jì)算如下：1/280+1/（5.01*10*4）+1/10*4+1/600+1/387+（1/0.3968+1/0.3968）=0.007942+（1/0.3968+1/0.3968）二0.007942+2/0.3968=0.007942+5.040322=5.048264（1/h）所以系統(tǒng)的可靠性為：1/5.048264=0.1980879H。試題四（共25分）問題1（7分）兩階段提交協(xié)議（2PC）可以保證數(shù)據(jù)的強(qiáng)一致性，許多分布式關(guān)系型數(shù)據(jù)管理系統(tǒng)釆用此協(xié)議來完成分布式事務(wù)。它是協(xié)調(diào)所有分布式原子事務(wù)參與者，并決定提交或取消（回滾）的分布式算法。同時(shí)也是解決一致性問題的一致性算法。兩階段提交協(xié)議由兩個(gè)階段組成。（1） 階段1：請求階段（prepare階段，或稱表決階段）在請求階段，協(xié)調(diào)者將通知事務(wù)參與者準(zhǔn)備提交或取消事務(wù)，然后進(jìn)入表決過程。在表決過程中，參與者將告知協(xié)調(diào)者自己的決策：同意（事務(wù)參與者本地作業(yè)執(zhí)行成功）或取消（本地作業(yè)執(zhí)行故障）。（2） 階段2：提交階段（commit階段）在該階段，協(xié)調(diào)者將基于第一個(gè)階段的投票結(jié)果進(jìn)行決策：提交或取消。當(dāng)且僅當(dāng)所有的參與者同意提交事務(wù)協(xié)調(diào)者才通知所有的參與者提交事務(wù)，否則協(xié)調(diào)者將通知所有的參與者取消事務(wù)。參與者在接收到協(xié)調(diào)者發(fā)來的消息后將執(zhí)行響應(yīng)的操作。兩階段提交協(xié)議2PC不能解決當(dāng)前問題。（1） 分布式數(shù)據(jù)庫遵循的是CAP原則，會(huì)在一定程度上犧牲一致性。（2） 大多數(shù)NoSQL數(shù)據(jù)庫并不支持2PC。（3） 分布式兩階段提交協(xié)議2PC—般針對的對象在邏輯上是一個(gè)整體，對某一個(gè)整體事務(wù)需要在多個(gè)物理節(jié)點(diǎn)上執(zhí)行時(shí)，進(jìn)行表決和執(zhí)