2025年软件工程考研系统设计专项训练冲刺试卷（含答案）

2025年软件工程考研系统设计专项训练冲刺试卷（含答案）考试时间：______分钟总分：______分姓名：______一、请简述微服务架构的核心思想及其相较于传统单体架构的主要优缺点。二、在设计一个高并发的短链接系统时，需要考虑哪些关键的技术点？请分别阐述。三、请解释什么是数据库的范式，并说明在系统设计中选择合适范式级别需要权衡哪些因素。四、对于一个需要支持海量用户实时互动的社交平台（如朋友圈），在系统设计上如何保证消息的及时性和可靠性？请阐述涉及的关键技术和设计策略。五、请描述在系统设计中应用“单一职责原则”和“开闭原则”的具体含义，并举例说明它们如何帮助提升系统的可维护性和可扩展性。六、假设你需要为一个电商平台的订单系统进行设计。请说明你会如何进行需求分析，并确定系统的核心功能模块。同时，针对订单数据的高并发读写和事务一致性，提出你的解决方案。七、在设计一个分布式缓存系统时，需要考虑哪些关键的设计点？请详细说明缓存数据一致性的常见解决方案及其优缺点。八、请阐述在系统设计中如何进行安全架构设计。需要考虑哪些主要的安全威胁，以及相应的防护措施？举例说明如何在认证和授权环节进行设计。九、考虑一个需要支持大规模用户访问的在线直播系统，请从架构设计角度分析如何保证系统的低延迟和高可用性。可以涉及技术选型、架构模式等方面的思考。十、请比较RESTfulAPI和GraphQL在设计上的主要差异，并说明在什么场景下选择哪种API设计风格可能更合适。试卷答案一、核心思想：将一个大型应用拆分为一组小型、独立、可独立部署的服务，服务之间通过轻量级机制（通常是HTTPAPI）通信。每个服务都围绕特定的业务能力构建，拥有自己的数据库，并可以通过自动化工具进行部署。优点：1.技术异构性：每个服务可以选择最适合其业务需求的技术栈。2.独立开发与部署：服务规模小，团队可以独立开发、测试、部署和扩展，提高开发效率和市场响应速度。3.可扩展性：可以针对特定服务进行扩展，更精细化地利用资源。4.容错性：一个服务的故障通常不会导致整个应用崩溃，其他服务可以继续运行。5.可维护性：服务模块化程度高，代码库更小，更容易理解和维护。缺点：1.分布式系统复杂度：需要处理网络延迟、服务发现、负载均衡、数据一致性、分布式事务等问题。2.运维复杂度：需要管理更多的服务实例和部署流程。3.测试复杂度：端到端测试需要模拟多个服务交互，集成测试复杂。4.部署协调：跨多个服务的部署需要更精细的协调。5.数据一致性：实现跨服务的数据一致性通常比单体架构更复杂。二、关键技术点：1.高并发接入层：需要设计能够承受大流量请求的负载均衡器（如Nginx,HAProxy）和反向代理，可能需要使用CDN分散请求压力。2.缓存策略：广泛使用缓存（如Redis,Memcached）来存储热点数据（如短链接映射关系、用户信息），减少对后端存储的访问压力，降低延迟。3.数据库优化：选择合适的数据库类型（如使用高性能的键值数据库或列式数据库存储映射关系），优化查询，可能需要使用数据库集群或分片来提升读写性能和容量。4.异步处理：对于非关键操作（如发送访问日志、更新统计数据），采用消息队列（如Kafka,RabbitMQ）进行异步处理，解耦系统，提高响应速度。5.服务化（可选）：如果系统复杂度增加，可以将短链接生成、解析等逻辑拆分为独立的服务。6.高可用架构：通过部署多个实例、使用主从复制或集群、异地多活等方式保证服务不中断。7.限流与熔断：防止恶意攻击或突发流量导致系统崩溃，保护后端服务。三、数据库范式：是一种规范化理论，旨在减少数据冗余、避免插入更新删除异常，通过将数据分解成多个相关联的表，并遵循一定的规则（如第一范式NF1、第二范式NF2、第三范式NF3、BCNF、第四范式NF4、第五范式NF5）来组织。权衡因素：1.数据一致性vs.查询性能：范式级别越高，数据冗余越少，一致性越好，但复杂的关联查询可能需要多表连接，导致查询性能下降。降低范式（引入冗余）可以提高查询性能，但可能牺牲一致性和增加维护成本。2.数据更新vs.查询复杂度：高范式要求数据更新时进行更复杂的操作（如多表联动），增加了更新开销和出错概率；低范式虽然更新简单，但查询可能更复杂。3.应用场景复杂度：简单的应用可能不需要严格遵循高范式；复杂的应用则需要仔细权衡以保证数据integrity和performance。4.存储成本：低范式会占用更多存储空间。5.开发维护复杂度：高范式需要更复杂的数据库设计和SQL语句，增加了开发和维护的难度。四、保证及时性：1.高效的消息传递机制：使用低延迟的消息队列或WebSocket技术进行实时消息推送。2.优化的数据结构：使用高效的数据结构（如哈希表）存储用户关系和消息索引。3.负载均衡与分布式部署：将服务部署在多个节点，分散用户请求，提高处理能力。4.缓存：缓存用户在线状态、好友列表等。保证可靠性：1.消息队列保证至少一次传递：通过确认机制（ACK）、重试机制、幂等性设计保证消息不丢失。2.持久化：将关键状态（如用户在线/离线、消息状态）持久化到数据库或缓存中，防止服务重启后数据丢失。3.服务冗余与故障转移：部署多个消息服务器副本，实现主从或集群，当主节点故障时自动切换。4.数据备份与恢复：定期备份数据，制定灾难恢复计划。5.监控与告警：实时监控系统状态和消息延迟，及时发现并处理问题。五、单一职责原则(SRP)：一个类（或模块、函数）应该只有一个引起它变化的原因。这意味着一个类应该只负责一项职责。*含义：降低类的复杂度，使类更专注于一件事情。当需求变化时，只影响负责该职责的类。*例子：在用户模块中，有一个`User`类，它只负责用户的基本信息（如`getName()`,`getAddress()`）。将用户权限管理逻辑放在一个独立的`UserPermission`类中。这样，修改地址逻辑的变化不会影响权限逻辑，反之亦然。*价值：提升可维护性（修改影响范围小）、可测试性（单元测试更容易）、降低耦合度。开闭原则(OCP)：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。*含义：当需求变化时，应该通过增加新的代码（扩展）来适应，而不是修改现有代码（修改）。通过使用抽象和多态性实现。*例子：设计一个图形绘制框架，基础类`Shape`定义了绘制接口`draw()`。当需要支持新图形（如`Circle`,`Square`）时，创建新的具体图形类继承`Shape`并实现`draw()`，无需修改`Shape`类或已有图形类的代码。如果需要改变绘制风格（如填充、描边），可以增加`DrawingStrategy`接口和具体策略类，让`Shape`类持有一个`DrawingStrategy`的实例，而不需要修改`Shape`本身。*价值：提升可扩展性（易于添加新功能）、可维护性（减少修改带来的风险）。六、需求分析：1.核心功能：订单创建、订单查询、订单支付、订单状态管理（待支付、已支付、已发货、已完成、已取消）、购物车关联。2.非功能性需求：高并发（秒杀场景）、事务一致性（订单支付与库存扣减）、数据准确性、一定的可扩展性。核心模块：1.订单管理模块：负责订单的创建、存储、查询、状态更新。2.支付集成模块：对接第三方支付平台（支付宝、微信支付等），处理支付请求和回调。3.库存管理模块（或接口）：负责处理订单创建时的库存锁定与扣减逻辑，保证一致性。4.用户中心模块（接口）：获取用户信息、地址等。5.消息通知模块（接口）：发送订单状态变更通知。解决方案：1.高并发读写：*数据库层面：使用高性能数据库（如MySQLCluster,PostgreSQL+分片），优化索引，SQL语句优化。对于读多写少的订单查询，使用缓存（Redis）缓存热点订单数据。*应用层面：异步处理非核心流程（如发送通知），使用消息队列（Kafka）解耦订单创建与库存扣减。*架构层面：订单服务自身进行限流、熔断。2.事务一致性（订单支付与库存）：*分布式事务方案：采用本地消息表/数据库事务+消息队列+消息消费者补偿机制（如TCC、Saga模式变种）。支付成功后，本地事务提交，并将支付结果写入“订单支付消息表”；支付服务确认收到消息后，更新订单状态；如果后续处理失败，补偿机制尝试回滚或重试。*乐观锁/悲观锁：在库存扣减操作中使用悲观锁或乐观锁防止超卖。*最终一致性：接受一定时间窗口内的数据不一致，通过后续的补偿或校验保证最终一致性。七、关键设计点：1.缓存粒度：缓存整个对象还是对象的部分属性，需要根据业务场景确定。2.缓存更新/失效策略：数据更新时如何同步缓存（CacheAside,Read/WriteThrough,WriteBehind），缓存过期策略（TimeToLive,Event-BasedEviction）。3.缓存一致性：当底层数据变化时，如何保证缓存数据的准确性。是强一致性（实时更新）还是最终一致性（异步更新/失效）。4.缓存分区与容量：如何管理缓存大小，避免内存溢出；如何进行缓存分片，提高并发访问能力。5.缓存穿透、击穿、雪崩问题：如何预防和解决这些常见问题（如空值缓存、热点key加固、设置合理的过期时间、使用互斥锁/分布式锁处理击穿、限流熔断处理雪崩）。6.缓存与数据库的交互：如何高效地写入和读取数据库与缓存。7.缓存持久化（可选）：是否需要将缓存数据定期持久化到磁盘（如RDB、AOF），以防止服务重启后数据丢失。缓存数据一致性解决方案：1.Cache-AsidePattern(旁路缓存)：数据更新时先更新数据库，然后更新/删除缓存；读取时先读缓存，缓存无则读数据库并更新缓存。实现简单，但可能存在数据短暂不一致。2.Read/WriteThrough(读写穿透)：数据更新时，先更新缓存（可能需要等待数据库同步），然后更新数据库；读取时直接读缓存。保证缓存和数据一致性，但写操作性能受数据库影响。3.WriteBehind(写回缓存)：数据更新时先更新缓存，稍后异步批量更新数据库。读操作直接读缓存，写操作性能好，但一致性靠异步过程保证，有延迟。4.消息通知机制：数据变更服务通过消息队列通知缓存服务进行更新或失效。解耦性好，可以实现最终一致性。需要配合可靠的消息系统和补偿机制。5.分布式锁：在更新数据时，使用分布式锁保证同时只有一个服务实例能操作数据库和缓存，适用于写操作冲突的场景。优缺点：*Cache-Aside:简单，但一致性保证弱，写操作有延迟。*Read/WriteThrough:一致性好，但写路径复杂。*WriteBehind:写性能好，但实现复杂，有延迟。*消息通知：解耦好，最终一致性，实现复杂，依赖消息系统可靠性。*分布式锁：保证强一致性，但可能成为性能瓶颈，增加系统复杂度。八、安全架构设计：主要安全威胁：1.认证（Authentication）：非法用户冒充合法用户访问系统。2.授权（Authorization）：合法用户访问超出其权限的资源。3.数据泄露：敏感数据（密码、个人信息）被窃取。4.数据篡改：数据在传输或存储中被恶意修改。5.拒绝服务攻击（DoS/DDoS）：使服务不可用。6.注入攻击（SQLi,NoSQLi,OSCommandInjection）：利用输入验证漏洞执行恶意操作。7.跨站脚本（XSS）：在用户浏览器中执行恶意脚本。8.跨站请求伪造（CSRF）：非法利用用户登录状态发起请求。9.中间人攻击（MitM）：窃听或篡改通信。防护措施：1.认证：*使用强密码策略，密码需加密存储（哈希加盐）。*支持多因素认证（MFA）。*使用安全的认证协议（如OAuth2.0,OpenIDConnect）。*使用JWT或Session进行身份传递，注意保护令牌安全。2.授权：*实施最小权限原则。*使用基于角色的访问控制（RBAC）或基于属性的访问控制（ABAC）模型。*对敏感操作进行二次验证。3.数据保护：*敏感数据加密存储（数据库字段加密）和传输（HTTPS/TLS）。*对输出到页面的数据进行HTML实体编码，防止XSS。*对用户输入进行严格验证和过滤，防止注入攻击。4.通信安全：*全面启用HTTPS。*配置HSTS（HTTP严格传输安全）。*使用安全的HTTP头（CSP,HOPA,X-Frame-Options等）。5.安全配置：*关闭不必要的服务和端口。*使用安全的服务器软件配置（如OWASPTop10配置）。*及时更新和打补丁。6.输入验证与输出编码：严格校验所有外部输入，对所有输出进行恰当的编码。7.防范常见攻击：*使用参数化查询/预编译语句防止SQL注入。*使用CSRF令牌防止CSRF攻击。*配置好WAF（Web应用防火墙）。*限制请求频率，实现限流、熔断、降级。8.监控与日志：记录详细的访问日志和安全事件，实时监控异常行为。9.安全审计与渗透测试：定期进行安全审计和渗透测试。认证与授权设计：*认证环节设计：*提供用户注册和登录接口，密码使用bcrypt或Argon2等加盐哈希算法存储。*使用JWT进行无状态认证，JWTpayload中包含用户基本信息和角色，签名使用密钥或私钥保护。*对于敏感操作，要求用户重新输入密码或使用MFA验证。*提供OAuth2.0授权流程，允许第三方应用代表用户访问资源。*授权环节设计：*用户信息中包含角色列表和权限集合。*系统资源（URL、API接口）定义所需的角色或权限。*在每个请求处理前，根据用户Token解析出的角色/权限和请求的资源进行匹配校验。*可以使用中间件（如SpringSecurity）实现统一的授权检查。*对于细粒度的权限控制，可以使用ABAC模型，结合用户属性、资源属性和环境条件进行决策。九、架构设计：低延迟：1.接入层优化：使用CDN缓存静态资源，部署高性能负载均衡器（如LVS,Nginx）进行流量分发和SSL卸载。考虑使用边缘计算节点。2.应用层优化：*服务拆分，将实时互动功能（如聊天、直播流分发）独立为高性能服务。*使用无状态服务设计，方便水平扩展。*关键业务逻辑（如推流处理、消息编解码）优化算法，减少CPU和内存消耗。*异步化非实时处理任务（如录制录像、统计数据），使用消息队列（如Kafka,RabbitMQ）。3.数据层优化：*使用内存数据库（如Redis）缓存用户在线状态、会话信息、实时排行榜等热点数据。*对于直播流，使用专门的流媒体服务器（如Nginx-RTMP模块,SRS）负责流的接收、转码和分发，架构上与主应用服务解耦。*数据库读写分离，使用缓存层（Memcached/Redis）分担读请求。*选用低延迟的数据库引擎或存储方案。4.网络优化：*使用专线或高质量云网络服务，减少网络抖动和丢包。*对直播流进行分片（Segment）传输，适应不同网络环境和客户端播放速率。*启用QUIC等现代网络协议（如果客户端支持）。高可用性：1.服务冗余：将核心服务（如用户服务、实时互动服务、流媒体服务）部署在多个可用区或数据中心，实现主从备份或集群部署。2.负载均衡：在每个可用区内部署服务实例，使用负载均衡器（如HAProxy,Nginx,AWSELB）自动分发流量，并实现健康检查和自动故障切换。3.数据库高可用：使用数据库集群（如MySQLCluster,PostgreSQLCluster），主从复制，读写分离。考虑异地多活数据库部署。4.无状态服务设计：服务实例间无需共享状态，方便水平扩展和故障切换。5.熔断与降级：对外部依赖（如其他服务、第三方API）实现熔断机制，当依赖不可用时提供降级服务（如返回默认内容、静态数据）。6.异地多活：对于核心服务，在地理上不同的区域部署实例，用户根据网络情况自动或手动切换到最近或可用的区域。7.监控告警：实时监控系统各项指标（CPU、内存、网络、延迟、错误率），设置告警阈值，及时发现并处理故障。8.自动化运维：使用自动化工具进行服务部署、配置管理和故障恢复。综合考量：整体架构应倾向于微服务或分布式架构，将实时互动、用户管理、内容管理等核心功能拆分为独立服务，通过消息队列解耦，并针对每个部分进行高可用和低延迟设计。优先保证核心互动链路的低延迟和高可用。十、RESTfulAPIvs.GraphQL主要差异：1.数据获取方式：*RESTful:通常使用不同的URI路径代表不同的资源，客户端通过访问不同URI获取不同数据。客户端需要根据需要组合多个API请求来获取所需的所有数据。可能存在过载（请求过多数据）或不足（请求数据不足）的问题。*GraphQL:客户端通过一个统一的端点（通常是`/graphql`）发送查询，在查询体中明确指定所需的数据类型和字段。服务器根据查询返回精确所需的数据结构。2.数据形状控制：*RESTful:返回的数据形状通常是预定义的，由服务器端资源确定。客户端只能获取到固定结构的数据。*GraphQL:客户端可以精确控制返回数据的形状，服务器按需返回字段及其子字段。3.性能：*RESTful:可能需要多次请求才能获取完整数据，增加网络开销。但也可能通过一次请求获取大量数据导致服务器压力增大。*GraphQL:通常一次请求就能获取所有所需数据，减少网络往返次数（HTTPLatency），尤其在需要跨多个资源关联数据时性能优势明显。但也可能因查询过于庞大导致服务器处理负担加重。4.接口数量：*RESTful:需为每种资源及其常见操作定义多个独立的API端点。