案例分析心得
2018-2022年的案例分析考试内容汇总（近五年）
| 架构设计题型 | 软件系统建模 | 数据库 | Web 系统设计 | |
| 2018年 |
|
|
|
|
| 2019年 |
|
|
|
|
| 2020年 |
|
|
|
|
| 2021年 |
|
|
|
|
| 2022年 |
|
|
|
|
骚戴理解：
- 架构设计题型：可以发现题目慢慢趋向于稳定，一个送分的质量属性效用树，可以发现这个送分的题目的分值越来越少了，另外一个是分析比较多种架构风格，我猜今年的题型也是这样的结构！首先要明确目标，这个题型的分必须拿满分或者接近满分才行，只有这样才有机会过案例分析，否则来年再战！
-
- 多种架构风格分析，可以发现基本上是从【可修改性、灵活性、性能、可扩展性、数据处理方式】这些角度去分析，所以在备考的时候需要把所有的架构风格的这些角度的特点都要背下来，考试的时候再结合题目原文的内容，引用一些作为依据，然后简洁写几句这些架构风格的这些角度的分析结论，那么这个分基本上就可以拿到大部分了
- 质量属性效应树是可以拿满分的，这个也很简单，没什么好讲的
- 软件系统建模题型：基本上数据流图是必考的，这些基本上是UML的相关知识，但是新教程里面没有了UML这一章节，不知道今年会不会考，我倒是希望考，因为这个题目不难，常规一点的题目就是靠数据流图的填充和0层数据流图，再加一些概念，下面是我考中级的时候做的笔记，都是关于UML的相关知识，作为扩展
-
- 试题一（数据流图）_数据流图经典例题_骚戴的博客-CSDN博客
- 试题三（UML）_包含关系箭头指向-CSDN博客
- 软件设计师---UML-CSDN博客
- 数据库题型：可以发现近五年考的基本上都是缓存的相关知识，Redis缓存考的最多，如何保持缓存和数据库的一致性也考的很多，所以备考重点就是缓存的知识，不会考很深，但是会很广，下面是我写的面试题，可以作为一个缓存知识的补充
-
- Redis面试题-CSDN博客
- Web 系统设计题型：这个题型基本上杂七杂八，毫无规律可言，垃圾题型，一般情况下不建议做
案例分析-质量属性
结合业务场景来谈软件质量属性及其实现的架构设计策略
(1) 该要求主要对应性能，可以采用的架构设计策略有增加计算资源、改善资源需求、资源管理和资源调度。
(2) 该要求主要对应安全性，可以采用的架构设计策略有抵御攻击、攻击检测、从攻击中恢复和信息审计等。
(3) 该要求主要对应可用性，可以采用的架构设计策略有心跳、Ping/Echo、主动冗余、 被动冗余、选举等。
(4) 该要求主要对应可修改性，接口-实现分离、抽象、信息隐藏等架构策略实现该属性。
列举软件质量属性名称并解释其含义
列举软件质量属性名称
常见的软件质量属性有多种，例如性能(Performance)、可用性(Availability)、可靠性 (Reliability)、健壮性(Robustness)、安全性(Security)、可修改性(Modification)、可变性 (Changeability)、易用性(Usability)、可测试性(Testability)、功能性(Functionality)和互操作性 (Inter-operation)等。
这些质量属性的具体含义
(1)性能是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某 段时间内系统所能处理事件的个数。
(2)可用性是系统能够正常运行的时间比例。
(3)可靠性是指软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力。
(4)健壮性是指在处理或环境中，系统能够承受压力或变更的能力。
(5)安全性是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝 服务的能力。
(6)可修改性是指能够快速地以较高的性能价格比对系统进行变更的能力。
(7)可变性是指体系结构经扩充或变更成为新体系结构的能力。
(8)易用性是衡量用户使用一个软件产品完成指定任务的难易程度。
(9)可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和 成本前提下，进行测试设计、测试执行的能力。
(10)功能性是系统所能完成所期望工作的能力。
(11)互操作性是指系统与外界或系统与系统之间的相互作用能力
系统架构风险，敏感点和权衡点的定义
系统架构风险：架构设计中潜在的，存在问题的架构决策所带来的隐患
系统架构敏感点：为了实现某种特定的质量属性，一个或多个构件所具有的特性
系统架构权街点：影响多个质量属性的特性，是多个质量属性的敏感点
葵花宝典
这里积累做题中遇到的各个质量属性的描述，我愿称之为质量属性这类题目的葵发宝典，欲练此功，必先自宫！
性能
- 正常负载情况下，系统必须在 0.5 秒内对用户的交易请求进行响应
- 交易过程中涉及到的产品介绍视频传输必须保证画面具有 600*480 的分辨率，20 帧/ 秒的速率；
- 在正常负载情况下，系统必须在 0.5 秒内响应用户的交易请求；
- 在高峰负载情况下，用户发起支付请求后系统必须在 10 秒内完成支付功能；
- 正常负载情况下，系统必须在 0.5 秒内对用户的车辆查询请求进行响应；
- 查询过程中涉及到的车辆实时视频传输必须保证 20 帧／秒的速率，且画面具有 600*480 的分辨率；
- 支持不同模型的自动转换。在初始需求中定义的机器性能条件下，对于一个包含 50 个对象的设计模型，将其转换为相应代码框架时所消耗时间不超过 5 秒。
- 正常负载情况下，系统必须在 0.5 秒内对用户的查询请求进行响应
- 查询过程中涉及到的桥梁与公路的实时状态视频传输必须保证画面具有 1024*768 的分辨率，40 帧/秒的速率
- 系统应支持大于50个终端设备的并发请求;
- 独立事务操作响应时间应小于3s;
- 系统应能够实时识别车牌，识别时间应小于ls;
- 在正常负载情况下，系统应在0.5秒内对用户的商品查询请求进行响应;
- 系统在展示商品的实时视频时，需要保证视频画面具有1024X768 像素的分辨率，40帧/秒的速率:
- 在正常负载情况下，系统应该在0.2s内对用户的界面操作请求进行响应。
- 在正常负载情况下，用户的代码提交请求应在0.5s内完成。
- 系统应支持大于100个工业设备的进行检测
- 设备数据以制造现场传输到系统后台传输时间小于1S
- 在正常负载情况下，机器学习流程从提交到开始执行，时间间隔不大于5秒;
- 在正常负载情况下，平台应在0.5秒内对用户的界面操作请求进行响应;
错误示范（注意下面这样的不是性能的描述）
- 假设每秒中用户查询请求的数量是 10 个，处理请求的时间为 30 毫秒，则“在 1 秒 内完成用户的查询请求”这一要求是呵以实现的；
安全性
- 用户信息数据库授权必须保证 99.999%可用；
- 信用卡支付必须保证 99.999%的安全性；
- 用户的信用卡支付必须保证 99.999%的安全性；
- 用户信息数据库授权必须保证 99.999%可用；
- 系统能够抵御 99.999%的黑客攻击；
- 对用户信息数据的授权访问必须保证 99.999%的安全性；
- 系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测与防御；
- 对桥梁信息数据库的所有操作都必须进行完整记录；
- 可抵御常见SQL注入攻击:
- 系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测与防御;
- 系统应对用户信息数据库的所有操作都进行完整记录;
- 系统应该具备完善的安全防护措措施，能够对黑客的攻击行为进行检测和防御。
- 系统需要针对代码仓库的所有操作进行详细记录，便于后期查阅与审计。
- 可抵御见XSS攻击
- 支持数据审计
- 平台应该具备数据库保护措施，能够预防核心数据库被非授权用户访问;
- 平台需要对用户的所有操作过程进行详细记录，便于审计工作;
可用性
【注意没有可靠性，只有可用性】
- 网络失效后，系统需要在 1.5 分钟内发现错误并启用备用系统；
- 主站点断电后，需要在 3 秒内将访问请求重定向到备用站点；
- 网络失效后，系统需要在 2 分钟内发现错误并启用备用系统；
- 主站点断电后，需要在 3 秒内将访问请求重定向到备用站点；
- 网络失效后，系统需要在 2 分钟内发现并启用备用网络系统；
- 系统主站点断电后，需要在 3 秒内将请求重定向到备用站点；
- 能够连续运行的时间不小于 240 小时，意外退出后能够在 10 秒之内自动重启
- 网络失效后，系统需要在 10 秒内发现错误并启用备用系统
- 系统主站点断电后，必须在 3 秒内将请求重定向到备用站点
- 系统在故障情况下，应在1小时内恢复;
- 系统应7X24小时工作;
- 系统主站点断电后，应在5秒内将请求重定向到备用站点;
- 当系统发生网络失效后，需要在15秒内发现错误并启用备用网络;
- 系统主站点断电后应在3s内将请求重定向到备用站点。
- 系统宕机后，需要在15s 内发现错误，并启用备用系统。
- 系统应在7*24小时工作
- 系统在故障情况下，应在0.5小时内恢复
- 平台支持分布式部署，当主站点断电后，应在20秒内将请求重定向到备用站点;
- 平台主站点宕机后，需要在15 秒内发现错误并启用备用系统;
可修改性
- 需要在 20 人月内为系统添加一个新的 CORBA 中间件；
- 更改 Web 界面接口必须在 4 人周内完成；
- 需要在 30 人月内为系统添加公司新购买的事务处理中间件；
- 系统需要对 Web 界面风格进行修改，修改工作必须在 4 人月内完成；
- 在系统升级时，需要保证在 1 个月内添加一个新的消息处理中间件；
- 更改系统的 Web 界面接口必须在 1 周内完成；
- 集成开发环境具有模块化结构，支持以模块为单位进行调试、测试与发布（注意一点容易认为是可测试性的描述）
- 在系统升级时，必须保证在 10 人月内可添加一个新的消息处理中间件
- 更改系统的 Web 界面接口必须在 4 人周内完成；
- 系统要扩容时，应保证在10人月内完成所有的部署与测试工作;
- 更改系统的Web界面接口必须在4人周内完成;
- 系统支持硬件设备灵活扩容，应保证在2人天内完成。
- 更改系统web界面风格需要在4人天内完成。
- 平台部署后，针对界面风格的修改需要在3人天内完成:
- 平台支持硬件扩容与升级，能够在3人天内完成所有部署与测试工作;
可测试性
- 支持应用开发过程中的代码调试功能：开发人员可以设置断点，启动调试，编辑器可以自动卷屏并命中断点，能通过变量监视器查看当前变量取值。
易用性
- 经过调研，手机应用开发人员更倾向于使用 Windows 系统，因此集成开发环境的界面需要与 Windows 平台上的主流开发工具的界面风格保持一致。
- 新用户学习使用系统的时间少于1小时。
- 具有友好的用户界面;
错误示范（注意下面这样的不是易用性的描述）
- 支持用户通过配置界面依据自己的喜好修改界面风格，包括颜色、布局、代码高亮方式等，配置完成后无需重启环境
架构风险
- 目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模 块的重复，影响系统的可修改性；
- 现有架构设计中的支付部分与第三方支付平台紧耦合，当系统需要支持新的支付平台时，这种设计会导致支付部分代码的修改，影响系统的可修改性
- 目前对“车辆信息实时监控”业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性；
- 如果“养护报告生成”业务逻辑的描述尚未达成共识，可能导致部分业务功能模块规则的矛盾，影响系统的可修改性
敏感点
- 对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计；
- 对交易请求处理时间的要求将影响系统数据传输协议和交易处理过程的设计；.
- 对查询请求处理时间的要求将影响系统的数据传输协议和处理过程的设计；
- 对查询请求处理时间的要求将影响系统的数据传输协议和处理过程的设计
权衡点
- 更改加密的级别将对安全性和性能产生影响；
- 系统拟采用新的加密算法，这会提高系统安全性，但同时会降低系统的性能；
- 更改系统加密的级别将对安全性和性能产生影响
- 更改系统加密的级别将对安全性和性能产生影响
案例分析-数据库
什么是反规范化技术？其优缺点？
规范化设计后，数据库设计者希望牺牲部分规范化来提高性能，这种从规范化设计的回退方法称为反规范化技术。
采用反规范化技术的益处：降低连接操作的需求、降低外码和索引的数目，还可能减少表的数目，能够提高查询效率。
可能带来的问题：数据的重复存储，浪费了磁盘空间；可能出现数据的完整性问题，为了保障数据的一致性，增加了数据维护的复杂性，会降低修改速度。
常见的反规范化技术有哪些？
(1)增加冗余列：在多个表中保留相同的列，通过增加数据冗余减少或避免查询时的连接操作。
(2)增加派生列：在表中增加可以由本表或其它表中数据计算生成的列，减少查询时的连接操作并避免计算或使用集合函数。
(3)重新组表：如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。
(4)水平分割表：根据一列或多列数据的值，把数据放到多个独立的表中，主要用于表数据规模很大、表中数据相对独立或数据需要存放到多个介质上时使用。
(5)垂直分割表：对表进行分割，将主键与部分列放到一个表中，主键与其它列放到另一个表中，在查询时减少 I/O 次数
针对反规范化数据不一致问题可采用的解决方案有哪些？
1、触发器数据同步
2、应用程序数据同步
3、物化视图
或者说：批处理维护，应用逻辑，触发器
NOSQL数据库的优点/特点和缺点
NoSQL 数据库的哪些特点/优点
- NoSQL 数据库支持高并发数据访问，性能较高。
- NoSQL 数据库的数据存储结构松散，能够灵活支持多种类型的数据格式。
- NoSQL 数据库能够支持海量数据的存储，且易于横向扩展。
- NoSQL 数据库基于分布式数据存储，不存在单点故障和性能瓶颈，系统可用性高。
NoSQL 数据库的哪些缺点/可能存在的问题
- NoSQL 数据库的现有产品不够成熟，大多数产品处于初创期。
- NoSQL 数据库并未形成一定的标准，产品种类繁多，缺乏官方支持。
- NoSQL 数据库不提供对 SQL 的支持，学习和应用迁移成本较高。
- NoSQL 数据库支持的特性不够丰富，现有产品提供的功能比较有限。
使用 Memcached 代替数据库查询缓存的原因
Memcached 相比数据库查询缓存：
缓存架构：数据库缓存只是将查询结果进行缓存，适用面很窄，而 Memcached 是将数据库中的表进行缓存，对于在这些表之上的操作均可适用。
缓存有效性：Memcached 缓存时效较长，只要未更新，就属于有效状态，而数据查询缓存时效较短（具体时效与配置有关），所以在此方面 Memcached 有优势。
缓存数据类型：Memcached 缓存数据为表级，而数据库查询缓存为元组级
比较关系型数据库管理系统和文件系统
比较内存数据库和关系数据库
SQL 语句设计时影响查询效率的设计原则有哪些
- 查询时尽量不要返回不需要的行、列；
- 需要进行多表连接查询时，尽量使用连接查询，避免使用子查询结构；
- 尽量避免采用 NOT IN、NOT EXIST、LIKE 等使用全表查询的操作；
- 尽量避免使用 DISTINCT 关键字
Hibernate 框架的优点
(1)从移植的角度来看使用 Hibernate 更容易移植到其它数据库平台。 Hibernate 与具体数据库的关联只需在 XML 文件中配置即可，所有的 HQL 语句与具体 使用的数据库无关，移植性很好。MyBatis 项目中所有的 SQL 语句都是依赖所用的数 据库的，所以不同数据库类型的支持不好。
(2)使用 Hibernate 能降低或者消除 SQL 语句开发工作量，Hibernate 提供了方法完成持久层操作，程序员不需要对 SQL 的熟练掌握，便可完成任务。
(3)Hibernate 提供了对象状态管理的功能，使开发者不再需要理会底层数据库系统的细节，而 MyBatis 在这一块没有文档说明，用户需要对对象自己进行详细的管理
Hibernate 框架和Mybatis的区别
Mybatis 的着力点，则在于 POJO 与 SQL 之间的映射关系。然后通过映射配置文件， 将 SQL 所需的参数，以及返回的结果字段映射到指定 POJO。相对 Hibernate“O/R”而言， iBATIS 是一种“Sql Mapping”的 ORM 实现。
Hibernate 的调优方案
- 制定合理的缓存策略；
- 尽量使用延迟加载特性；
- 采用合理的 Session 管理机制；
- 使用批量抓取，设定合理的批处理参数（batch_size）;
- 进行合理的 O/R 映射设计
Mybatis 调优方案
MyBatis 在 Session 方面和 Hibernate 的 Session 生命周期是一致的，同样需要合理 的 Session 管理机制。MyBatis 同样具有二级缓存机制。 MyBatis 可以进行详细的 SQL 优化设计。
SQL 优化方面
Hibernate 的查询会将表中的所有字段查询出来，这一点会有性能消耗。Hibernate 也可 以自己写 SQL 来指定需要查询的字段，但这样就破坏了 Hibernate 开发的简洁性。而 Mybatis的 SQL 是手动编写的，所以可以按需求指定查询的字段。
Hibernate HQL 语句的调优需要将 SQL 打印出来，而 Hibernate 的 SQL 被很多人嫌弃因为太丑了。MyBatis 的 SQL 是自己手动写的所以调整方便。但 Hibernate 具有自己的日志统计。Mybatis 本身不带日志统计，使用 Log4j 进行日志记录。
扩展性方面
Hibernate 与具体数据库的关联只需在 XML 文件中配置即可，所有的 HQL 语句与具体使用的数据库无关，移植性很好。MyBatis 项目中所有的 SQL 语句都是依赖所用的数据库的，所以不同数据库类型的支持不好。
对象管理
Hibernate 是完整的对象/关系映射解决方案，它提供了对象状态管理（state management）的功能，使开发者不再需要理会底层数据库系统的细节。也就是说，相对于常见的JDBC/SQL 持久层方案中需要管理 SQL 语句，Hibernate 采用了更自然的面向对象的视角 来持久化 Java 应用中的数据。
换句话说，使用 Hibernate 的开发者应该总是关注对象的状态（state），不必考虑 SQL 语句的执行。这部分细节已经由 Hibernate 掌管妥当，只有开发者在进行系统性能调优的时候才需要进行了解。
而 MyBatis 在这一块没有文档说明，用户需要对对象自己进行详细的管理。
抓取策略
Hibernate 对实体关联对象的抓取有着良好的机制。对于每一个关联关系都可以详细地设置是否延迟加载，并且提供关联抓取、查询抓取、子查询抓取、批量抓取四种模式。它是 详细配置和处理的。 而 Mybatis 的延迟加载是全局配置的。
数据持久层不同的技术方案对应不同的实现技术有哪些？
- iBatis 是 apache 的一个开源项目，一个 O/R Mapping 解决方案，iBatis 最大的特点就是小巧，上手很快。如果不需要太多复杂的功能，iBatis 是能够满足你的要求又足够灵活的最简单的解决方案，现在的 iBatis 已经改名为 Mybatis 了。
- EJB 有 两 种 主 要 类 型 BMP(Bean managed persistence ) 和 CMP(Container managedpersistence),这两种类型各有优缺点。
- BMP 是在 Bean 中完成对数据库 JDBC 的各种调用，也就是说，在你的实体 bean(entity bean)中，明确写入了 SQL 语句，如"insert .. "或"select ..",并且使用 Datasource 获得一个数据库资源以及连接(connection)从而对数据库直接进行增加删除修改。
- CMP 是由 EJB 容器自动完成对数据库的操作，你所有做的，就是在实体 bean 重写入SetXXX 或 getXXX 方法，然后在 ejb-jar.xml 中定义 cmp-field 就可以。
- Hibernate 对数据库结构提供了较为完整的封装，Hibernate 的 O/R Mapping 实现了 POJO 和数据库表之间的映射，以及 SQL 的自动生成和执行。程序员往往只需定义好了 POJO 到 数据库表的映射关系，即可通过 Hibernate 提供的方法完成持久层操作。程序员甚至不需要对 SQL 的熟练掌握， Hibernate/OJB 会根据制定的存储逻辑，自动生成对应的 SQL 并调用 JDBC 接口加以执行。
数据库程序在线访问方式和 ORM 方式的优缺点
ORM，即 Object-Relationl Mapping，它在关系型数据库和对象之间作一个映射，这样， 我们在具体的操作数据库的时候，就不需要再去和复杂的 SQL 语句打交道，只要像平时操作对象一样操作即可。
数据库程序在线访问方式优点：
1、性能比 ORM 好
2、可以处理复杂查询语句
数据库程序在线访问方式缺点：
1、要求程序员懂 SQL 语句
2、修改与维护相对困难
ORM 优点：
1、使用 ORM 可以大大降低学习和开发成本。
2、程序员不用再写 SQL 来进行数据库操作。
3、减少程序的代码量。
4、降低由于 SQL 代码质量差而带来的影响。
ORM 缺点：
1、不太容易处理复杂查询语句。
2、性能较直接用 SQL 差。
数据访问层的优点
- 由于涉及到多种异构数据库平台，数据访问复杂性增加，不宜与业务逻辑混合在一起
- 数据管理变复杂之后，需要使用的代码量增加，分单独层次有利于让逻辑更清晰。
- 业务逻辑应以相同的方式应对异构的数据库，此时需要单独的数据访问层屏蔽差异性
请解释说明工厂模式在数据访问层中的应用
工厂模式分抽象工厂与工厂方法，场景适合采用抽象工厂设计模式。
抽象工厂设计模式提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定它们具体的类。其优点是可以非常方便的创建一系列的对象，其使用场景也是创建系列对象的情况，可以针对 Oracle、MySQL、SQLServer 分别建立抽象工厂，若指定当前工厂为 Oracle 工厂，则创建出来的数据库连接，数据集等一系列的对象都是符合 Oracle 操作要求的。这样便于数据库之间的切换
主从复制机制的优点
1、提升性能
交易平台要求高并发，主从复制方式一主多从，不同的用户请求可以从不同的从数据库读取数据，提高并发度。
2、可扩展性更优
如果采用单台数据库服务器，则访问量持续增加时，数据库瓶颈暴露，且无法迅速解决问题。而主从结构可以快速增加从服务器数量，以满足需求。
3、提升可用性
一主多从，一台从服务器出现故障不影响整个系统正常工作。
4、相当于负载均衡
一主多从分担任务，相当于负载均衡。
5、提升数据安全性
系统中的数据冗余存放多份，不会因为某台机器硬件故障而导致数据丢失
分布式数据库缓存的基本概念
分布式数据库缓存是一种将数据存储在分布式系统中，以提高数据库查询性能和吞吐量的技术。它通过在数据库和应用程序之间引入缓存层，将经常访问的数据存储在高速缓存中，以减少对数据库的频繁访问
比较MemCache 和 Redis 两种工具
Memcache存在数据可靠性和一致性的问题？
Memcache 不支持数据持久化操作，所以掉电数据会全部丢失，而且无法直接恢复，这存在可靠性问题，Memcache 不支持事务，所以操作过程中可能产生数据的不一致性。
Redis 与原有关系数据库的数据同步方案
读取数据时，先读取 Redis 中的数据，如果 Redis 没有，则从原数据库中读取，并同步更新 Redis 中的数据。写回时，写入到原数据库中，并同步更新到 Redis 中
请给出 Redis 分布式存储的 2 种常见方案和 Redis 集群切片的几种常见方式
Redis 分布式存储的 2 种常见方案：主从方案、Cluster 方案。
Redis 集群切片的几种常见方式：
1 、客户端分片：在客户端通过 key 的 hash 值对应到不同服务器。
2 、对数据根据 key 散列到不同的 slot 上，不同 slot 对应不同的服务器
使用缓存常见的问题有哪些？原因及其解决方案？
缓存雪崩
缓存雪崩是指在某个时间点，缓存中大量的数据同时失效或过期，导致大量请求直接访问底层数据源，从而造成数据库压力过大，甚至导致系统崩溃。
缓存雪崩的主要原因是缓存中的数据同时失效或过期，导致大量的请求无法从缓存中获取数据，只能直接访问底层数据源。这可能是由于缓存中的数据设置了相同的过期时间，或者由于缓存服务器故障导致缓存中的数据全部失效。
为了避免缓存雪崩，可以采取以下解决方案：
1. 设置合理的缓存过期时间：将缓存中的数据的过期时间错开，避免大量数据同时过期。可以采用随机的方式设置过期时间，或者根据业务特点和数据访问模式来动态调整过期时间。
2. 实施缓存预热：在系统启动或负载较低时，提前将一些热点数据加载到缓存中。通过缓存预热，可以在缓存失效时，仍然能够从缓存中获取部分数据，减轻对底层数据源的压力。
3. 实施缓存降级策略：当缓存失效或故障时，可以选择进行缓存降级，直接返回默认值或者空值，这一部分请求将不再继续访问数据库，从而减轻数据库压力
4. 监控和报警：建立缓存监控系统【选择适合的监控工具或平台，如Prometheus、Grafana、ELK等】，实时监测缓存的状态和性能。当发现缓存异常或失效时，及时触发报警并采取相应的应对措施。
缓存穿透
缓存穿透是指在缓存中无法找到所需数据，导致每次请求都需要直接访问底层数据源，从而增加了数据库的负载。缓存穿透通常发生在恶意请求或者无效的数据查询上。
缓存穿透的主要原因是请求的数据在缓存中不存在，但是频繁的请求导致每次都直接访问底层数据源。这可能是由于恶意攻击者故意发送无效的请求，或者由于业务逻辑错误导致查询无效的数据。
为了避免缓存穿透，可以采取以下解决方案：
1. 输入合法性验证：在请求进入系统之前，对请求参数进行合法性验证，过滤掉无效的请求。可以使用数据校验、黑白名单等方式来验证请求的合法性。
2. 布隆过滤器（Bloom Filter）：使用布隆过滤器来快速判断请求的数据是否存在于缓存中。布隆过滤器是一种空间效率高、误判率可控的数据结构，可以快速判断一个元素是否在集合中，从而避免无效的请求直接访问底层数据源。
3. 空值缓存：当查询的数据在底层数据源中不存在时，将空值缓存起来。这样，下次再有相同的查询请求时，可以直接从缓存中获取空值，避免无效的请求直接访问底层数据源。
缓存击穿
缓存击穿是指某个热点数据在缓存中失效或不存在，导致大量请求直接访问底层数据源，从而造成数据库压力过大，甚至导致系统崩溃。与缓存雪崩不同的是，缓存击穿通常只是针对某个特定的数据，而不是缓存中的所有数据。
缓存击穿的主要原因是热点数据在缓存中失效或不存在，导致大量的请求无法从缓存中获取数据，只能直接访问底层数据源。这可能是由于缓存中的数据过期或被删除
为了避免缓存击穿，可以采取以下解决方案：
1. 使用互斥锁（Mutex Lock）：在查询缓存数据之前，先获取一个互斥锁。当某个请求获取到锁时，其他请求需要等待，直到该请求完成并释放锁。这样可以避免多个请求同时访问底层数据源，保证只有一个请求去加载数据到缓存中。
2. 设置热点数据永不过期：对于一些热点数据，可以设置其永不过期，确保其一直存在于缓存中。这样即使缓存中的其他数据过期或失效，热点数据仍然可以被请求直接从缓存中获取，避免直接访问底层数据源。
3. 异步更新缓存：当热点数据过期时，可以异步地更新缓存，而不是等待请求到来时再去加载数据。通过异步更新缓存，可以减少请求直接访问底层数据源的情况，提高系统的性能和稳定性。
4. 使用分布式锁：在分布式环境中，可以使用分布式锁来保证只有一个请求去加载数据到缓存中。通过使用分布式锁，可以避免多个节点同时访问底层数据源，减轻数据库的负载压力。
缓存预热
缓存预热是指在系统启动或负载较低时，提前将一些热点数据加载到缓存中，以减少后续请求的响应时间和数据库的负载。
缓存预热的主要目的是通过预先加载热点数据到缓存中，使得系统在运行时可以直接从缓存中获取数据，而不需要去查询数据库或其他数据源，从而提高系统的性能和响应速度。
以下是一些常见的缓存预热策略：
1. 系统启动时预热：在系统启动时，可以利用后台任务或初始化方法将热点数据加载到缓存中。这样，在系统正式接收请求之前，缓存中已经有了一部分热点数据，可以提供更快的响应。
2. 定时预热：可以定时触发预热任务，定期将热点数据加载到缓存中。可以根据业务特点和数据访问模式来设置预热的时间间隔和频率。
3. 请求触发预热：当系统检测到某个数据即将成为热点数据时，可以在第一次请求到达时立即将该数据加载到缓存中。这种方式可以根据实际的请求情况动态地进行缓存预热。
缓存预热需要根据具体的业务需求和系统特点进行评估和决策。预热的数据量和策略应该根据系统的负载情况、数据的重要性和访问模式等因素进行调整。同时，需要注意预热过程可能会对系统的性能产生一定的影响，因此需要合理安排预热的时间和资源，避免影响正常的系统运行。
缓存降级
缓存降级是一种在缓存系统无法正常工作或出现异常情况时的应对策略。当缓存系统无法提供正常的服务时，为了保证系统的可用性和稳定性，可以选择进行缓存降级，即暂时停用缓存并直接访问底层数据源。
缓存降级的主要目的是保证系统的可用性，即使缓存系统出现故障或性能问题，仍然能够提供基本的功能和服务。当缓存不可用时，系统可以直接从数据库或其他数据源中获取数据，确保系统的正常运行。
缓存降级的实施可以根据具体情况采取不同的策略：
1. 直接访问数据库：当缓存不可用时，系统可以直接访问底层数据库获取数据。这种方式保证了数据的一致性，但可能会对系统的性能产生一定的影响。
2. 返回默认值或空值：当缓存不可用时，系统可以返回默认值或空值作为响应，以保证系统的正常运行。这种方式可以避免系统因缓存故障而完全无法提供服务。
3. 降级页面或功能：对于一些非关键的页面或功能，可以选择在缓存不可用时暂时关闭或降级，以减轻系统的负载和压力。
需要注意的是，缓存降级是一种权衡和应对策略，并不适用于所有场景。在实施缓存降级时，需要根据具体业务需求和系统特点进行评估和决策。同时，应该监控和及时修复缓存系统的故障，以恢复正常的缓存服务，提高系统的性能和稳定性。
比如可以参考日志级别设置预案
- 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
- 警告：有些服务在一段时间内成功率有波动（如在95~100%之间）， 可以自动降级或人工降级，并发送告警；
- 错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
- 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。
热点数据和冷数据
热点数据和冷数据是在数据管理和存储领域中常用的术语，用来描述数据的访问频率和热度。
- 热点数据（Hot Data）指的是经常被访问和使用的数据，具有较高的访问频率和热度。这些数据通常是对业务操作至关重要的数据，对系统性能和用户体验有较大的影响。为了提高系统的响应速度和效率，热点数据通常会被缓存到高速存储介质（如内存）中，以便快速访问。
- 冷数据（Cold Data）则是相对于热点数据而言的，指的是不经常被访问和使用的数据，具有较低的访问频率和热度。这些数据可能是历史数据、备份数据或不常用的业务数据。由于冷数据的访问需求较低，可以采用较廉价的存储介质（如磁盘）进行存储，以降低存储成本。
对于热点数据和冷数据的处理，可以采取不同的数据管理策略：
1. 热点数据缓存：将热点数据缓存在高速存储介质中，以提高访问速度和系统性能。常见的热点数据缓存技术包括Redis、Memcached等。
2. 数据分层：将数据按照访问频率和热度进行划分，将热点数据放在高性能存储层，将冷数据放在低成本存储层，以实现存储资源的优化。
3. 数据归档：对冷数据进行归档，将其移出主要存储系统，以减少存储压力和成本。归档的数据可以存储在离线存储介质（如磁带库）中，以备将来需要时进行恢复和访问。
什么是SQL注入攻击，并列举出两种抵御SQL注入攻击的方式。
SQL注入攻击:是黑客对数据库进行攻击的常用手段之一。随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL注入。
可以通过以下方式抵御SQL注入攻击:
1、使用正则表达式;
2、使用参数化的过滤性语句;
3、检查用户输入的合法性;
4、用户相关数据加密处理;
5、存储过程来执行所有的查询;
6、使用专业的漏洞扫描工具。
请说明关系型数据库开发中,逻辑数据模型设计过程包含哪些任务?
逻辑结构设计阶段的主要任务是确定数据模型、将ER图转换成指定数据模型、确定完整性约束、确定用户视图。
Redis的三种内存淘汰机制
三种内存淘汰机制:随机、近期最少使用LRU、最不经常使用LFU
对比RDB备份和AOF备份的区别
- 磁盘刷新频率：
-
- RDB备份：RDB备份是通过将内存数据保存到磁盘上的二进制文件中，它可以根据配置的刷新频率定期执行。默认情况下，RDB备份是在每次有新数据写入时执行。
- AOF备份：AOF备份是通过将每个写操作以追加的方式记录到一个日志文件中，因此它的磁盘刷新频率要比RDB备份更高。
- 文件大小：
-
- RDB备份：RDB备份生成的文件大小通常比AOF备份小，因为它只保存了一个时间点的数据快照。
- AOF备份：AOF备份文件通常比RDB备份文件大，因为它记录了每个写操作的完整日志。
- 重启性能：
-
- RDB备份：RDB备份在数据库重启时可以快速加载整个数据快照文件，因为它只需要读取一个文件并将其加载到内存中。
- AOF备份：AOF备份在数据库重启时需要将所有写操作从日志文件中重新执行一遍，这可能需要较长的时间，特别是对于大型日志文件。
- 数据安全：
-
- RDB备份：RDB备份是一个紧凑的二进制文件，数据在备份过程中相对较安全，因为它不会受到写操作的影响。
- AOF备份：AOF备份是一个追加日志文件，如果在写操作过程中出现错误或意外关闭数据库，可能会导致数据损坏。
Redis常见数据结构的使用场景
说明解决Redis和MySQL数据实时同步问题的常见方案
一、引用Mysql的事务，因为事务有一致性保证，事务提交成功后再更新缓存。
二、在缓存里面引用一些访问控制位，数据库数据变化后，同步变更对应的访问控制位，然后从缓存查询时，率先判断该访问控制位，有变化就从数据库查,无变化直接从缓存返回数据。
三、通过数据库中间件产品保证缓存和数据库数据时时同步
采用标准的数据访问机制的原因
标准的数据访问机制可以屏蔽不同通信协议的差异，为应用程序提供一个统一的接口,从而实现多种不同设备之间的数据交互。
案例分析-Web系统设计
表现层状态转换(REST)是？ REST 中将哪三种关注点进行分离？
REST 从资源的角度来定义整个网络系统结构，分布在各处的资源由统一资源标识符 (URI)确定，客户端应用程序通过 URI 获取资源的表现，并通过获得资源表现使得其状态发生改变。
REST 中将资源、资源的表现和获取资源的动作三者进行分离
完成一次分布式对象调用的详细步骤
一次远程调用的过程如下：
① 客户程序将调用请求发送给客户端桩，对于客户程序来说，桩就是服务程序在客户端的代理。
② 客户端桩负责将远程调用请求进行编组并发送给通信总线。
③ 调用请求经通信总线传送到服务端框架。
④ 服务端框架将调用请求解组并分派给真正的远程对象实现(服务程序)。
⑤ 服务程序完成客户端的调用请求，将结果返回给服务端框架。
⑥ 服务端框架将调用结果编组并发送给通信总线。
⑦ 调用结果经通信总线传送到客户端桩。
⑧ 客户端桩将调用结果解组并返回给客户程序，客户程序得到调用结果。
MVC 架构风格
MVC 架构风格是什么
MVC 架构风格：用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
MVC 模式的作用
(1)允许多种界面的扩展，视图的变更与增加，与模型无关；
(2)易于维护，控制器和视图随着模型的扩展而扩展，只要保持公共接口，控制器和视图的旧版本可以继续使用；
(3)可支持功能强大的用户界面
MVC 架构的组件交互关系
MVC 架构将整个软件系统划分为模型、视图和控制器 3 个部分。模型负责维护并保存具有持久性的业务数据，实现业务处理功能，并将业务数据的变化情况及时通知视图；视图负责呈现模型中包含的业务数据，响应模型变化通知，更新呈现形式，并向控制器传递用户的界面动作；控制器负责将用户的界面动作映射为模型中的业务处理功能并实际调用之，然后根据模型返回的业务处理结果选择新的视图。
MVC 架构中包含哪三种元素，它们的作用分别是什么?
MVC 架构包含：视图、控制器、模型
视图（View）：视图是用户看到并与之交互的界面。视图向用户显示相关的数据，并 能接收用户的输入数据，但是它并不进行任何实际的业务处理。
控制器（Controller）：控制器接受用户的输入并调用模型和视图去完成用户的需求。 该部分是用户界面与 Model 的接口。一方面它解释来自于视图的输入，将其解释成为系统能够理解的对象，同时它也识别用户动作，并将其解释为对模型特定方法的调用；另一方面，它处理来自于模型的事件和模型逻辑执行的结果，调用适当的视图为用户提供反馈。
模型（Model）：模型是应用程序的主体部分。模型表示业务数据和业务逻辑。一个模型能为多个视图提供数据。
基于 JavaEE 的 MVC 模式设计资源共享平台的软件架构
DNS 的负载均衡机制和基于反向代理的负载均衡机制
基于 DNS 的负载均衡的基本原理
基于 DNS 的负载均衡是在 DNS 服务器中为同一个主机名配置多个 IP 地址，在应答DNS 查询时，DNS 服务器对每个查询将以 DNS 文件中主机记录的 IP 地址按顺序返回不同的解析结果，将客户端的访问引导到不同的节点上去，使得不同的客户端访问不同的节点，从而达到负载均衡的目的。
基于反向代理负载均衡的基本原理
反向代理负载均衡。反向代理负载均衡是将来自 Internet 上的连接请求以反向代理的方式动态地转发给内部网络上的多个节点进行处理，从而达到负载均衡的目的。
什么是数据持久层？数据持久层的好处是什么？
什么是数据持久层？
数据持久层是一组软件服务，将应用程序与该程序所使用的数据源分离，为整个项目提供一个统一、安全、并发的数据持久机制。
数据持久层的好处是什么？
1、程序代码重用性强，即使更换数据库，只需要更改配置文件，不必重写程序代码。
2、业务逻辑代码可读性强，在代码中不会有大量的 SQL 语言，提高程序的可读性。
3、持久化技术可以自动优化，以减少对数据库的访问量，提高程序运行效率。
4、简化开发工作，让开发人员更关注于业务逻辑的开发。
5、通过对象/关系映射向业务逻辑提供面向对象的数据访问
比较PHP和Java
1、PHP 只能实现简单的分布式两层或三层的架构，而 JAVA 在这方面就比较强大，可以实现多层的网络架构。数据库层(持久化层)、应用(业务)逻辑层、表示逻辑层彼此分开，而且现在不同的层都已经有一些成熟的开发框架的支持。
2、PHP 是面向过程的语言，Java 是面向对象的，面向过程语言开发的程序只要业务流程发生变化，修改工作量很大，所以可修改性差，同时可复用性也差。
3、PHP 语言在可靠性方面比 J2EE 平台差，J2EE 平台有大量增强可靠性的成熟解决方案，而 PHP 只是一种简单的脚本语言，在可靠性方面缺乏成熟解决方案。
4、PHP 对于不同的数据库采用不同的数据库访问接口，而 Java 通过 JDBC 来访问数据库，通过不同的数据库厂商提供的数据库驱动方便地访问数据库，访问数据库的接口比较统一。所以原架构在数据库连接方面修改起来工作量也是很大的。
5、PHP 适合于小型项目，所以本项目中以前采用 PHP 是合适的，但目前大量功能需要增加，PHP 在稳定性方面也达不到要求。
5、PHP 比 Java 的可维护性差。
7、PHP 比 Java 的扩展性差。
8、PHP 比 Java 的安全性差。
应用服务器的概念并重点说明应用服务器如何来保障系统在大负荷和长时间运行下的稳定性以及可扩展性
应用服务器是指通过各种协议把商业逻辑曝露给客户端的程序。
1、若系统负荷很大，可以布署多台应用服务，多台应用服务器分担任务，以达到性能要求。
2、应用服务器可以通过灵活的增加服务器完成扩展，所以可扩展性很好。
3、应用服务器可长时间稳定运行。因为当一台应用服务器出现故障时，可以将当前运行的事务转移至正常应用服务器上完成执行，不影响业务正常执行，从而保障高可靠性与稳定性。
J2EE 的 N 层体系结构示意图
说明 EJB 构件中的 Bean(构件)分为哪三种类型，每种类型 Bean 的职责是什么？
EJB 中的 Bean 分三种类型：Session Bean(会话 Bean)、Entity Bean(实体 Bean) 和 Message-Driven Bean(消息驱动 Bean)。
Session Bean 的职责是：维护一个短暂的会话。
Entity Bean 的职责是：维护一行持久稳固的数据。
Message-Driven Bean 的职责是：异步接受消息
有状态和无状态Bean/构件
(a) IdentificationBean(身份认证构件) ---有状态
(b) ResPublishBean(资源发布构件) ---有状态
(c) ResRetrievalBean(资源检索构件) ---无状态
(d) OnlineEditBean(在线编辑构件) ---有状态
(e) StatisticsBean(统计分析构件)---无状态
扩展：无状态的 Bean 适合用不变模式，技术就是单例模式，这样可以共享实例，提高性能。有状态的 Bean，多线程环境下不安全，那么适合用 Prototype 原型模式
什么是“响应式 Web 设计”？响应式 Web 设计的实现方式有哪些？
响应式 web 设计是指我们设计与开发的页面可以根据用户的行为和不同的设备环境做
响应式 web 设计是指我们设计与开发的页面可以根据用户的行为和不同的设备环境做出相应的响应来调整页面的布局，以提供用户可感知的、流畅的阅读和操作体验。
实现方式：
（1）流式布局(flex)
（2）弹性布局加媒体查询(@media screen an (min-width:768px){})
操作性需求、性能需求、 安全性需求和文化需求的含义
- 性能需求(Performance Requirements)：指响应时间、吞吐量、准确性、有效性、资源利用率等与系统完成任务效率相关的指标。可靠性、可用性等指标可归为此类。
-
- 用户操作的响应时间应不大于 3 秒，竞拍板块不大于 1 秒；
- 系统需要支持不低于 2G 的数据缓存
- 安全性需求(Security Requirements)：系统向合法用户提供服务并阻止非授权用户使用服务方面的系统需求。
-
- 用户密码需要加密传输；
- 用户操作停滞时间超过一定时限需要重新登录验证；
- 操作性需求(Operational Requirements)：与用户操作使用系统相关的一些需求。
-
- 系统需要支持当前主流的标准和服务，特别是通信协议和平台接口
- 系统具有故障诊断和快速恢复能力；
- 文化需求(Cultural Requirements)：带有文化背景因素的系统需求
-
- 用户界面支持用户的个性化定制
- 系统支持用户选择汉语、英语或法语三种语言之一进行操作
分布式架构设计图
TCP和UDP通信协议的不同
TCP在IP协议提供的不可靠数据服务的基础上，采用了重发技术，为应用程序提供了一个可靠的、面向连接的、全双工的数据传输服务。TCP协议一般用于传输数据量比较少，且对可靠性要求高的场合。
UDP是一种不可靠的、无连接的协议，可以保证应用程序进程间的通信，与TCP相比,UDP是一种无连接的协议，它的错误检测功能要弱得多。
案例分析-信息安全
分别针对采用对称加密策略与公钥加密策略，说明如何利用加密技术为在网络中传输的数据提供机密性与完整性保障
对称加密策略
(1)机密性：发送者利用对称密钥对要发送的数据进行加密，只有拥有正确相同密钥的接收者才能将数据正确解密，从而提供机密性。
(2)完整性：发送者根据要发送的数据生成消息认证码(或消息摘要)，利用对称密钥对消息认证码进行加密并附加到数据上发送；接收者使用相同密钥将对方发送的消息认证码解密，并根据接收到的数据重新生成消息认证码，比较两个认证码是否相同以验证数据的完整性。
公钥加密策略
(1)机密性：发送者利用接收者的公钥对要发送的数据进行加密，只有拥有对应私钥的 接收者才能将数据正确解密，从而提供机密性。
(2)完整性：发送者根据要发送的数据生成消息认证码(或消息摘要)，利用自己的私钥对消息认证码进行加密并附加到数据上发送；接收者利用对方的公钥将对方发送的消息认证码解密，并根据接收到的数据重新生成消息认证码，比较两个认证码是否相同以验证数据的完整性。
基于角色的访问控制(RBAC)与可扩展访问控制标记语言(XACML)相结合的机制的优点
(1)授权的可管理性：RBAC 将用户与权限分离，与 MAC 相比，减小了授权管理的复杂性，更适合于大型企业级系统的安全管理。
(2)细粒度访问控制的支持：XACML 提供了统一的访问控制策略描述语言，策略表达能力强，可用来描述各种复杂的和细粒度的访问控制安全需求，更适合企业复杂业务功能的访问控制要求。
(3)分布式环境的支持：XACML 的标准性便于各子系统的协作交互，各子系统或企业业务部门可以分布管理访问控制权限，而 MAC 则通常需要对访问控制权限集中管理，不太适合企业基于 SOA 集成后的分布式系统。
目前数据库管理系统提供的基本数据加密方式主要包括加解密 API 和透明加密两种
目前数据库管理系统提供的基本数据加密支持主要有以下两种：
（1）加解密 API：数据库管理系统提供可在 SQL 语句中调用的加解密 API，应用可以利用这些 API 构建自己的基础架构，对数据进行加密保护。
（2）透明加密：安全管理员为数据库敏感字段选择加密方式及密钥强度，应用访问受保护数据时只需使用口令打开或关闭密钥表，对数据的加密和解密由数据库管理系统自动完
成。
总结：加解密 API 方式的灵活性强，但构建和管理复杂；而透明加密方式管理简单，应用程序负担轻，但灵活性较差。
列举 3 种可实现信息系统安全保障的措施
- 釆用挑战/应答的认证机制，防止重放攻击。
- 釆用加密技术保证信息在网络传输过程的安全。
- 釆用数字签名技术保证信息传输过程的完整性和不可否认
信息系统面临哪些方面的安全威胁并分别予以简要描述
- 信息系统面临的安全威胁来自于物理环境、通信链路、网络系统、操作系统、应用系统以及管理等多个方面。
- 物理安全威胁是指对系统所用设备的威胁，如自然灾害、电源故障、数据库故障和设备被盗等造成数据丢失或信息泄漏。
- 通信链路安全威胁是指在传输线路上安装窃听装置或对通信链路进行干扰。
- 网络安全威胁当前主要是指由于因特网的开放性、国际性与无安全管理性，对内部网络形成的严重安全威胁。
- 操作系统安全威胁指的是操作系统本身的后门或安全缺陷，如“木马”和“陷阱门”等。
- 应用系统安全威胁是指对于网络服务或用户业务系统安全的威胁，包括应用系统自身漏洞，也受到“木马”的威胁。
- 管理系统安全威胁指的是人员管理和各种安全管理制度。
描述主要的认证方式
目前主要的认证方式有三类：
(1)用户名和口令认证：主要是通过一个客户端与服务器共知的口令(或与口令相关的数据)进行验证。根据处理形式的不同，分为验证数据的明文传送、利用单向散列函数处理验 证数据、利用单向散列函数和随机数处理验证数据。
(2)使用令牌认证：该方式中，进行验证的密钥存储于令牌中，目前的令牌包括安全证书和智能卡等方式。(3)生物识别认证：主要是根据认证者的图像、指纹、气味和声音等作为认证数据。根据该企业的业务特征，采用令牌认证较为合适。
请解释授权侵犯的具体含义？针对防止授权侵犯和保留用户痕迹的要求给出相应的解决方案？说明该解决方案的名称、 内容和目标？
授权侵犯指的是被授权以某一目的使用某一系统或资源的某个人，将此权限用于其他非授权的目的，也称作“内部攻击”。
从系统安全架构设计的角度需要提供抗抵赖框架。
抗抵赖服务包括证据的生成、验证和记录，以及在解决纠纷时随即进行的证据恢复和再次验证。
框架中抗抵赖服务的目的是提供有关特定事件或行为的证据。例如，必须确认数据原发者和接收者的身份和数据完整性，在某些情况下，可能需要涉及上下文关系(如日期、时间、原发者/接收者的地点等)的证据等等。
REST 从资源的角度来定义整个网络系统结构，分布在各处的资源由统一资源标识符
(URI)确定，客户端应用程序通过 URI 获取资源的表现，并通过获得资源表现使得其状态发
生改变。
REST 中将资源、资源的表现和获取资源的动作三者进行分离
案例分析-系统建模
数据流图(Data Flow Diagram)的基本元素及其作用
数据流：数据流是数据在系统内传播的路径，因此由一组成分固定的数据组成。
外部实体：代表系统之外的实体，可以是人、物或其他软件系统。
加工（处理）：加工是对数据进行处理的单元，它接收一定的数据输入，对其进行处理， 并产生输出。
数据存储：表示信息的静态存储，可以是文件、文件的一部分、数据库的元素等。
状态图和活动图的含义及其区别
状态图主要用于描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件(event)，以及因状态转移而伴随的动作(action)。
活动图可以用于描述系统的工作流程和并发行为。活动图其实可看作状态图的特殊形式，活动图中一个活动结束后将立即进入下一个活动(在状态图中状态的转移可能需要事件的触发)。
两者最大的区别是：状态图侧重于描述行为的结果，而活动图侧重描述行为的动作。其次活动图可描述并发行为，而状态图不能
用例之间的关系有哪几种类型？
用例之间的关系包括：包含、扩展、泛化。
“登录系统”用例与“注册课程”用例之间的关系为：包含关系。
“参加考试”用例与“参加补考”用例之间的关系为：扩展关系。
类之间的关系有哪几种类型？
类之间的关系包括：关联、聚合、组合、依赖、泛化、实现(可写可不写，因为实现是接口与类之间的关系，而接口是一种特殊的类)
类 University 与类 Student 之间的关系是：聚合关系(整体与部分的关系，整体与部分可以分开，生命周期不同，因为 Student 不仅在高校，也可以在小学等)。
类 University 与类 Department 之间的关系是：组合关系(也是整体与部分的关系，但是整体与部分不可以分开，生命周期相同，题目中的系一般只有高校才有)。
类 Student 与类 Course 之间的关系是：关联关系。
比较信息工程方法中的“实体(entity)” 与面向对象方法中的“类(class)”
实体用于数据建模，而类用于面向对象建模。实体只有属性，而类有属性和操作。
Essential Use Cases 和 Real Use Cases 有哪些区别?
Essential Use Cases(抽象用例)，Real Use Cases(基础用例)，这两者的区别为：基础用例是实实在在在与用户需求有对应关系的用例，是从用户需求获取的渠道得到的，而抽象用例是从基础用例中抽取的用例的公共部分，是为了避免重复工作，优化结构而提出的用例。
数据流图和系统流程图之间有哪些方面的区别
(1)数据流图中的处理过程可并行;系统流程图在某个时间点只能处于一个处理过程。
(2)数据流图展现系统的数据流;系统流程图展现系统的控制流。
(3)数据流图展现全局的处理过程，过程之间遵循不同的计时标准;系统流程图中处理过程遵循一致的计时标准。
请说明什么是派生属性?请说明什么是超类实体?
派生属性可以由其他属性计算获得，派生属性用于存储计算结果值。例如:资费、总计。
超类实体由多个实体中所共有的属性组成。
流程图与数据流图的含义及其区别
数据流图作为一种图形化工具，用来说明业务处理过程、系统边界内所包含的功能和系 统中的数据流。
流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程，描述 处理过程的控制流。
两者的区别主要包括：
(1)数据流图中的处理过程可并行；流程图在某个时间点只能处于一个处理过程。
(2)数据流图展现系统的数据流；流程图展现系统的控制流。
(3)数据流图展现全局的处理过程，过程之间遵循不同的计时标准；流程图中处理过程遵循一致的计时标准。
(4)数据流图适用于系统分析中的逻辑建模阶段；流程图适用于系统设计中的物理模阶段
设计高质量的数据流图时应考虑的三个原则
高质量数据流图设计时应考虑的三个原则：
(1)复杂性最小化原则。DFD 分层结构就是把信息划分为小的且相对独立的一大批子集 例子，这样就可以单独考查每一个 DFD。如果要了解某个过程更加详的信息，可以跳转到该过程的下一层；如果要知道一个 DFD 如何与其他 DFD 相关联，可以跳转到上一层的 DFD 进行考查。
(2)接口最小化原则。接口最小化是复杂性最小化的一种具体规则。在设计模式时，应使得模型中各个元素之间的接口数或连接数最小化。
(3)数据流一致性原则。一个过程和它的过程分解在数据流内容中是否有差别？是否存在有数据流出但没有相应的数据流入的加工？是否存在有数据流入但没有相应的数据流出的加工？
案例分析-软件架构风格
比较管道—过滤器风格和数据仓储风格
面向服务架构(SOA)是什么？ ESB 在 SOA 中的作用与特点？
面向服务架构(SOA)是什么？
面向服务的架构（SOA)是一个组件模型，它将应用程序的不同功能单元（称为服务） ，通过 这些服务之间定义良好的接口和契约联系起来。接口是釆用中立的方式进行定义的， 它应该 独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
企业服务总线（ESB）是什么？
企业服务总线（ESB）是一种用于集成企业内部系统和应用程序的中间件架构。它充当了企业内部系统之间的通信桥梁，通过提供统一的接口和协议，实现了不同系统之间的数据传输和交互。ESB的目标是简化企业内部系统的集成过程，提高系统之间的互操作性和灵活性。
ESB采用了面向服务的架构（SOA），将企业内部的各个系统和应用程序抽象为服务，通过ESB进行服务之间的通信和交互。ESB提供了一套标准化的接口和协议，使得系统之间的集成更加简单和可靠。通过ESB，企业可以将现有的系统和应用程序进行重用，避免了重复开发和维护的工作。
ESB 在 SOA 中的作用与特点？
- 支撑 SOA 的关键是其消息传递架构-企业服务总线（ESB)。ESB 用于实现企业应用不同消息和信息的准确、高效和安全传递。
- 面向服务的元数据管理：他必须了解被他中介的两端，即服务的请求以及请求者对服务的要求，以及服务的提供者和他所握供的服务的描述；
- 通信：服务的发布/订阋、响应/请求、同步/异步消息、路由和寻址等；
- 服务交互：服务接口定义，服务实现的置换，服务消息模型，服务目录和发现等；
- 服务安全：认证和授权、不可否认和机密性、安全标准的支持等
什么是软件架构风格？面向对象和控制环路两种架构风格各自的特点
软件架构风格是描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。
- 面向对象架构风格的特征是将数据表示和基本操作封装在对象中。这种模式的构件是对 象，对象维护自身表示的完整性，对象之间通过消息机制进行通信，对象交互时需要知道彼 此的标识，通过对象之间的协作完成计算过程。
- 控制环路架构风格是将过程输出的指定属性维护在一个特定的参考值(设定点)。控制环路风格包括过程变量、被控变量、输入变量、操纵变量和设定点等构件，通过收集实际和理想的过程状态信息，并能调整过程变量使得实际状态趋于理想状态。
