● 閱讀以下關(guān)于嵌入式實(shí)時(shí)系統(tǒng)相關(guān)技術(shù)的敘述，在答題紙上回答問題1和問題2。

【說明】

某公司長(zhǎng)期從事宇航領(lǐng)域嵌入式實(shí)時(shí)系統(tǒng)的軟件研制任務(wù)。公司為了適應(yīng)未來嵌入式系統(tǒng)網(wǎng)絡(luò)化、智能化和綜合化的技術(shù)發(fā)展需要，決定重新考慮新產(chǎn)品的架構(gòu)問題，經(jīng)理將論證工作交給王工負(fù)責(zé)。王工經(jīng)調(diào)研和分析，完成了新產(chǎn)品架構(gòu)設(shè)計(jì)方案，提交公司高層討論。

【問題1】 （14分）

王工提交的設(shè)計(jì)方案中指出：由于公司目前研制的嵌入式實(shí)時(shí)產(chǎn)品屬于簡(jiǎn)單型系統(tǒng)，其嵌入式子系統(tǒng)相互獨(dú)立，功能單一，時(shí)序簡(jiǎn)單。而未來滿足網(wǎng)絡(luò)化、智能化和綜合化的嵌入式實(shí)時(shí)系統(tǒng)將是一種復(fù)雜系統(tǒng)，其核心特征體現(xiàn)為實(shí)時(shí)任務(wù)的機(jī)理、狀態(tài)和行為的復(fù)雜性。簡(jiǎn)單任務(wù)和復(fù)雜任務(wù)的特征區(qū)分主要表現(xiàn)在十個(gè)方面。請(qǐng)參考表3-1給出的實(shí)時(shí)任務(wù)特征分類，用題干中給出的（a）~（t）20個(gè)實(shí)時(shí)任務(wù)特征描述，補(bǔ)充完善表3-1給出的空（1）~（14）。

（a）任務(wù)屬性不會(huì)隨時(shí)間變化而改變；

（b）任務(wù)的屬性與時(shí)間相關(guān)；

（c）任務(wù)僅可以從非連續(xù)集中獲取特征變量；

（d）任務(wù)變量域是連續(xù)的；

（e）功能原理不依賴于上下文；

（f） 功能原理依賴于上下文；

（g）任務(wù)行為可以用step-by-step順序分析方法來理解；

（h）許多任務(wù)在產(chǎn)生訪問活動(dòng)時(shí)相互間是并發(fā)處理的，很難用step-by-step方法分析；

（i） 因果關(guān)系相互影響；

（j） 行為特征依賴于大量的反饋機(jī)制；

（k）系統(tǒng)內(nèi)構(gòu)成、策略和描述是相似的；

（l） 系統(tǒng)內(nèi)存在許多不同的構(gòu)成、策略和描述；

（m）功能關(guān)系是非線性的；

（n） 功能關(guān)系是線性的；

（o） 不同的子任務(wù)是相互獨(dú)立的，任務(wù)內(nèi)部?jī)H存在少量的交互操作；

（p） 不同的子任務(wù)有很高的交互操作，要把一個(gè)單任務(wù)的行為隔離開是困難的；

（q） 域特征有非常整齊的原則和規(guī)則；

（r）  許多不同的上下文依賴于規(guī)則；

（s）  原理和規(guī)則在表面屬性上很容易被識(shí)別；

（t）   原理被覆蓋、抽象，而不會(huì)在表面屬性上被識(shí)別。

表3-1  簡(jiǎn)單任務(wù)和復(fù)雜任務(wù)特征比較

【問題2】（11分）

王工設(shè)計(jì)方案中指出：要滿足未來網(wǎng)絡(luò)化、智能化和綜合化的需求，應(yīng)該設(shè)計(jì)一種能夠充分表達(dá)嵌入式系統(tǒng)行為的、且具有一定通用性的通信架構(gòu)， 以避免復(fù)雜任務(wù)的某些特征帶來的通信復(fù)雜性。通常為了實(shí)現(xiàn)嵌入式系統(tǒng)中計(jì)算組件間的通信，在架構(gòu)上需要一種簡(jiǎn)單的架構(gòu)風(fēng)格，用于屏蔽不同協(xié)議、不同硬件和不同結(jié)構(gòu)組成所帶來的復(fù)雜性。圖3-1給出了一種“腰（Waistline）" 型通信模式的架構(gòu)風(fēng)格。腰型架構(gòu)的關(guān)鍵是基本消息通信（BMTS），通常BMTS的消息與時(shí)間屬性相關(guān)，支持事件觸發(fā)消息、速率約束消息和時(shí)間觸發(fā)消息。

請(qǐng)說明基于BMTS的消息通信網(wǎng)絡(luò)的主要特征和上述三種消息的基本含義，并舉例給出兩種具有時(shí)間觸發(fā)消息能力的網(wǎng)絡(luò)總線。

圖3-1  “腰”型通信模式架構(gòu)風(fēng)格

●閱讀以下關(guān)于分布式數(shù)據(jù)庫緩存設(shè)計(jì)的敘述，在答題紙上回答問題1至問題3.

【說明】

某企業(yè)是為城市高端用戶提供高品質(zhì)蔬菜生鮮服務(wù)的初創(chuàng)企業(yè)，創(chuàng)業(yè)初期為快速開展業(yè)務(wù)，該企業(yè)采用輕量型的開發(fā)架構(gòu)（腳本語言+關(guān)系型數(shù)據(jù)庫）研制了一套業(yè)務(wù)系統(tǒng)。業(yè)務(wù)開展后受到用戶普遍歡迎，用戶數(shù)和業(yè)務(wù)數(shù)量迅速增長(zhǎng)，原有的數(shù)據(jù)庫服務(wù)器已不能滿足高度并發(fā)的業(yè)務(wù)要求。為此，該企業(yè)成立了專門的研發(fā)團(tuán)隊(duì)來解決該問題。

張工建議重新開發(fā)整個(gè)系統(tǒng)， 采用新的服務(wù)器和數(shù)據(jù)架構(gòu)，解決當(dāng)前問題的同時(shí)為日后的擴(kuò)展提供支持。但是，李工認(rèn)為張工的方案開發(fā)周期過長(zhǎng)，投入過大，當(dāng)前應(yīng)該在改動(dòng)盡量小的前提下解決該問題。李工認(rèn)為訪問量很大的只是部分?jǐn)?shù)據(jù)，建議采用緩存工具M(jìn)emCache來減輕數(shù)據(jù)庫服務(wù)器的壓力，這樣開發(fā)量小，開發(fā)周期短，比較適合初創(chuàng)公司，同時(shí)將來也可以通過集群進(jìn)行擴(kuò)展。然而，劉工又認(rèn)為李工的方案中存在數(shù)據(jù)可靠性和一致性問題，在宕機(jī)時(shí)容易丟失交易數(shù)據(jù)，建議采用Redis來解決問題。在經(jīng)過充分討論，該公司最終決定采用劉工的方案。

【問題1】 （9分）

在李工和劉工的方案中，均采用分布式數(shù)據(jù)庫緩存技術(shù)來解決問題。請(qǐng)說明分布式數(shù)據(jù)庫緩存的基本概念。

表4-1中對(duì)MemCache和Redis兩種工具的優(yōu)缺點(diǎn)進(jìn)行了比較，請(qǐng)補(bǔ)充完善表 4-1中的空（1）~ （6）。

表4-1 MemCache與Redis能力比較

【問題2】 （8分）

劉工認(rèn)為李工的方案存在數(shù)據(jù)可靠性和一致性的問題，請(qǐng)說明原因。

為避免數(shù)據(jù)可靠性和一致性的問題，劉工的方案采用Redis作為數(shù)據(jù)庫緩存，請(qǐng)說明基本的Redis與原有關(guān)系數(shù)據(jù)庫的數(shù)據(jù)同步方案。

【問題3】 （8分）

請(qǐng)給出Redis分布式存儲(chǔ)的2種常見方案和Redis集群切片的幾種常見方式。

相關(guān)推薦：2018年系統(tǒng)架構(gòu)設(shè)計(jì)師真題匯總

點(diǎn)擊注冊(cè)會(huì)員>>>即可獲取系統(tǒng)架構(gòu)設(shè)計(jì)師免費(fèi)在線真題、觀看免費(fèi)公開課！