免费智能真题库 > 历年试卷 > 系统分析师 > 2022年上半年 系统分析师 下午试卷 案例
  第4题      
  知识点：   功能分解   关系数据库   耦合   数据库   微服务   维护   一致性

 
【说明】
某大型电商平台构建了一个在线B2B商店系统。该系统采用微服务架构，将系统功能分解为多个松散耦合且可独立部署的较小组件或服务。最终设计的系统包括了电商系统中常见的服务：客户服务、订单服务、支付服务等，其中：
1、客户服务负责对客户相关的信息进行管理和维护；
2、订单服务负责对订单信息的管理和维护；
3、支付服务负责对在线支付功能和信息的管理和维护等。
为了确保微服务之间的松耦合，每个服务都有自己的数据，其中，订单服务使用了 NoSQL 数据库，客户服务和支付服务使用了关系数据库。
李工认为由于不同服务使用了各自的不同数据库，使得跨服务操作可能存在数据不一致。比如订单与支付的数据一致性问题，系统通过订单服务在本地 NoSQL 数据库中创建订单记录，同时在支付服务的关系数据库中创建支付记录，且必须保证订单记录和支付记录的一致性，该问题在系统构建时需要考虑。
 
问题：4.1   （7分）
李工建议采用两阶段提交协议（2PC）来解决服务数据的一致性问题。请用200字以内的文字简要说明2PC；说明2PC是否能解决该问题，并简要解释原因。
 
问题：4.2   （8分）
王工建议采用分布式数据管理方案，用事件驱动架构来解决服务数据的一致性问题，在订单服务和支付服务之间通过可靠的消息队列实现事件的传递，其基本操作步骤如下，请填写其中的空白处。
（1）订单服务接收订购请求，创建一个订单，该记录状态为（a），发布一个“创建订单”事件；
（2）（b）接收“创建订单”事件，记录（c），发布一个“支付完成”事件；
（3）订单服务接收“支付完成”事件，修改订单记录状态为（d）。
 
问题：4.3   （10分）
李工提出王工的方案会有数据库更新和发布事件的原子性问题，例如订单服务创建订单记录和发布“创建订单”事件需要原子性保障，否则会出现数据不一致状态。
王工认为可以使用本地事务发布事件的方法来解决该问题。请给出使用本地事务发布事件的基本方法，并说明该方法的缺点。
 
 
 

   知识点讲解    
   · 功能分解    · 关系数据库    · 耦合    · 数据库    · 微服务    · 维护    · 一致性
 
       功能分解
        功能分解是将需求规格说明中每一个功能加以分解，确保各个功能被全面地测试。功能分解是一种较常用的方法。
        步骤如下：
        （1）使用程序设计中的功能抽象方法把程序分解为功能单元。
        （2）使用数据抽象方法产生测试每个功能单元的数据。
        功能抽象中程序被看成一种抽象的功能层次，每个层次可标识被测试的功能，层次结构中的某一功能有由其下一层功能定义。按照功能层次进行分解，可以得到众多的最低层次的子功能，以这些子功能为对象，进行测试用例设计。
        数据抽象中，数据结构可以由抽象数据类型的层次图来描述，每个抽象数据类型有其取值集。程序的每一个输入和输出量的取值集合用数据抽象来描述。
 
       关系数据库
               关系模型概述
               关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。关系模型的数据结构单一，现实世界的实体以及实体间的各种联系均用关系来表示。在用户看来，关系模型中数据的逻辑结构是一张二维表。关系模型中常用的关系操作包括选择、投影、连接、除、并、交、差等查询操作，和增加、删除、修改操作两大部分。早期的关系操作能力通常用关系代数和关系演算来表示，关系代数是用对关系的运算来表达查询要求的方式，关系演算是用谓词来表达查询要求的方式。另外还有一种介于关系代数和关系演算之间的语言SQL，它不仅具有丰富的查询功能，而且具有数据定义和数据控制功能，是关系数据库的标准语言。
               关系数据结构及形式化定义
               首先介绍一些概念：
               （1）域（Domain）：域是一组具有相同数据类型的值的集合。
               （2）笛卡尔积（Cartesian Product）：给定一组域D1, D2，…，Dn，这些域中可以有相同的。D1，D2，…，Dn的笛卡尔积为：D1×D2×…×Dn=｛（d1，d2,…，dn） |di∈Di, i=1，2,…，n｝其中每一个元素（d1，d2，…，dn）叫做一个n元组或简称元组。元素中的每一个值di叫做一个分量。笛卡尔积可以用来表示二维表，表中的每行对应一个元组，每列对应一个域。
               （3）关系（Relation）：D1×D2×…×Dn的子集叫做在域D1，D2，…，Dn上的关系，表示为R （D1, D2，…，Dn），这里R表示关系的名字，n是关系的目或度（Degree），关系中的每个元素是关系中的元组。
               关系是笛卡尔积的有限子集，所以关系也是一个二维表，表的每行对应一个元组，表的每列对应一个域。一个元组就是该关系所涉及的属性集的笛卡尔积的一个元素。由于在笛卡尔积的定义中，域是可以相同的，所以为了加以区分，必须对每个列起一个名字，称之为属性，n目关系必须有n个属性。若关系中的某一属性组的值能够唯一标识一个元组，则称该属性组为候选码（Candidate Key）。若一个关系有多个候选码，则选定其中之一为主码（Primary Key）。主码的各个属性称为主属性（Prime Attribute）。不包含在任何候选码中的属性称为非码属性（Non-key Attribute）。当关系模式的所有属性组是这个关系模式的候选码时，称为全码（All-Key）。
               关系的完整性
               （1）实体完整性。
               若属性A是基本关系R的主属性，则属性A不能取空值。也就是说基本关系得所有主属性都不能取空值，而不仅是主码整体不能取空值。
               （2）参照完整性。
               现实世界中的实体之间往往存在某种联系，在关系模型中实体之间的联系用关系描述，这样就会存在着关系间的引用。例如，学生、课程、选课三个关系如下：
               学生（学号，姓名，性别，专业）
               课程（课程号，课程名，教师，学分）
               选课（学号，课程号，成绩）
               它们之间是多对多联系，存在着属性的引用，即选课关系引用了学生关系的主码和课程关系的主码，如画线所示。在选课关系中必须满足：①选课关系中的“学号”值必须是确实存在的学生的学号，即在学生关系中有该学生的记录；②选课关系中“课程号”也必须确实存在，即课程关系中有该课程的记录。也就是说，选课关系中某些属性的取值需要参照其他关系的属性的取值。
               设F是基本关系R的一个或一组属性，但不是关系R的码。如果F与基本关系S的主码KS相对应，则称F是基本关系R的外码，并称基本关系R为参照关系，基本关系S为被参照关系或目标关系，关系R和S不一定是不同的关系。在上例中，“学号”和“课程号”是选课关系的外码，学生关系和课程关系是被参照关系，选课关系是参照关系。
               参照完整性规则：若属性（或属性组）F是基本关系R的外码，它与基本关系S的主码KS相对应（关系R和S不一定是不同的关系），则对于R中每个元组在F上的值或者取空值或者等于S中某个元组的主码值。
               （3）用户定义的完整性
               用户定义的完整性就是针对某一具体关系数据库的约束条件。例如属性的取值范围、属性间必须满足一定的函数关系等。
 
       耦合
        耦合性是指模块之间联系的紧密程度。耦合性越高，则模块的独立性越差。模块间耦合的高低取决于模块间接口的复杂性、调用的方式及传递的信息。模块的耦合有以下几种类型：
        （1）无直接耦合：指两个模块间没有直接的关系，它们分别从属于不同模块的控制与调用，它们之间不传递任何信息。因此，模块间耦合性最弱，模块独立性最高。
        （2）数据耦合：指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言中的值传递。这种耦合程度较低，模块的独立性较高。
        （3）标记耦合：指两个模块之间传递的是数据结构，如高级语言中的数据组名、记录名、文件名等这些名字即为标记，其实传递的是这个数据结构的地址。
        （4）控制耦合：指一个模块调用另一个模块时，传递的是控制变量，被调模块通过该控制变量的值有选择地执行块内的某一功能。
        （5）公共耦合：指通过一个公共数据环境相互作用的那些模块之间的耦合。
        （6）内容耦合：这是程度最高的耦合。当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部，这种模块之间的耦合为内容耦合，这种情况往往出现在汇编程序设计中。
 
       数据库
        数据库（DataBase，DB）是指长期存储在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和存储，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。
        系统使用的所有数据存储在一个或几个数据库中。
 
       微服务
        微服务是一种基于一组独立部署运行的小型服务来构建应用的方法。与传统的面向服务体系结构SOA应用相比，这些小型服务主要围绕应用系统业务能力来构建，采用尽量去中心化的机制管理，使用不同技术栈开发，通过轻量级通信机制交互。
 
       维护
        维护阶段是软件生存期中时间最长的阶段。软件一旦交付正式投入运行后便进入软件维护阶段。该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。
 
       一致性
        在讨论一致性之前，先看一下CAP理论。它作为一种理论依据，使得在不同应用中，对一致性也有了不同的要求。CAP理论：简单地说，就是对于一个分布式系统，一致性（Consistency）、可用性（Availablity）和分区容忍性（Partition tolerance）三个特点最多只能三选二。
        一致性意味着系统在执行了某些操作后仍处在一个一致的状态，这点在分布式的系统中尤其明显。比如某用户在一处对共享的数据进行了修改，那么所有有权使用这些数据的用户都可以看到这一改变。简言之，就是所有的结点在同一时刻有相同的数据。
        可用性指对数据的所有操作都应有成功的返回。高可用性则是在系统升级（软件或硬件）或在网络系统中的某些结点发生故障的时候，仍可以正常返回。简言之，就是任何请求不管成功或失败都有响应。
        分区容忍性这一概念的前提是在网络发生故障的时候。在网络连接上，一些结点出现故障，使得原本连通的网络变成了一块一块的分区，若允许系统继续工作，那么就是分区可容忍的。
        在数据库系统中，事务的ACID属性保证了数据库的一致性。比如银行系统中，转账就是一个事务，从原账户扣除金额，以及向目标账户添加金额，这两个数据库操作的总和构成一个完整的逻辑过程，具有原子的不可拆分特性，从而保证了整个系统中的总金额没有变化。
        然而，这些ACID特性对于大型的分布式系统来说，是和高性能不兼容的。比如，你在网上书店买书，任何一个人买书这个过程都会锁住数据库直到买书行为彻底完成（否则书本库存数可能不一致），买书完成的那一瞬间，世界上所有的人都可以看到书的库存减少了一本（这也意味着两个人不能同时买书）。这在小的网上书城也许可以运行得很好，可是对Amazon这种网上书城却并不是很好。
        而对于Amazon这种系统，它也许会用Cache系统，剩余的库存数也许是几秒甚至几个小时前的快照，而不是实时的库存数，这就舍弃了一致性。并且，Amazon可能也舍弃了独立性，当只剩下最后一本书时，也许它会允许两个人同时下单，宁愿最后给那个下单成功却没货的人道歉，而不是整个系统性能的下降。
        由于CAP理论的存在，为了提高性能，出现了ACID的一种变种BASE（这四个字母分别是Basically Available，Soft—state，Eventual consistency的开头字母，是一个弱一致性的理论，只要求最终一致性）：
        .Basically Available：基本可用。
        .Soft state：软状态，可以理解为“无连接”的，而与之相对应的Hard state就是“面向连接”的。
        .Eventual consistency：最终一致性，最终整个系统（时间和系统的要求有关）看到的数据是一致的。
        在BASE中，强调可用性的同时，引入了最终一致性这个概念，不像ACID，其并不需要每个事务都是一致的，只需要整个系统经过一定时间后最终达到一致。比如Amazon的卖书系统，也许在卖的过程中，每个用户看到的库存数是不一样的，但最终卖完后，库存数都为0。再比如SNS网络中，C更新状态，A也许可以1分钟就看到，而B甚至5分钟后才看到，但最终大家都可以看到这个更新。
        具体地说，如果选择了CP（一致性和分区容忍性），那么就要考虑ACID理论（传统关系型数据库的基石，事务的四个特点）。如果选择了AP（可用性和分区容忍性），那么就要考虑BASE系统。如果选择了CA（一致性和可用性），如Google的bigtable，那么在网络发生分区的时候，将不能进行完整的操作。
        ACID理论和BASE的具体对比如下表所示。
        
        ACID和BASE的对比表
   题号导航      2022年上半年 系统分析师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
 
第4题    在手机中做本题