點選報名後領取>>>軟考16本電子版教材 & 36本輔導教材 + 27套曆年真題試卷 + 21套精編知識點6G資料包
系統設計考察要點
· 軟體架構風格（****）
· 品質屬性與架構評估（*****）
· Web架構綜合考察（*****）
軟體架構風格（****）
考察方式一般是架構風格對比，是以需要掌握五大架構風格及子風格及特點等（建議記憶書中内容，以下是這五種架構風格的概述）。
· 資料流風格将前一步處理的結果作為後一步的輸入内容，主要包含批處理序列與管道-過濾器兩種風格，批處理序列強調的是大量整體的資料一起處理，而管道過濾器強調的是流式資料的處理；
· 調用傳回風格主要包含主程式/子程式、面向對象風格、層次結構三種風格，主程式/子程式是面向過程的調用，面向對象風格主要是對象方法的調用，層次結構則是層與層的方法調用；
· 獨立構件風格強調的是構件之間不直接互動進而降低系統的耦合性，主要包含程序通信與事件驅動兩種風格；
· 虛拟機風格的特點是可以靈活的自定義場景，主要包含解釋器風格與規則系統，而規則系統其實是在解釋器的基礎之上增加了經驗規則；
· 倉庫風格強調的是以資料為中心，主要包含資料庫系統、黑闆系統、超文本系統三種風格
品質屬性與架構評估（*****）
這塊是最重要的，基本年年必考品質屬性。
品質屬性主要是四種（性能、可用性、安全性、可修改性），考察方式一般是羅列品質屬性讓你識别是哪種品質屬性，考察時可能還會額外有其他品質屬性。
· 性能是指系統的響應能力，即要多長時間才能對某個事件做出響應或者在某段時間内系統所能處理的事件的個數；
· 可用性是指系統正常運作的時間比例，經常用兩次故障之間的時間長度或出現故障時系統能夠恢複正常的速度來表示；
· 安全性是指系統能夠向合法使用者提供服務的同時可以阻止非授權使用者通路的企圖或拒絕服務的能力；
· 可修改性是指系統能夠快速地以較高的性能價格比對系統進行變更的能力，通常以某些具體的變更為基準，通過評估這些變更的代價衡量可修改性。
如2020年案例真題請分析題幹中的需求描述，填寫圖1-2中(1)～(6)處的空白。
偶爾可能會考察架構評估的一些概念如下：
架構評估方法：
· 1 軟體架構分析法（SAAM） 最初僅僅是用于分析架構可修改性，後面擴充到其他品質屬性。
· 2 架構權衡分析法（ATAM） 從軟體架構分析法發展而來，主要是針對性能、可用性、安全性和可修改性，在系統開發之前，對這些品質屬性進行評價和折中。
· 3 成本效益分析法（CBAM） 成本效益分析是通過比較項目的全部成本和效益來評估項目價值的一種方法，成本—效益分析作為一種經濟決策方法，以尋求在投資決策上如何以最小的成本獲得最大的收益。
系統架構風險（風險點）：是指架構設計中潛在的、存在問題的架構決策所帶來的隐患。
敏感點：是指為了實作某種特定的品質屬性，一個或多個構件所具有的特性。
權衡點：是影響多個品質屬性的特性，是多個品質屬性的敏感點。
Web架構綜合考察（*****）
Web架構綜合題也是年年必然會考察的，考察的方式多種多樣，按往年一般從以下方面考察：從架構來看：MVC、MVP、MVVM、REST、Webservice、微服務
| 角度 | 考察點 |
| 從并發分流來看 | 叢集（負載均衡），CDN |
| 從緩存來看 | MemCache、Redis、Squid |
| 從資料來看 | 主從庫（主從複制）、記憶體資料庫、反規範化技術、NoSQL、分區（分表）技術、視圖與物化視圖 |
| 從持久化來看 | Hibernate、Mybatis |
| 從分布存儲來看 | Hadoop、FastDFS、區塊鍊 |
| 從資料編碼來看 | XML、JSON |
| 從Web應用伺服器來看 | Apache、WebSphere、WebLogic、Tomcat、JBOSS、IIS |
| 從安全性來看 | SQL注入攻擊 |
| 其他 | 靜态化、有狀态與無狀态、響應式Web設計、中台 |
一些相關概念：
應用層負載均衡：
· Http重定向，特點：實作簡單，但性能較差。
· 反向代理伺服器，特點：部署簡單，但代理伺服器可能成為性能瓶頸。
傳輸層負載均衡：
· DNS域名解析負載均衡，特點：效率比HTTP重定向高，減少維護負載均衡伺服器成本。但一個應用伺服器故障，不能及時通知DNS，而且DNS負載均衡的控制權在域名伺服器商那裡，網站無法做更多的改善和更強大的管理。
· 基于NAT的負載均衡，特點：技術較為成熟，一般在網關位置，可以通過硬體實作。像四層交換機一般就采用了這種技術。
負載均衡算法
· 輪轉算法：輪流将服務請求排程給不同的節點。
· 權重輪轉算法：考慮不同節點處理能力的差異。
· 源位址哈希雜湊演算法：根據請求的源IP位址，作為散列鍵從靜态配置設定的散清單找出對應的節點。
· 目标位址哈希雜湊演算法：根據請求目标IP做散列找出對應節點。
· 随機算法：随機配置設定，簡單，但不可控
負載均衡算法
· 最小連接配接數算法：新請求配置設定給目前活動請求數量最少的節點，每個節點處理能力相同的情況下。
· 權重最小連接配接數算法：考慮節點處理能力不同，按最小連接配接數配置設定。
· 權重百分比算法：考慮了節點的使用率、硬碟速率、程序個數等，使用使用率來表現剩餘處理能力。
負責均衡算法
軟體負載均衡：LVS、Nginx、HAproxy
Session共享機制：
· 方案一：用戶端Cookie攜帶Session
· 方案二：服務間同步Session
· 方案三：将Session存入Redis
Hibernate與Mybatis的技術不同次元技術對比：
· 簡單對比：Hibernate強大、複雜、間接、SQL無關；Mybatis小巧、簡單、直接、SQL相關
· 可移植性：Hibernate好（不關心具體資料庫）；Mybatis差（根據資料庫SQL編寫）
· 複雜多表關聯：Hibernate不支援；Mybatis支援
資料庫讀寫分離化-主從資料庫結構特點：
· 一般：一主多從，也可以多主多從。
· 主庫做寫操作，從庫做讀操作。
資料庫讀寫分離化-主從複制步驟：
· 1 主庫更新資料完成前，将操作寫binlog日志檔案。
· 2 從庫打開I/O線程與主庫連接配接，做binlog dump process，并将事件寫入中繼日志。
· 3 從庫執行中繼日志事件，保持與主庫一緻。
緩存與資料庫協作-資料讀取：
· 1 根據key從緩存讀取
· 2 若緩存沒有，則根據key在資料庫中查找
· 3 讀取到“值”之後，更新緩存
緩存與資料庫協作-資料寫入：
· 1 根據key值寫資料庫
· 2 根據key更新緩存
Redis與Memcache的能力比較
| 對比次元 | Redis | Memcache |
| 持久性 | 支援 | 不支援 |
| 分布式存儲 | 多種方式，主從、Sentinel、Cluster等 | 用戶端哈希分片/一緻性哈希 |
| 多線程支援 | 不支援（Redis6.0開始支援） | 支援 |
| 記憶體管理 | 無 | 私有記憶體池/記憶體池 |
| 事務支援 | 有限支援 | 不支援 |
| 資料容災 | 支援，可以在災難發生時恢複資料 | 不支援，不能做資料恢複 |
Redis叢集切片的常見方式
· 用戶端分片：在用戶端通過key的hash值對應到不同的伺服器
· 中間件分片：在應用軟體和redis中間，例如：Twemproxy，Codis等，由中間件實作服務到背景Redis節點的路由分派。
· 用戶端服務端協作分片：Redis Cluster模式，用戶端可采用一緻性哈希，服務端提供錯誤節點的重定向服務slot上。不同的slot對應到不同的伺服器。
Redis分布式存儲方案
· 主從（Master/Slave）模式，核心特點：一主多從，故障時手動切換。
· 哨兵（Sentinel）模式，核心特點：有哨兵的一主多從，主節點故障自動選擇新的主節點。
· 叢集（Cluster）模式，核心特點：分節點對等叢集，分slots，不同slots的資訊存儲到不同節點。
Redis資料分片方案：
· 範圍分片：按資料範圍值做分片
· 哈希分片：通過對key進行hash運算分片，可以把資料配置設定到不同執行個體，這類似于取餘操作，餘數相同的，放在一個執行個體上。
· 一緻性哈希分片：哈希分片的改進，可以有效解決重新配置設定節點帶來的無法命中的問題。
Redis的持久化方式：
· RDB：傳統資料庫中快照的思想。指定時間間隔将資料進行快照存儲。
· AOF：傳統資料庫中的日志思想，把每條改變資料集的指令追加到AOF檔案末尾，這樣出問題了，可以重新執行AOF檔案中的指令來重建資料集。
Redis兩種持久化方式對比：
| RDB | AOF | |
| 備份量 | 重量級的全量備份，儲存整個資料庫 | 輕量級增量備份，一次隻儲存一個修改指令 |
| 儲存間隔時間 | 儲存間隔時間長 | 儲存間隔時間短，預設1秒 |
| 還原速度 | 資料還原速度快 | 資料還原速度慢 |
| 阻塞情況 | save會阻塞，但bgsave或則自動不會阻塞 | 無論是平時還是AOF重寫，都不會阻塞 |
| 資料體積 | 同等資料體積小 | 同等資料體積大 |
| 安全性 | 資料安全性低，容易丢資料 | 資料安全性高，根據政策決定 |
Redis緩存的資料淘汰政策：
· 不淘汰（noeviction）：進制驅逐資料，記憶體不足以容納新資料時，新寫入操作會報錯。系統預設的一種淘汰政策。
· 設定了過期時間的鍵空間：
§ volatile-random：随機移除某個key
§ volatile-lru：優先移除最近最少使用的key
§ volatile-ttl：ttl值小的key優先移除
· 全鍵空間：
§ allkeys-random：随機移除某個key
§ allkeys-lru：優先移除最近最少使用的key
Redis的緩存雪崩解決方案：（大部分緩存失效 -> 資料庫崩潰）
· 使用鎖或隊列：保證不會有大量的線程對資料庫一次性進行讀寫，進而避免失效時大量的并發請求落到底層存儲系統上。
· 為key設定不同的緩存失效時間：在固定的一個緩存時間基礎上+随機一個時間作為緩存失效時間。
· 二級緩存：設定一個有時間限制的緩存+一個無時間限制的緩存。避免大規模通路資料庫。
Redis緩存穿透解決方案：（查詢無資料傳回 -> 直接查資料庫）
· 如果查詢結果為空，直接設定一個預設值放到緩存，這樣第二次到緩存中擷取就有值了。設定一個不超過5分鐘的過期時間，以便能正常更新緩存。
· 設定布隆過濾器，将所有可能存在資料哈希到一個足夠大的bitmap中，一個一定不存在的資料會被這個bitmap攔截掉，進而避免了對底層存儲系統的查詢壓力。
Redis緩存預熱解決方案：（系統上線後，将相關需要緩存資料直接加到緩存系統中）
· 直接寫個緩存重新整理頁面，上線時手工操作。
· 資料量不大時，可以再項目啟動的時候自動進行加載。
· 定時重新整理緩存。
Redis緩存更新常見的兩種方式
· 1 定時清理過期的緩存
· 2 當有使用者請求過來時，再判斷這個請求所用到的緩存是否過期，過期的話就去底層系統得到資料并更新緩存
Redis緩存降級：
· 目的是保證核心服務可用，即使是有損的，而且有些服務是無法降級的（如電商的購物流程等）；在進行降級之前要對系統進行梳理，進而梳理出哪些必須保護，哪些可以降級。
文章源于網絡，如有侵權，請私信文章标題聯系删除，謝謝。
為了能讓更多人享受軟考的政策福利和現實功利，51CTO旗下軟考教研團隊聯合薛大龍老師，認真嚴肅向大家推出軟考2日直播特訓營。
掃碼入群0元領取6G的軟考6資料包+2天軟考特訓營名額
軟考資料包括：軟考16本電子版教材 & 36本輔導教材 + 27套曆年真題試卷 + 21套精編知識點6G資料包
軟考訓練營名額+資料領取方式>>>
掃下方碼入群後按照老師的要求操作即可領取。
51CTO軟考兩天直播訓練營
這門課恰好能夠為你答疑解惑，助你快速入門并掌握軟考知識要點，獲得技能提升。為自己的職業發展規劃制定一個更明确的規劃，邁出升職加薪的第一步。
訓練營周期為 兩天直播課 晚8：00-9：00
心急的小夥伴可直接掃碼解鎖。
☟☟☟
2天軟考直播特訓營
3大必備技能
↓↓↓
限時 0 元 即可解鎖
點選下方連結報名
僅限前100個名額
報名連結: https://edu.51cto.com/surl=oR9sp3
課程涵蓋：高分知識點梳理，案例分析解題方法、論文通用模闆等。我們力争通過2天的直播課程，助力您快速入門并一次性通關軟考！
如果你對這門課程還不太了解的話，就跟我一起往下看吧。
我們的主講老師薛大龍老師，深耕軟考教育教育訓練20餘年，主編出版軟考輔導教材60餘本，非常熟悉軟考題目的要求、難度、以及判卷标準。
完成本體驗營2天所有課程及作業考核，學員将掌握資訊系統項目管理師、系統內建項目管理工程師的高頻考點及答題技巧：
①掌握資訊系統項目管理師知識體系；
②掌握考試高分占比知識領域；
③掌握考試考情前沿分析；
④掌握論文與案例超幹貨答題方法；
⑤掌握名師對真題的獨到解析。
報名前，你還需要知道的3件事
1）課程形式
直播課程+社群學習活動
2）課程時間
報名後老師安排上課 晚8:00-9:00
3）報名後要做什麼？
付費後根據提示添加學姐為好友，開營前學姐會統一拉人入群。
2天軟考考證特訓營
0 元 解鎖課程
還可 領取「6G課程資料」