(一)软件质量属性
- 性能:系统响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理事件的个数
- 查询过程中涉及到的桥梁与公路的实时状态视频传输必须保证画面具有1024x768的分辨率,40帧/秒的速率;
- 可用性:系统能够正常运行的时间比例
- 可靠性:软件系统在应用或错误面前,在意外或者错误使用的情况下维持软件系统功能特性的基本能力
- 健壮性:在处理或环境中,系统能够承受压力或变更的能力
- 安全性:系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力
- 可修改性:能够快速地以较高的性能价格比对系统进行变更的能力
- 系统要扩容时,应保证在10人·月内完成所有的部署与测试工作
- 更改系统的Web界面接口必须在4人周内完成
- 支持用户通过配置界面依据自己的喜好修改界面风格,包括颜色、布局、代码高亮方式等,配置完成后无需重启环境
- 可变性:系统结构经扩充或变更成为新体系结构的能力
- 易用性:衡量用户使用一个软件产品完成指定任务的难易程度
- 友好的用户界面
- 可测试性:软件发现故障并隔离、定位其故障的能力特性,以及在一定的时间和成本前提条件下,进行测试设计、测试执行的能力
- 集成开发环境具有模块化结构,支持以模块为单位进行调试、测试与发布
- 功能性:系统所能完成所期望工作的能力
- 互操作性:系统与外界或系统与系统之间的相互作用能力
架构设计策略
- 性能:增加计算资源、改善资源需求(减少计算复杂度等)、资源管理(并发、数据复制等)和资源调度(先进先出队列、优先级队列等)
- 安全性:抵御攻击(授权、认证和访问限制等)、攻击检测(入侵检测等)、从攻击中恢复(部分可用性策略)和信息审计等
- 可用性:Ping/Echo、心跳、异常和主动冗余等
- 可修改性:软件模型泛化、限制模块之间通信、使用中介和延迟绑定等
(二)风险,敏感点,权衡点
- 风险:架构设计中潜在的、存在问题的架构决策所带来的隐患。
- eg:如果“养护报告生成”业务逻辑的描述尚未达成共识,可能导致部分业务功能模块规则的矛盾,影响系统的可修改性
- 敏感点:为了实现某种特定的质量属性,一个或多个构件所具有的特性。
- eg:对查询请求处理时间的要求(性能)将影响系统的数据传输协议和处理过程的设计;
- 权衡点:影响多个质量属性的特性,是多个质量属性的敏感点。
- eg:更改系统加密的级别将对安全性和性能产生影响;
二、结构化软件系统建模
(一)流程图和数据流图
含义及其区别
数据流图:一种图形化工具,用来说明业务处理过程、系统边界内所包含的功能和系统中的数据流。
- 数据流:数据流是数据在系统内传播的路径,因此由一组成分固定的数据组成。
- 外部实体:代表系统之外的实体,可以是人、物或其他软件系统。
- 加工(处理) :加工是对数据进行处理的单元,它接收一定的数据输入, 对其进行处理,并产生输出。
- 数据存储:表示信息的静态存储,可以是文件、文件的一部分、数据库的元素等。
流程图:图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程,描述处理过程的控制流。
两者的区别主要包括:
- 数据流图中的处理过程可并行;流程图在某个时间点只能处于一个处理过程
- 数据流图展现系统的数据流;流程图展现系统的控制流
- 数据流图展现全局的处理过程,过程之间遵循不同的计时标准;流程图中处理过程遵循一致的计时标准
- 数据流图适用于系统分析中的逻辑建模阶段;流程图适用于系统设计中的物理建模阶段
数据流图存在的错误
- “分类训练”加工:只有输入没有输出,产生数据黑洞
- “分类处理"加工:有输出没有输入,无中生有
- “规则文件"数据流:外部实体没有经过加工处理,直接到数据存储
- “配置信息”数据流:外部实体之间没有加工处理,存在直接数据流
解析:数据流图中常见的错误分为两种类型:一类是语法错误 ,包括外部实体之间、数据存储之间或外部实体与数据存储之间不经过加工而存在直接数据流;另一类是逻辑错误,包括数据黑洞(只有输入没有产生输出)、灰洞 (输入不足以产生输出)和无输入。
以上的为0层和1层数据流图,画出0层数据流图
设计高质量的数据流图应考虑的三个原则
- 复杂性最小化原则。DFD分层结构就是把信息划分为小的且相对独立的一大批子集例子,这样就可以单独考查每一个DFD。如果要了解某个过程更加详细的信息,可以跳转到该过程的下一层;如果要知道一个DFD如何与其他DFD相关联,可以跳转到上一层的DFD进行考查
- 接口最小化原则。是复杂性最小化的一种具体规则。在设计模式时,应使得模型中各个元素之间的接数或连接数最小化
- 数据流一致性原则。 一个过程和它的过程分解在数据流内容中是否有差别?是否存在有数据流出但没有相应的数据流入的加工?是否存在有数据流入但没有相应的数据流出的加工?
(二)实体和类的区别
实体用于数据建模,而类用于面向对象建模。实体只有属性,而类有属性和操作。
(三)Essential Use Cases和Real Use Cases
Essential Use Cases 可翻译为抽象用例,Real Use Cases 可翻译为基础用例。
他们是区别在于:
- Essential Use Cases 用于分析阶段,Real Use Cases 用于设计阶段。
- Essential Use Cases 描述用例的本质属性,它与如何实现这个用例无关,独立于实现该用例的软硬件技术。
- Real Use Cases 描述的是用例的实现方式,表达了设计和实现该用例时所采用的方法和技术。
(四)状态图和活动图
状态图:描述一个对象在其生存期间的动态行为,表现一个对象所经历的状态序列,引起状态转移的事件(event),以及因状态转移而伴随的动作(action)。
活动图:描述系统的工作流程和并发行为,可看作状态图的特殊形式,活动图中一个活动结束后将立即进入下一个活动(在状态图中状态的转移可能需要事件的触发)。
两者最大的区别是:状态图侧重于描述行为的结果,而活动图侧重描述行为的动作。其次活动图可描述并发行为,而状态图不能。
(五)用例建模
用例参与者
指系统以外的,需要使用系统或与系统交互的事物,包括:人或组织、设备、外部系统等
如:每个月到了月底系统会通过打印机打印学生的考勤信息。参与者有:时间、打印机
用例之间的关系:包含、扩展、泛化
类之间的关系:关联、聚合、组合、依赖、泛化(继承)、实现(类与接口)
关联和依赖:一个类A用到了另一个类B,关联比比依赖关系强,必然的,长期的,强烈的
聚合和组合:整体和部分,聚合整体和部分可分离,组合整体和部分不可分离
三、软件系统架构选择
(一)能写的架构风格-论文
面向对象的架构风格:显式调用。构件是对象,对象是抽象数据类型的实例。在抽象数据类型中,数据的表示和它们的相应操作被封装起来,对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式,对象是通过函数和过程的调用来交互的
层次结构风格(C/S,B/S,MVC):构件组织成一个层次结构,连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务,使用下一层的服务,只能见到与自己邻接的层。通过层次结构,可以将大的问题分解为若干个渐进的小问题逐步解决,可以隐藏问题的复杂度。修改某一层,最多影响其相邻的两层(通常只能影响上层)
进程通信:独立构件。构件是独立的过程,连接件是消息传递。构件通常是命名过程,消息传递的方式可以是点对点、异步或同步方式,以及远程过程(方法)调用等
事件驱动系统(消息中间件):隐式调用。构件不直接调用一个过程,而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册,当某个事件被触发时,系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程,它们之间交互的连接件往往是以过程之间的隐式调用来实现的。主要优点是为软件复用提供了强大的支持,为构件的维护和演化带来了方便;其缺点是构件放弃了对系统计算的控制
(二)什么是软件架构风格,面向对象和控制环路两种架构各自风格的特点
软件架构风格是描述某一类特定应用领域中软件系统组织方式的惯用方式。
面向对象架构风格:将数据表示和基本操作封装在对象中。这种模式的构件是对象,对象维护自身表示的完整性,对象之间通过消息机制进行通信,对象交互时需要知道彼此的标识,通过对象之间的协作完成计算过程。
控制环路架构风格:将过程输出的指定属性维护在一个特定的参考值 (设定点) 。控制环路风格包括过程变量、被控变量、 输入变量、操纵变量和设定点等构件,通过收集实际和理想的过程状态信息,并能调整过程变量使得实际状态趋于理想状态。
面向对象系统比较适合事件驱动的场景,特别是离散突发事件的处理;控制环路则适合连续事件的处理,比如恒定车速等
(三)主程序-子程序 和 管道-过滤器 这两种架构风格的特点
主程序-子程序架构风格中,所有的计算构件作为子程序协作工作,并由一个主程序顺序地调用这些子程序,构件通过共享存储区交换数据。
管道-过滤器架构风格中,每个构件都有一组输入和输出, 构件接受数据输入,经过内部处理,然后产生数据输出。这里的构件称为过滤器,构件之间的连接件称为数据流传输的管道。
共享数据的主-子程序 | 管道-过滤器 | |
算法变更 | - | + |
功能变更 | - | + |
数据表示变更 | - | - |
性能 | +,程序处于紧耦合的状态 | - |
(四)面向对象和基于规则
灵活性 | 可扩展性 | 性能 | |
面向对象 | 将用户级别,折扣规则等封装为对象,在系统启动时加载 | (2)加入新的用户级别和折扣规则时需要重新定义新的对象,并需要重启系统 | (3)用户级别和折扣规则已经在系统内编码,可直接运行,性能较好。 |
基于规则 | (1)将用户级别、折扣规则等描述为可动态改变的规则数据 | 加入新的用户级别和 折扣规则时只需要定 义新的规则,解释规 则即可进行扩展 | 需要对用户级别与 折扣规则进行实时 解释、性能较差 |
(五)管道过滤器和数据仓库
管道过滤器 | 数据仓储 | |
交互方式 | 顺序结构或有限的循环结构 | (1)星型(工具之间通过中心节点进行交互) |
数据结构 | (2)数据流(或流式数据) | 文件或模型 |
控制结构 | (3)数据驱动 | 业务功能驱动 |
扩展方法 | 接口适配 | (4)模型适配(与数据仓储进行数据适配) |
【阅读理解】需要同时支持该厂商自行定义的应用编程语言的编辑、界面可视化设计、编译、调试等模块,这些模块产生的模型或数据格式差异较大,集成环境应提供数据集成能力。集成开发环境还要支持以适配方式集成公司现有的应用模拟器工具
四、信息系统安全性
(一)信息系统面临的安全威胁
信息系统面临的安全威胁来自于物理环境、通信链路、 网络系统、操作系统、应用系统以及管理等多个方面。
- 物理安全威胁:对系统所用设备的威胁,如自然灾害、电源故障、 数据库故障和设备被盗等造成数据丢失或信息泄漏。
- 通信链路安全威胁:在传输线路上安装窃听装置或对通信链路进行干扰。
- 网络安全威胁:主要是指由于因特网的开放性、国际性与无安全管理性,对内部网络形成的严重安全威胁。
- 操作系统安全威胁:操作系统本身的后门或安全缺陷,如“木马和“陷阱门"等。
- 应用系统安全威胁:对于网络服务或用户业务系统安全的威胁,包括应用系统自身漏洞,也受到“木马”的威胁。
- 管理系统安全威胁:人员管理和各种安全管理制度。
(二)安全认证
目前主要的认证方式有三类
- 用户名和口令认证:主要是通过一个客户端与服务器共知的口令(或与口令相关的数据)进行验证。根据处理形式的不同,分为验证数据的明文传送、利用单向散列函数处理验证数据、利用单向散列函数和随机数处理验证数据。
- 使用令牌认证:该方式中,进行验证的密钥存储于令牌中,目前的令牌包括安全证书和智能卡等方式。
- 生物识别认证:主要是根据认证者的图像、指纹、气味和声音等作为认证数据。
(三)授权侵犯
授权侵犯指的是被授权以某一目的使用某一系统或资源的某个人,将此权限用于其他非授权的目的,也称作"内部攻击"。
解决方案:抗抵赖服务
抗抵赖服务包括证据的生成、验证和记录,以及在解决纠纷时随即进行的证据恢复和再次验证。
框架中抗抵赖服务的目的是提供有关特定事件或行为的证据。例如,必须确认数据原发者和接收者的身份和数据完整性,在某些情况下,可能需要涉及上下文关系(如日期、时间、原发者/接收者的地点等)的证据,等等。
五、软件设计模式
(一)MVC
视图层(View):用户看到并与之交互的界面,能显示数据,接收输入,但不进行业务处理
控制器(Controler):接受用户的输入并调用模型和视图去完成用户的需求。该部分是用户界面与Model的接口。一方面它解释来自于视图的输入,将其解释成为系统能够理解的对象,同时它也识别用户动作,并将其解释为对模型特定方法的调用;另一方面,它处理来自于模型的事件和模型逻辑执行的结果,调用适当的视图为用户提供反馈。
模型(Model):应用程序的主体部分,表示业务数据和业务逻辑。一个模型能为多个视图提供数据。
EJB(三种Bean组成)
Session Bean的职责是:维护一个短暂的会话
Entity Beans 的职责是:维护一个持久稳固的数据
Message-Driven Bean的职责是:异步接受消息
有状态和无状态构件:是否需要保存客户端与服务器交互的中间状态数据
如:身份认证需要记录用户身份信息,在线编辑构件需要记录前一次操作结果
(二)Web系统架构设计
UDDI:(了解):是一种用于描述、发现、集成Web Service的技术,通过UDDI,企业可以根据自己的需要动态查找并使用Web服务,也可以将自己的Web服务动态地发布到UDDI注册中心,供其他用户使用
(三)什么是面向服务架构(SOA)以及ESB(企业服务总线)在SOA中的作用与特点
SOA是一个组件模型, 它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
ESB作用与特点
- SOA的一种实现方式,ESB在面向服务的架构中起到的是总线作用,将各种服务进行连接与整合
- 描述服务的元数据和服务注册管理
- 在服务请求者和提供者之间传递数据,以及对这些数据进行转换的能力,并支持由实践中总结出来的一些模式如同步模式、异步模式等
- 发现、路由、匹配和选择的能力,以支持服务之间的动态交互,解耦服务请求者和服务提供者。高级一些的能力,包括对安全的支持、服务质量保证、可管理性和负载平衡等。
(四)系统安全保证措施
- 引入https协议或采用加密技术对数据先加密再传输
- 采用信息摘要技术对重要信息进行完整性验证
- 防火墙系统
- 安全检测
- 网络扫描
六、系统设计与开发工具集成
(一)ESB企业服务总线【2012之前】
主要功能,并从集成系统的部署方式、待集成系统之间的耦合程度、集成系统的可扩展性3个方面说明为何采用ESB作为集成框架的基础架构。
ESB的主要功能包括:
- 应用程序的位置透明性
- 传输协议转换
- 消息格式转换
- 消息路由
- 消息增强
- 安全支持
- 监控和管理
采用ESB作为集成框架,能够实现灵活的部署结构,包括CS结构、P2P结构等。
采用ESB作为集成框架,待集成系统只需要和总线进行联系,彼此之间不需要互相通信,这样就大大降低了系统的耦合程度。
采用ESB作为集成框架,在加入新的待集成系统时,只需要采用插件的方式实现传输协议和数据格式的适配即可,系统的可扩展性较强。
(二)根据需求分析应该采用何种具体的集成方式或架构风格最为合适
- 由于需要共享系统的功能,并且系统的运行平台与语言差异较大,应该采用面向服务的方式进行功能集成,可以将工具的功能包装为服务,实现跨语言与跨平台访问。
- 工具所支持的通信协议和数据格式各不相同,并需要实现工具之间的灵活通信协议和数据格式交换,因此应该基于消息总线,以协议及数据适配器的方式实现灵活的通信协议和数据格式转换。
- 集成框架需要根据实际的软件系统开发流程,灵活、动态地定义系统设计与开发工具之间的协作关系,因此应该引入工作流定义语言及其引擎来动态描述工具之间的协作关系。
- 采用 界面集成 的方法对第三方工具进行集成,绕过工具内部的复杂处理逻辑。
(三)架构设计中的非功能需求
- 操作性需求:指系统完成任务所需的操作环境要求及如何满足系统将来可能的需求变更的要求
如:系统需要支持当前主流的标准和服务,特别是通信协议和平台接口
如:系统具有故障诊断和快速恢复能力,注意和可用性区分
- 性能需求:针对系统性能要求的指标。常见的包括:响应时间、吞吐率
- 安全性需求:防止系统崩溃和保证数据安全所需要采取的保护措施或预防措施
- 文化需求:使用本系统的不同用户群体对系统提出的特有要求
用户界面支持用户的个性化定制
七、信息系统可靠性
(一)可靠度和失效率
可靠度就是系统在规定的条件下、规定的时间内不发生失效的概率。
失效率又称风险函数,也可以称为条件失效强度,是指运行至此刻系统未出现失效的情况下,单位时间系统出现失效的概率。
(二)动态冗余和N版程序设计技术
动态冗余又称为主动冗余,它是通过故障检测、故障定位及故障恢复等手段达到容错的目的。主要方式是多重模块待机储备,当系统检测到某工作模块出现错误时,就用一个备用的模块来替代它并重新运行。 各备用模块在其待机时,可与主模块一样工作,也可以不工作。前者叫热备份系统(双重系统),后者叫冷备份系统(双工系统、双份系统)。
N版本程序设计是一种静态的故障屏蔽技术,其设计思想是用N个具有相同功能的程序同时执行一项计算,结果通过多数表决来选择。其中N个版本的程序必须由不同的人独立设计,使用不同的方法、设计语言、开发环境和工具来实现,目的是减少N个版本的程序在表决点上相关错误的概率。
(三)检错技术的优缺点,及其常见的实现方式和处理方式
检错技术实现的代价一般低于容错技术和冗余技术,但有一个明显的缺点,就是不能自动解决故障,出现故障后如果不进行人工干预,将最终导致软件系统不能正常运行。
检错技术常见的实现方式:判断返回结果,如果返回结果超出正常范围,则进行异常处理;计算运行时间也是一种常用技术,如果某个模块或函数运行时间超过预期时间,可以判断出现故障;还有置状态标志位等多种方法,自检的实现方式需要根据实际情况来选用。
检错技术的处理方式,大多数都采用 ”查处故障-停止软件运行-报警“ 的处理方式。但根据故障的不同情况,也有采用不停止或部分停止软件系统运行的情况,这一般由故障是否需要实时处理来决定。
八、Web应用系统架构设计
(一)什么是REST,并指出在REST中将哪三种关注点进行分离
REST从资源的角度来定义整个网络系统结构,分布在各处的资源由统一资源标识符 (URI) 确定,客户端应用程序通过URI获取资源的表现,并通过获得资源表现使得其状态发生改变
REST中将资源、资源的表现和获取资源的动作三者进行分离
(二)什么是响应式设计
响应式web设计是指设计与开发的页面可以根据用户的行为(比如改变浏览器窗口大小)和不同的设备环境(比如系统平台、屏幕分辨率以及横竖屏等)做出相应的响应来调整页面的布局,以提供用户可感知的、流畅的阅读和操作体验。
实现方式:流式布局、弹性布局(如弹性图片)、媒体查询
应用系统架构设计
(三)主从复制
提升性能:交易平台要求高并发,主从复制方式一主多从,不同的用户请求可以从不同的从数据库读取数据,提高并发度。
可扩展性更优:如果采用单台数据库服务器,则访问量持续增加时,数据库瓶颈暴露,且无法迅速解决问题。而主从结构可以快速增加从服务器数量,以满足需求。
提升可用性:一主多从,一台从服务器出现故障不影响整个系统正常工作。
相当于负载均衡:一主多从分担任务,相当于负载均衡
提升数据安全性:系统中的数据冗余存放多份,不会因为某台机器硬件故障而导致数据丢失。
(四)胖客户端和瘦客户端(相对概念)
了解概念,能够区分哪些需求更合适用哪种客户端
胖客户端的客户端不但做UI展示,还会处理业务逻辑,更新起来更麻烦,客户端侧运行能力强,压力更大,做缓存容易
瘦客户端的客户端专注于UI展示,业务逻辑交给服务端侧处理,更新业务逻辑更方便
(五)应用服务器
PHP相较于J2EE存在的不足
- PHP只能实现简单的分布式两层或三层的架构,而JAVA在这方面就比较强大,可以实现多层的网络架构。数据库层(持久化层)、应用(业务)逻辑层、表示逻辑层彼此分开,而且现在不同的层都已经有一些成熟的开发框架的支持
- PHP是面向过程的语言,Java是面向对象的,面向过程语言开发的程序只要业务流程发生变化,修改工作量很大,所以可修改性差,同时可复用性也差
- PHP语言在可靠性方面比J2EE平台差,J2EE平台有大量增强可靠性的成熟解决方案,而PHP只是一种简单的脚本语言, 在可靠性方面缺乏成熟解决方案
- PHP对于不同的数据库采用不同的数据库访问接口,而Java通过JDBC来访问数据库,通过不同的数据库厂商提供的数据库驱动方便地访问数据库,访问数据库的接口比较统一。所以原架构在数据库连接方面修改起来工作量也是很大的
- PHP适合于小型项目
- PHP比Java的可维护性差
- PHP比Java的扩展性差
- PHP比Java的安全性差
应用服务器概念
应用服务器是指通过各种协议把商业逻辑隰露给客户端的程序
简单的说能实现动态网页技术的服务器叫作Web应用服务器
- 若系统负荷很大,可以部署多台应用服务,多台应用服务器分担任务,以达到性能要求
- 应用服务器可以通过灵活的增加服务器完成扩展,所以可扩展性很好
- 应用服务器可长时间稳定运行。因为当一台应用服务器出现故障时,可以将当前运行的事务转移至正常应用服务器上完成执行,不影响业务正常执行,从而保障高可靠性与稳定性
九、数据库
(一)分布式数据库缓存
先写数据库再写缓存,或先写缓存再写数据库的问题:双写不一致问题、读写冲突的并发问题
访问缓存时对于不存在的key设置null值存在的问题以及解决方式
- 存在问题:不在系统中的key值是无限的,如果均设置key值为空,会造成内存资源的极大浪费,引起性能急剧下降
- 解决思路:查询缓存之前,对key值进行过滤,只允许系统中存在的key进行后续操作(例如采用key的bitmap进行过滤)
key的大量失效及大量更新解决方案
- 缓存失效后,通过加排它锁或者队列方式控制数据库写缓存的线程数量,使得缓存更新串行化
- 给不同key设置随机或不同的失效时间,使失效时间的分布尽量均匀
- 设置两级或多级缓存,避免访问数据库服务器
(二)Memcache和Redis
分布式数据缓存:在高并发环境下,为了减轻数据库压力和提高系统响应时间,在数据库系统和应用系统之间增加的独立缓存系统
Memcache和Redis的区别
Memcache | Redis | |
数据类型 | 简单的key/value结构 | key/value,拥有5大数据类型,string,hash,list,set,zset |
持久性 | 不支持 | 支持 |
分布式存储 | 客户端哈希分片/一致性哈希 | 主从、Sentinel\Cluste等 |
多线程支持 | 支持 | 不支持,6.0之后支持,默认不开启 |
内存管理 | 有,私有内存池 | 无 |
事务支持 | 不支持 | 有限支持 |
Mencache在可靠性和一致性上存在的问题
- 可靠性:没有持久化功能,掉电后数据全部丢失
- 一致性:不支持事务
Redis同步方案:读取数据时,先读取Redis中的数据,如果Redis没有,则从原数据库中读取,并同步更新Redis中的数据。写回时,写入到原数据库中,并同步更新至Redis中
Redis分布式存储和集群切片
- 分布式存储:主从模式、哨兵模式、集群模式
- 集群切片
- 客户端分片:在客户端就通过key的hash值对应到不同的服务器
- 中间件实现分片:在应用软件和Redis中间,例如:Twemproxy、Codis等,由中间件实现服务到后台Redis节点的路由分派
- 客户端服务端协作分片:RedisCluster模式,客户端可采用一致性哈希,服务端提供错误节点的重定向服务到slot上,不同的slot对应到不同的服务器
(三)关系数据库和文件系统
设计难度 | 数据冗余 | 数据架构 | 应用扩展性 | |
关系型数据库 | 需要符合关系模式,难度较大 | 遵守数据库范式。数据冗余少 | 以数据库为中心组织,管理数据 | 独立于应用,接口标准化,适合共享 |
文件系统 | 针对特定应用程序,难度较小 | 可能多个文件有相同的数据属性,冗余大 | 以应用为中心管理数据 | 符合特定应用系统要求 的文件数据很难在不同| 的应用系统之间共享 |
(四)关系数据库和内存数据库
数据模型 | 读写性能 | 容量 | 可靠性 | |
内存 | key/value | 内存读写,相对快 | 受内存限制 | 有恢复机制,但不是所有都能恢复,可靠性较低 |
关系 | 关系模式 | 外存读写,相对慢 | 基于磁盘,大 | 内建恢复机制,可靠性高 |
(五)持久层
数据持久层是一组软件服务, 将应用程序与该程序所使用的数据源分离,为整个项目提供一个统一、 安全、 并发的数据持久机制。
好处:
- 程序代码重用性强,即使更换数据库,只需要更改配置文件,不必重写程序代码。
- 业务逻辑代码可读性强,在代码中不会有大量的SQL语言,提高程序的可读性。
- 持久化技术可以自动优化,以减少对数据库的访问量,提高程序运行效率。
- 简化开发工作,让开发人员更关注于业务逻辑的开发。
- 通过对象/关系映射向业务逻辑提供面向对象的数据访问。
(六)数据库程序在线访问.Net和ORM方式的优缺点
优点 | 缺点 | |
.Net | 1、性能比ORM好 2、可以处理复杂查询语句 | 1、要求程序员懂SQL语句 2、修改与维护相对困难 |
ORM | 1、使用ORM可以大大降低学习和开发成本。 2、程序员不用再写SQL来进行数据库操作。 3、减少程序的代码量。 4、降低由于SQL代码质量差而带来的影响。 | 1、不太容易处理复杂查询语句。 2、性能较直接用SQL差。 |
(七)什么是SQL注入,以及抵御SQL注入的方式?
SQL注入攻击,就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令
可以通过以下方式抵御SQL注入攻击:
- 使用正则表达式
- 使用参数化的过滤性语句;
- 检查用户输入的合法性;
- 用户相关数据加密处理;
- 存储过程来执行所有的查询;
- 使用专业的漏洞扫描工具。
(八)什么是数据库建模中的反规范化技术,优点和可能带来的问题
规范化设计后,数据库设计者希望牺牲部分规范化来提高性能,这种从规范化设计的回退方法称为反规范化技术
采用反规范化技术的益处:降低连接操作的需求、降低外码和索引的数目,还可能减少表的数目,能够提高查询效率。
可能带来的问题:数据的重复存储,浪费了磁盘空间;可能出现数据的完整性问题,为了保障数据的一致性,增加了数据维护的复杂性,会降低修改速度
(九)常见的反规范化技术有哪些
- 增加冗余列:在多个表中保留相同的列,通过增加数据冗余减少或避免查询时的连接操作
- 增加派生列:在表中增加可以由本表或其他表中数据计算生成的列,减少查询时的连接操作并避免计算或使用集合函数
- 重新组表:如果许多用户需要查看两个表连接出来的结果数据,则把这两个表重新组成一个表来减少连接而提高性能
- 水平分割表:根据一列或多列数据的值,把数据放到多个独立的表中,主要用于表数据规模很大、表中数据相对独立或数据需要存放到多个介质上时使用
- 垂直分割表:对表进行分割,将主键与部分列放到一个表中,主键与其他列放到另一个表中,在查询时减少I/O次数
十、设计模式
(一)工厂模式的优点和应用场景
工厂模式分抽象工厂与工厂方法
抽象工厂设计模式提供一个接口, 可以创建一系列相关或相互依赖的对象, 而无需指定它们具体的类。其优点是可以非常方便的创建一系列的对象,其使用场景也是创建系列对象的情况。在本题中,可以针对Oracle、MySQL、 SQL Server分别建立抽象工厂,若指定当前工厂为Oracle,则创建出来的数据库连接,数据集等一系列的对象都是符合Oracle操作要求的。 这样便于数据库之间的切换。
(二)实现工具之间数据格式的灵活转换时,通常采用的设计模式是什么?
适配器设计模式
首先定义一个统一的数据转换接口类,然后针对不同的数据格式转换需求定义对应的实际转换类,实际转换类需要继承数据转换接口类,并实现接口转换类定义的接口。
补充
(一)系统架构图
SiteMesh:JSP布局框架
(二)Scrum敏捷开发过程
需求里面有描述
product backlog:优先级的需求列表
sprint:实现一个“小目标”的周期