● 閱讀以下關于嵌入式實時系統相關技術的敘述，在答題紙上回答問題1和問題2。

【說明】

某公司長期從事宇航領域嵌入式實時系統的軟件研制任務。公司為了適應未來嵌入式系統網絡化、智能化和綜合化的技術發展需要，決定重新考慮新產品的架構問題，經理將論證工作交給王工負責。王工經調研和分析，完成了新產品架構設計方案，提交公司高層討論。

【問題1】 （14分）

王工提交的設計方案中指出：由于公司目前研制的嵌入式實時產品屬于簡單型系統，其嵌入式子系統相互獨立，功能單一，時序簡單。而未來滿足網絡化、智能化和綜合化的嵌入式實時系統將是一種復雜系統，其核心特征體現為實時任務的機理、狀態和行為的復雜性。簡單任務和復雜任務的特征區分主要表現在十個方面。請參考表3-1給出的實時任務特征分類，用題干中給出的（a）~（t）20個實時任務特征描述，補充完善表3-1給出的空（1）~（14）。

（a）任務屬性不會隨時間變化而改變；

（b）任務的屬性與時間相關；

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

（d）任務變量域是連續的；

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

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

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

（h）許多任務在產生訪問活動時相互間是并發處理的，很難用step-by-step方法分析；

（i） 因果關系相互影響；

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

（k）系統內構成、策略和描述是相似的；

（l） 系統內存在許多不同的構成、策略和描述；

（m）功能關系是非線性的；

（n） 功能關系是線性的；

（o） 不同的子任務是相互獨立的，任務內部僅存在少量的交互操作；

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

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

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

（s）  原理和規則在表面屬性上很容易被識別；

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

表3-1  簡單任務和復雜任務特征比較

【問題2】（11分）

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

請說明基于BMTS的消息通信網絡的主要特征和上述三種消息的基本含義，并舉例給出兩種具有時間觸發消息能力的網絡總線。

圖3-1  “腰”型通信模式架構風格

●閱讀以下關于分布式數據庫緩存設計的敘述，在答題紙上回答問題1至問題3.

【說明】

某企業是為城市高端用戶提供高品質蔬菜生鮮服務的初創企業，創業初期為快速開展業務，該企業采用輕量型的開發架構（腳本語言+關系型數據庫）研制了一套業務系統。業務開展后受到用戶普遍歡迎，用戶數和業務數量迅速增長，原有的數據庫服務器已不能滿足高度并發的業務要求。為此，該企業成立了專門的研發團隊來解決該問題。

張工建議重新開發整個系統， 采用新的服務器和數據架構，解決當前問題的同時為日后的擴展提供支持。但是，李工認為張工的方案開發周期過長，投入過大，當前應該在改動盡量小的前提下解決該問題。李工認為訪問量很大的只是部分數據，建議采用緩存工具MemCache來減輕數據庫服務器的壓力，這樣開發量小，開發周期短，比較適合初創公司，同時將來也可以通過集群進行擴展。然而，劉工又認為李工的方案中存在數據可靠性和一致性問題，在宕機時容易丟失交易數據，建議采用Redis來解決問題。在經過充分討論，該公司最終決定采用劉工的方案。

【問題1】 （9分）

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

表4-1中對MemCache和Redis兩種工具的優缺點進行了比較，請補充完善表 4-1中的空（1）~ （6）。

表4-1 MemCache與Redis能力比較

【問題2】 （8分）

劉工認為李工的方案存在數據可靠性和一致性的問題，請說明原因。

為避免數據可靠性和一致性的問題，劉工的方案采用Redis作為數據庫緩存，請說明基本的Redis與原有關系數據庫的數據同步方案。

【問題3】 （8分）

請給出Redis分布式存儲的2種常見方案和Redis集群切片的幾種常見方式。

相關推薦：2018年系統架構設計師真題匯總

點擊注冊會員>>>即可獲取系統架構設計師免費在線真題、觀看免費公開課！