【系统分析师之路】2018下系统架构师案例分析历年真题
2018下系统架构师案例分析历年真题
2018年下系统架构师试题一（需求工程）
试题一
某文化产业集团委托软件公司开发一套文化用品商城系统，业务涉及文化用品销售、定制、竞拍和点评等板块，以提升商城的信息化建设水平。该软件公司组织项目组完成了需求调研，现已进入到系统架构设计阶段。考虑到系统需求对架构设计决策的影响，项目组先列出了可能影响系统架构设计的部分需求如下：
（a）用户界面支持用户的个性化定制；
（b）系统需要支持当前主流的标准和服务，特别是通信协议和平台接口；
（c）用户操作的响应时间应不大于3秒，竞拍板块不大于1秒；
（d）系统具有故障诊断和快速恢复能力；
（e）用户密码需要加密传输；
（f） 系统需要支持不低于2G的数据缓存；
（g）用户操作停滞时间超过一定时限需要重新登录验证；
（h）系统支持用户选择汉语、英语或法语三种语言之一进行操作。
项目组提出了两种系统架构设计方案：瘦客户端C/S架构和胖客户端C/S架构，经过对上述需求逐条分析和讨论，最终决定采用瘦客户端C/S架构进行设计。
【问题1】（8分）
在系统架构设计中，决定系统架构设计的非功能性需求主要有四类：操作性需求、性能需求、安全性需求和文化需求。请简要说明四类需求的含义。
【问题2】（8分）
根据表1-1的分类，将题干所给出的系统需求（a）~（h）分别填入（1） ~ （4）。
【问题3】（9分）
请说明瘦客户端C/S架构能够满足题干中给出的哪些系统需求（只需要回答出三个系统需求）。
我的解答
- 【问题1我的解答】
| 需求种类 | 说明解答 |
|---|---|
| 操作性需求 | 易于用户操作或者能够满足用户操作期望的需求 |
| 安全需求 | 保障用户使用系统的安全，防止来自外部的入侵，以及内部的信息泄漏等的需求 |
| 文化需求 | 满足默认的行业标准的需求 |
| 性能需求 | 满足用户在并发操作吞吐率，响应时间可用性方面的需求 |
- 【问题2我的解答】
| 需求描述 | 需求种类 |
|---|---|
| 用户界面支持用户的个性化定制 | 操作性需求 |
| 系统需要支持当前主流的标准和服务，特别是通信协议和平台接口 | 文化需求 |
| 用户操作的响应时间应不大于3秒，竞拍板块不大于1秒 | 性能需求 |
| 系统具有故障诊断和快速恢复能力 | 操作性需求 |
| 用户密码需要加密传输 | 安全需求 |
| 系统需要支持不低于2G的数据缓存 | 性能需求 |
| 用户操作停滞时间超过一定时限需要重新登录验证 | 安全需求 |
| 系统支持用户选择汉语、英语或法语三种语言之一进行操作 | 文化需求 |
- 【问题3我的解答】
（b）系统需要支持当前主流的标准和服务，特别是通信协议和平台接口；
（c）用户操作的响应时间应不大于3秒，竞拍板块不大于1秒；
（e）用户密码需要加密传输；
标准答案
- 【问题1标准答案】
- 性能需求
指响应时间、吞吐量、准确性、有效性、资源利用率等与系统完成任务效率相关的指标。可靠性、可用性等指标可归为此类。 - 安全性需求
系统向合法用户提供服务并阻止非授权用户使用服务方面的系统需求。 - 操作性需求
操作性需求是指系统完成任务所需的操作环境要求以及如何满足系统将来可能的需求的变更的要求。 - 文化需求
带有文化背景因素的系统需求，使用本系统的不同用户群体对系统提出的特有要求。
- 【问题2标准答案】
| 需求描述 | 需求种类（标准答案） | 需求种类（我的答案） |
|---|---|---|
| 用户界面支持用户的个性化定制 | 文化需求 | 操作性需求 |
| 系统需要支持当前主流的标准和服务，特别是通信协议和平台接口 | 操作性需求 | 文化需求 |
| 用户操作的响应时间应不大于3秒，竞拍板块不大于1秒 | 性能需求 | 性能需求 |
| 系统具有故障诊断和快速恢复能力 | 操作性需求 | 操作性需求 |
| 用户密码需要加密传输 | 安全需求 | 安全需求 |
| 系统需要支持不低于2G的数据缓存 | 性能需求 | 性能需求 |
| 用户操作停滞时间超过一定时限需要重新登录验证 | 安全需求 | 安全需求 |
| 系统支持用户选择汉语、英语或法语三种语言之一进行操作 | 文化需求 | 文化需求 |
-
【问题3标准答案】
-
瘦客户端CS架构能更好地满足abdh。
（a）无论胖还是瘦，要做到用户界面的个性化应该都没有问题，而且难说哪种更强。毕竟瘦的只是把业务逻辑从客户端放到了服务器上。
（b）胖和瘦无明显差异。
（c）胖客户端，在客户端的运算能力强一些。瘦客户端可以在服务端面用集群做支持。
（d）瘦客户端将业务逻辑迁移到应用服务器上，所以有故障只要修复服务器上的内容，而胖客户端要更新所有客户端，工作量大，所以此情况下瘦客户端有优势。
（e）胖客户端的后端是数据库，没有业务逻辑，此时要做加密传输没有基础，但瘦客户端可以做到。
（f）胖客户端做到2G数据缓存很容易，而瘦客户端不现实。
（g）瘦客户端与胖客户端均可做到。
（h）瘦客户端与胖客户端均可做到 -
【试题解析】
-
本题考到了一个极为少见的非功能性需求分类方式：
- 操作性需求（Operational Requirements）
- 指系统完成任务所需的操作环境要求及如何满足系统将来可能的需求变更的要求。
- 操作性需求包括：技术环境需求、系统集成需求、可移植性需求、维护性需求
- 性能需求（Performance Requirements）
- 针对系统性能要求的指标。
- 常见的包括：响应时间、吞吐率。
- 性能需求包括：速度需求、容量需求、可信需求
- 安全性需求（Security Requirements）
- 防止系统崩溃和保证数据安全所需要采取的保护措施或预防措施。
- 安全性需求包括：系统价值需求、访问控制需求、加密/认证需求、病毒控制需求
- 文化需求（Cultural Requirements）
- 使用本系统的不同用户群体对系统提出的特有要求。
- 文化需求包括：多语言需求、个性化定制需求、规范性描述需求、法律需求
- 题目问题3主观性比较强，其实题目中提到的这些要求，如果要做，两种架构都是能完成的。所以在此对比一下相对优势。
| No | 需求说明 | 需求实现 |
|---|---|---|
| a | 用户界面支持用户的个性化定制 | 无论胖还是瘦，要做到用户界面的个性化都没有问题，但从更新的角度来看，胖客户端针对新增的个性化要求，更新起来比较困难。所以相对来说，瘦客户端更有优势 |
| b | 系统需要支持当前主流的标准和服务，特别是通信协议和平台接口 | 从单次实现来看，都能实现，但要随时保持最新，瘦客户更有优势 |
| c | 用户操作的响应时间应不大于3秒，竞拍板块不大于1秒 | 胖客户端，在客户端的运算能力强一些 |
| d | 系统具有故障诊断和快速恢复能力 | 瘦客户端将业务逻辑迁移到应用服务器上，所以有故障只要修复服务器上的内容，而胖客户端要更新所有客户端，工作量大，所以此情况下瘦客户端有优势 |
| e | 用户密码需要加密传输 | 瘦客户端与胖客户端无明显差异 |
| f | 系统需要支持不低于2G的数据缓存 | 胖客户端做到2G数据缓存很容易，而瘦客户端不容易实现 |
| g | 用户操作停滞时间超过一定时限需要重新登录验证 | 瘦客户端与胖客户端无明显差异 |
| h | 系统支持用户选择汉语、英语或法语三种语言之一进行操作 | 瘦客户端与胖客户端均可做到，但若涉及到更新，瘦客户端有优势 |
心得体会
- 本题考查了需求工程的知识。其实架构设计中最主要的工作就是将需求分配到设计中，通过设计实现需求。
- 在需求工程的章节中，需求可以分为业务需求，功能需求，系统需求，非功能需求。
- 其中为了更好的描述非功能需求，可以考虑使用PIECES框架来分类。
- 按照质量屋QFD来分，又可以分为基本需求，期望需求和兴奋需求三种。
- 非功能性需求在这里又分为了四类：操作性需求，性能需求，安全需求和文化需求。
- 文化需求这里是第一次看到，它的解释是特定用户的特定需求，那么就是为特定用户准备的解决方案把。
而操作性需求就是完成任务所需要的操作环境的要求，以及如何满足将来可能出现的需求变更。 - 其他性能需求和安全需求这个不需要特别知道的情况下就可以扯出来的知识。
- 第二问就是对于具体的需求的分类了。其实我觉得可以第二问先做再回过头来看第一问。
- 第二问我就是前面两个错了。协议啊标准啊什么的归属于操作性需求，而个性化定制属于文化需求。
- 第三问考查的是不同的需求在设计实现的时候，框架的选型。这个题比较Open，
- 要回答这个题目就要对胖客户机，瘦客户机以及BS架构等有一定的了解，在此基础上答题。
- 胖客户端就是把业务逻辑和界面表示都放在了客户端，瘦客户端就是把应用逻辑放在应用服务器，只把和界面表示的部分放到客户端；
- 而BS架构就是浏览器服务器架构，也就是说零客户端了。连用户界面都交给了应用服务器，客户端只要有浏览器就可以显示了。
回答第三问时，需要结合这些知识来选择性的作答。 - 如果是经常要更新业务逻辑的需求下，显然瘦客户端更加方便维护；相反，业务逻辑不需要经常变动的时候，把业务逻辑放在客户端，那么服务器端的压力是最小的。
2018年下系统架构师试题二（结构化设计）
试题二
某公司欲建设一个房屋租赁服务系统，统一管理房主和租赁者的信息，提供快捷的租赁服务。本系统的主要功能描述如下：
1.登记房主信息。记录房主的姓名、住址、身份证号和联系电话等信息，并写入房主信息文件。
2.登记房屋信息。记录房屋的地址、房屋类型（如平房、带阳台的楼房、独立式住宅等）、楼层、租金及房屋状态（待租赁、已出租）等信息，并写入房屋信息文件。一名房主可以在系统中登记多套待租赁的房屋。
3.登记租赁者信息。记录租赁者的个人信息，包括：姓名、性别、住址、身份证号和电话号码等，并写入租赁者信息文件。
4.安排看房。已经登记在系统中的租赁者，可以从待租赁房屋列表中查询待租赁房屋信息。租赁者可以提出看房请求，系统安排租赁者看房。对于每次看房，系统会生成一条看房记录并将其写入看房记录文件中。
5.收取手续费。房主登记完房屋后，系统会生成一份费用单，房主根据费用单交纳相应的费用。
6.变更房屋状态。当租赁者与房主达成租房或退房协议后，房主向系统提交变更房屋状态的请求。系统将根据房主的请求，修改房屋信息文件。
【问题1】（12分）
若采用结构化方法对房屋租赁服务系统进行分析，得到如图2-1所示的顶层DFD。使用题干中给出的词语，给出图2-1中外部实体E1E2、加工P1P6以及数据存储D1~D4的名称。
图2-1 房屋租赁服务系统顶层DFD
【问题2】（5分）
若采用信息工程（Information Engineering）方法对房屋租赁服务系统进行分析，得到如图2-2所示的ERD。请给出图2-2中实体（1）~ （5）的名称。
图2-2 房屋租赁服务系统ERD
【问题3】（8分）
（1）信息工程方法中的“实体（entity）” 与面向对象方法中的“类（class）”之间有哪些不同之处？
（2）在面向对象方法中通常采用用例（Use Case）来捕获系统的功能需求。用例可以按照不同的层次来进行划分，其中的Essential Use Cases和Real Use Cases有哪些区别?
我的解答
-
【问题1我的解答】
E1:房主
E2：房屋租赁者
P1：登记房主信息
P2:登记房屋信息
P3:登记租赁者信息
P4:查询待租赁房屋信息
P5：安排看房
P6:变更房屋状态
D1:房主信息文件
D2：租赁者信息文件
D3：房屋信息文件
D4：看房记录文件 -
【问题2我的解答】
1）房主
2）房屋
3）房屋列表
4）租赁者
5）看房请求 -
【问题3我的解答】
扫描二维码关注公众号，回复： 12991779 查看本文章
- 信息工程方法中的实体一般对应一个基本表，而面向对象中的类代表一个对真实世界对象的一种抽象，包含但不局限于实体。
- 面向对象中的类分为了三种类型：实体类，边界类和控制类。七种实体类和信息工程中的实体相互对应。
标准答案
- 【问题1标准答案】
| 符号 | 我的答案 | 标准答案 |
|---|---|---|
| E1 | 房主 | 房主 |
| E2 | 房屋租赁者 | 租赁者 |
| P1 | 登记房主信息 | 登记房主信息 |
| P2 | 登记房屋信息 | 登记房屋信息 |
| P3 | 登记租赁者信息 | 登记租赁者信息 |
| P4 | 查询待租赁房屋信息 | 查询租赁房屋信息 |
| P5 | 安排看房 | 安排看房 |
| P6 | 变更房屋状态 | 变更房屋状态 |
| D1 | 房主信息文件 | 房主信息文件 |
| D2 | 租赁者信息文件 | 租赁者信息文件 |
| D3 | 房屋信息文件 | 房屋信息文件 |
| D4 | 看房记录文件 | 看房记录文件 |
- 【问题2标准答案】
| No | 我的答案 | 标准答案 |
|---|---|---|
| 1 | 房主 | 房主 |
| 2 | 房屋 | 房屋 |
| 3 | 房屋列表 | 房屋状态 |
| 4 | 租赁者 | 租赁者 |
| 5 | 看房请求 | 看房记录 |
- 【问题3标准答案】
- 实体用于数据建模，而类用于面向对象建模。实体只有属性，而类有属性和操作。
- Essential Use Cases 可翻译为抽象用例，Real Use Cases 可翻译为基础用例。他们是区别在于：
- 基础用例是实实在在与用户需求有对应关系的用例，是从用户需求获取的渠道得到的，而抽象用例是从基础用例中抽取的用例的公共部分，是为了避免重复工作，优化结构而提出的用例。
- 抽象用例用于分析阶段，它描述了用例的本质属性，它与如何实现这个用例无关，独立于实现该用例的软硬件环境；而基本用例用于设计阶段，描述了用例的实现方式。
心得体会
- 这题考查的就是结构化设计的试题。感觉这题是相对比较简单的一题。
- 第一题，第二题都是填空题，需要从题目中获得响应的信息，然后填入。前两空都是阅读理解题。理解程度就决定是否可以做对。
- 第三小题考查的是概念之间的比较。实体联系图中的实体是用来描述数据模型，而面向对象中的类是用来面向对象建模的；
- ER图中的实体只有属性，每一个属性对应基本关系表中的元组，而类图中的类有属性还有操作；
- 这个概念说实话都是知道的，但一下子用案例考概念还真的有点懵。
- Essential use case是抽象用例，RealUseCase是实际用例（基础用例）。Essential单词不认识，所以是一脸懵逼的状态；
- 在标准答案中，RealUseCase是与用户需求有对应关系的用例；而真实用例中抽取的用例的公共部分，优化结构而提出的用例才是抽象用例。简单一句话来说就是抽象化程序Essential>Real。Essential用在分析阶段，而Real用在设计阶段。
- 原来用例图中的用例还可以这么分，第一次学到这个知识点。
2018年下系统架构师试题三（嵌入式系统）
试题三
某公司长期从事宇航领域嵌入式实时系统的软件研制任务。公司为了适应未来嵌入式系统网络化、智能化和综合化的技术发展需要，决定重新考虑新产品的架构问题，经理将论证工作交给王工负责。王工经调研和分析，完成了新产品架构设计方案，提交公司高层讨论。
【问题1】（14分）
王工提交的设计方案中指出：由于公司目前研制的嵌入式实时产品属于简单型系统，其嵌入式子系统相互独立，功能单一，时序简单。而未来满足网络化、智能化和综合化的嵌入式实时系统将是一种复杂系统，其核心特征体现为实时任务的机理、状态和行为的复杂性。简单任务和复杂任务的特征区分主要表现在十个方面。请参考表3-1给出的实时任务特征分类，用题干中给出的（a）（t）20个实时任务特ji征描述，补充完善表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我的解答】
| 特征分类 | 简单任务 | 复杂任务 |
|---|---|---|
| 静态动态 | 任务属性不会随时间变化而改变 | 任务的属性与时间相关 |
| 连续非连续 | c任务仅可以从非连续集中获取特征变量 | d任务变量域是连续的 |
| 子系统独立性 | o 不同的子任务是相互独立的，任务内部仅存在少量的交互操作 | p 不同的子任务有很高的交互操作，要把一个单任务的行为隔离开是困难的 |
| 顺序/并行执行 | g 任务行为可以用step-by-step顺序分析方法来理解 | h 许多任务在产生访问活动时相互间是并发处理的，很难用step-by-step方法分析 |
| 单一性混合性 | i 因果关系相互影响 | j 行为特征依赖于大量的反馈机制 |
| 工作原理 | k 系统内构成、策略和描述是相似的 | l 系统内存在许多不同的构成、策略和描述 |
| 线性非线性 | n功能关系是线性的 | m 功能关系是非线性的 |
| 上下文相关性 | e 功能原理不依赖于上下文 | f功能原理依赖于上下文 |
| 规律不规律 | q 域特征有非常整齐的原则和规则 | r许多不同的上下文依赖于规则 |
| 表面属性 | s 原理和规则在表面属性上很容易被识别 | t原理被覆盖、抽象，而不会在表面属性上被识别 |
- 【问题2我的解答】
- 事件触发消息：只有当某个事件触发时，消息才被发出。
- 时间触发消息：当到达某个时间点时，消息被触发。
- 速率约束消息：当传输速率低于或高于某一个基准值时，被触发的消息。
标准答案
- 【问题1标准答案】
| 特征分类 | 简单任务 | 复杂任务 |
|---|---|---|
| 静态动态 | 任务属性不会随时间变化而改变 | 任务的属性与时间相关 |
| ☆连续非连续 | d任务变量域是连续的 | c任务仅可以从非连续集中获取特征变量 |
| ☆子系统独立性 | e 功能原理不依赖于上下文 | f功能原理依赖于上下文 |
| 顺序/并行执行 | g 任务行为可以用step-by-step顺序分析方法来理解 | h 许多任务在产生访问活动时相互间是并发处理的，很难用step-by-step方法分析 |
| 单一性混合性 | i 因果关系相互影响 | j 行为特征依赖于大量的反馈机制 |
| 工作原理 | k 系统内构成、策略和描述是相似的 | l 系统内存在许多不同的构成、策略和描述 |
| 线性非线性 | n功能关系是线性的 | m 功能关系是非线性的 |
| ☆上下文相关性 | o 不同的子任务是相互独立的，任务内部仅存在少量的交互操作 | p 不同的子任务有很高的交互操作，要把一个单任务的行为隔离开是困难的 |
| 规律不规律 | q 域特征有非常整齐的原则和规则 | r许多不同的上下文依赖于规则 |
| 表面属性 | s 原理和规则在表面属性上很容易被识别 | t原理被覆盖、抽象，而不会在表面属性上被识别 |
- 【问题2标准答案】
- BMTS的消息通信网络主要特征为：能适配不同的传输介质，以及适配不同的协议，屏蔽不同协议之间的差异，简化通信过程降低系统复杂度。一个计算组件传送消息到另一个或多个组件，传输可靠性高，延迟低，抖动微小；
- 事件触发消息：以事件作为触发方式，事件发生便触发相应消息。
- 速率约束消息：传输速率固定的消息。
- 时间触发消息：以时间作为触发方式，到达时间点便触发相应消息。
- 具有时间触发消息能力的网络总线：
- 航空电子全双工交换式以太网（Avio¬nics Full Duplex Switched Ethernet，AFDX）
- 时间触发以太网（Time-Triggered Ethernet，TTE）
心得体会
- 此题归属于嵌入式系统设计章节，考察了腰”型架构风格。但是实际的两个问题却和腰架构没有什么大的关系。
- 速率约束消息我是真的不清楚。也没有蒙对，它的定义是传输速率固定的消息（我去）事件触发和时间触发这两个从字面上就可以理解了，不算太难。具有时间触发消息能力的网络总线没有这方面的知识储备，这里就靠死记硬背吧。
- 航空电子全双工交换式以太网（Avio¬nics Full Duplex Switched Ethernet，AFDX）和时间触发以太网（Time-Triggered Ethernet，TTE）
- BMTS消息这个也是我的知识库的盲点。BMTS的消息通信网络主要特征为：能适配不同的传输介质，以及适配不同的协议，屏蔽不同协议之间的差异，简化通信过程降低系统复杂度
- 第一空考查了简单系统简单任务和复杂任务。而题型也是超级简单，已经可以说近似于判断题了。上下文相关性和子系统独立性我搞反了。怀疑是不是答案本身存在问题。
- 复杂系统简单系统这个题目真的很多都不知道，所以打算把它作为一个嵌入式知识点储备起来。
2018年下系统架构师试题四（数据库設計）
试题四
某企业是为城市高端用户提供高品质蔬菜生鲜服务的初创企业，创业初期为快速开展业务，该企业采用轻量型的开发架构（脚本语言+关系型数据库）研制了一套业务系统。业务开展后受到用户普遍欢迎，用户数和业务数量迅速增长，原有的数据库服务器已不能满足高度并发的业务要求。为此，该企业成立了专门的研发团队来解决该问题。
张工建议重新开发整个系统，采用新的服务器和数据架构，解决当前问题的同时为日后的扩展提供支持。但是，李工认为张工的方案开发周期过长，投入过大，当前应该在改动尽量小的前提下解决该问题。李工认为访问量很大的只是部分数据，建议采用缓存工具MemCache来减轻数据库服务器的压力，这样开发量小，开发周期短，比较适合初创公司，同时将来也可以通过集群进行扩展。然而，刘工又认为李工的方案中存在数据可靠性和一致性问题，在宕机时容易丢失交易数据，建议采用Redis来解决问题。在经过充分讨论，该公司最终决定采用刘工的方案。
【问题1】（9分）
在李工和刘工的方案中，均采用分布式数据库缓存技术来解决问题。请说明分布式数据库缓存的基本概念。
表4-1中对MemCache和Redis两种工具的优缺点进行了比较，请补充完善表4-1中的空（1）~ （6）。
【问题2】（8分）
刘工认为李工的方案存在数据可靠性和一致性的问题，请说明原因。
为避免数据可靠性和一致性的问题，刘工的方案采用Redis作为数据库缓存，请说明基本的Redis与原有关系数据库的数据同步方案。
【问题3】（8分）
请给出Redis分布式存储的2种常见方案和Redis集群切片的几种常见方式。
我的解答
- 【问题1我的解答】
分布式数据库缓存是指分布式系统中经常需要访问的内容放到缓存中，从而得到加快访问速度提高数据库访问性能效率。
| MemCache | Redis | |
|---|---|---|
| 数据类型 | 简单的键值结构 | 键值结构 |
| 持久性 | 不支持 | 支持 |
| 分布式存储 | 支持 | 多种方式，主从，聚簇，Sentinel |
| 多线程技术 | 支持 | 支持 |
| 内存管理 | 有 | 无 |
| 事务支持 | 支持 | 有限支持 |
- 【问题2我的解答】
- MemCache不支持持久性，当宕机时容易丢失交易数据，导致数据的不一致。
- 将经常需要访问的数据放在Redis中，同时通过定期任务更新的方式保持数据的同步一致性。
- 【问题3我的解答】
- 水平分片，垂直分片以及两者的混合分片。
标准答案
- 【问题1标准答案】
- 分布式数据库缓存是指在高并发的环境下，为了减轻数据库的压力和提高系统的响应时间，在数据库系统和应用系统之间增加独立缓存系统。
| MemCache | Redis | |
|---|---|---|
| 数据类型 | 简单的键值结构 | key/value，list，set，hash，sorted |
| 持久性 | 不支持 | 支持 |
| 分布式存储 | ☆不支持 | 多种方式，主从，聚簇，Sentinel |
| 多线程技术 | 支持 | 不支持 |
| 内存管理 | 有 | 无 |
| 事务支持 | ☆不支持 | 有限支持 |
- 【问题2标准答案】
- Memcache没有持久化功能，所以掉电数据会全部丢失，而且无法直接恢复，这存在可靠性问题。
- Memcache不支持事务，所以操作过程中可能产生数据的不一致性。
- 同步方案：
读取数据时，先读取Redis中的数据，如果Redis没有，则从原数据库中读取，并同步更新Redis中的数据。写回时，写入到原数据库中，并同步更新至Redis中
- 【问题3标准答案】
- Redis常见的分布式存储方案是
- 主从模式Master/Slave
- 哨兵模式Sentinel
- 集群模式Cluster
- Redis集群切片常见的方式有：
- 客户端分片
即在客户端就通过Key的hash值对应到不同的服务器 - 中间件实现分片
在应用软件和Redis中间，例如Twemproxy，Codis等，由中间件实现服务到后台Redis节点的路由分派。 - 客户端服务端协作分片
RedisCluster，客户端可以采用一致性Hash，服务端提供错误节点的重新定向服务Slot上。不同Slot对应到不同的服务器。
- 【答案解析】
- Redis和MemCache都是将数据存放在内存中，都是内存数据库。它们都支持键值数据类型，同时Memcache还可用于缓存其他东西，例如图片、视频等等，Redis还支持list、set、hash等数据结构的存储。
- Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。Memcache挂掉之后，数据就没了。
- 灾难恢复-Memcache挂掉后，数据不可恢复; Redis数据丢失后可以恢复。
- 在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcache相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的value交换到磁盘。
- Redis在很多方面支持数据库的特性，可以这样说他就是一个数据库系统，而Memcache只是简单地K/V缓存。
- 所以在选择方面如果有持久方面的需求或对数据类型和处理有要求的应该选择Redis。而简单的键值存储应该选择MemCache。
心得体会
- 此题考查的是内存数据库这个知识点，比较了当前比较流行的MemCache和Redis这两种技术
- 第一题首先考查数据库缓存的基本概念，这个大致可以答对，但是不够严谨。
- 关键字是提高数据库响应时间，减轻数据库的压力这两点，它加在了应用和数据库系统之间。
- MemCache和Redis这两种技术的比较，MemCache没有Redis先进，也没有Redis用得普遍，MemCache最多只能存储键值信息，它不支持分布式存储也不支持事务处理，关键也不可以持久存放。只有比较简单的信息系统需要通过Key-Value来提高速度的时候，那么MemCache是适用的。而且不支持事务那么就有可能出现数据不一致的情况。
- Redis对事务是有限支持的，那么就可以避免数据可靠性和一致性的问题，读取数据时，先读取Redis中的数据，如果Redis没有，则从原数据库中读取，并同步更新Redis中的数据。写回时，写入到原数据库中，并同步更新至Redis中
- 第二问这个答案和计算机组成原理中的局部性原理不是一个原理嘛。
- 第三问Redis分布式存储的2种常见方案，这个在表格里已经写了，几乎可以算是送分了。但我都没有回答出来。懵逼了。
- 而Redis集群切片的常见方式这个真的不清楚了。就当一个知识点记下来把。通过集群分片可以到达负载均衡的目的。
2018年下系统架构师试题五（面向服务架构）
试题五
某银行拟将以分行为主体的银行信息系统，全面整合为由总行统一管理维护的银行信息系统，实现统一的用户账户管理、转账汇款、自助缴费、理财投资、贷款管理、网上支付、财务报表分析等业务功能。但是，由于原有以分行为主体的银行信息系统中，多个业务系统采用异构平台、数据库和中间件，使用的报文交换标准和通信协议也不尽相同，使用传统的EAI解决方案根本无法实现新的业务模式下异构系统间灵活的交互和集成。因此，为了以最小的系统改进整合现有的基于不同技术实现的银行业务系统，该银行拟采用基于ESB的面向服务架构（SOA）集成方案实现业务整合。
【问题1】（7分）
请说明什么是面向服务架构（SOA）以及ESB在SOA中的作用与特点。
【问题2】（12 分）
基于该信息系统整合的实际需求，项目组完成了基于SOA的银行信息系统架构设计方案。该系统架构图如图5-1所示：
图5-1 基于SOA的银行信息系统架构设计
请从（a）~ （j）中选择相应内容填入图5-1的（1）~ （6），补充完善架构设计图。
（a）数据层
（b）界面层
（c）业务层
（d） bind
（e） 企业服务总线ESB
（f） XML
（g） 安全验证和质量管理
（h） publish
（i） UDDI
（j） 组件层
（k） BPEL
【问题3】（6分）
针对银行信息系统的数据交互安全性需求，列举3种可实现信息系统安全保障的措施。
我的解答
- 【问题1我的解答】
- SOA是面向服务的架构，它具有标准接口，松散耦合，粗粒度等三个特点。
- ESB是企业服务总线，它将所有的服务都封装好后，一个个的挂接在企业的一个总线上，以方便调用。
- 【问题2我的解答】
1）业务层b
2）数据层a
3）bind
4）企业服务总线ESB
5）安全验证和质量管理
6）组件层 - 【问题3我的解答】
不清楚
标准答案
- 【问题1标准答案】
- SOA是一个组件模型，它将应用程序的不同功能单元（服务）通过服务之间定义良好的接口和契约联系起来，接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台，操作系统和编程语言。这使得构件在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
- ESB的作用和特点
- ESB是SOA的一种实现方式，ESB在面向服务的架构中起到的是总线的作用，将各种服务进行连接和整合。
- 描述服务的元数据和服务注册管理
- 在服务请求者何服务提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总线出来的一些模式如同步模式和异步模式。
- 发现，路由，选择和匹配的能力，以支持服务之间的动态交互，解耦服务请求者与服务提供者，高级一些的能力包括对安全的支持，服务质量保证，可管理性和负载均衡。
- 【问题2标准答案】
| No | 我的解答 | 标准答案 |
|---|---|---|
| 1 | 业务层 | 业务层 |
| 2 | 数据层 | ☆UDDI |
| 3 | bind | ☆Publish发布 |
| 4 | 企业服务总线ESB | 企业服务总线ESB |
| 5 | 安全验证和质量管理 | 安全验证和质量管理 |
| 6 | 组件层 | 组件层 |
- 【问题3标准答案】
- 引入Https协议或者采用加密技术对数据先加密再传输。
- 采用信息摘要技术对重要信息进行完整性验证
- 防火墙系统
- 安全检测
- 【解析】
- 从应用的角度定义，可以认为SOA是一种应用框架，它着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务。SOA 使用户可以构建、部署和整合这些服务，且无需依赖应用程序及其运行平台，从而提高业务流程的灵活性。这种业务灵活性可使企业加快发展速度，降低总体拥有成本，改善对及时、准确信息的访问。SOA 有助于实现更多的资产重用、更轻松的管理和更快的开发与部署。
- 从软件的基本原理定义，可以认为SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
心得体会
- 这题考查的是面向服务的架构SOA。SOA面向服务有两个主要的应用场景，一个是WebService，另一个就是ESB企业服务总线。
- 第一问考的就是概念定义的默写。SOA是什么东东，ESB又是什么东东；这些概念应该都该比较能够扯了。
- 在概念中，还谈到了解耦服务请求者与服务提供者，保证安全，还能够实现负载均衡等。
- 第一问考的是填空，对SOA架构的理解程度。但是对于UDDI不是很了解（惭愧），所以第二问的二三空我都做错了。
- UDDI是一种用于描述、发现、集成Web Service的技术，它是Web Service协议栈的一个重要部分。通过UDDI，企业可以根据自己的需要动态查找并使用Web服务，也可以将自己的Web服务动态地发布到UDDI注册中心，供其他用户使用。
- 通过图可以看到，用户业务层的服务都是通过它动态地绑定自己需要的服务，同时服务层的服务也是通过ESB企业服务总线，将打包好的服务发布上去，让上层能够查找到并能够使用服务。
- 可以看到通过ESB，这种服务都被连接和整合到了一起，上层业务层只要调用就可以了。
- 第三空考查的是实现信息系统安全保障的措施。这个可以算是脑洞题把，一开始我都不知道该如何回答，所以比较的遗憾。
- 比如访问控制手段，安全传输协议https，防火墙系统，签名技术都可以写上去。
- 总的来说，这题也不算难的。但是要拿全部分数的化也不太容易把。