2026年软件工程师系统架构设计考试试题及答案解析

2026年软件工程师系统架构设计考试试题及答案解析一、单项选择题（本大题共15小题，每小题2分，共30分。每小题给出的四个选项中，只有一项最符合题目要求。）1.在微服务架构中，若采用Saga模式管理跨服务事务，以下关于Saga执行协调方式的描述，最准确的是（）。A.必须采用事件溯源（EventSourcing）作为底层事件存储，否则无法保证事务原子性B.在编排（Orchestration）方式中，由中心化协调器（如流程引擎）负责向各参与者发送指令并处理回滚C.在协同（Choreography）方式中，由各服务通过异步消息直接通信，其控制流完全依赖消息队列的持久化能力D.Saga模式仅适用于读多写少的业务场景，对于高并发写场景必须改用两阶段提交协议2.关于CAP定理在分布式系统设计中的工程实践，下列做法中最为合理的是（）。A.在金融核心账务系统中，为保障数据强一致性，网络分区发生时优先选择AP，并通过人工对账修复数据B.在社交动态流系统中，允许用户看到略有延迟的Feed，采用最终一致性模型，即选择APC.在分布式锁服务中，若发生网络分区，为保证锁的安全属性（互斥），选择牺牲可用性，即选择CP，但无法完全杜绝脑裂D.由于CAP定理证明任何系统都无法同时满足三者，因此设计时只能三选二，不存在任何折中策略3.在系统架构设计中，采用读写分离架构以提升数据库读性能。当主库发生宕机，某高可用方案切换至备库后，发现部分最新写入的数据丢失。最可能的原因是（）。A.未启用半同步复制，且主库宕机时存在尚未传输到备库的Binlog日志B.备库使用了ROW格式的二进制日志，而主库使用了STATEMENT格式C.切换过程中未设置备库为只读模式，导致应用写入产生数据覆盖D.数据库连接池中的空闲连接未及时释放，导致备库连接数不足4.关于CDN（内容分发网络）缓存策略，当源站动态内容需根据用户Cookie或Token进行个性化响应时，下列处理方式最优的是（）。A.在CDN边缘节点缓存所有响应，忽略Cookie变化，以最大化命中率B.禁止CDN缓存所有动态内容，所有请求均回源以保障数据准确C.采用边缘计算，在CDN节点上运行逻辑代码，通过API网关动态拉取个性化数据并组装响应，同时合理设置Cache-ControlD.在CDN节点上缓存该用户的所有请求，并将TTL设置为1个月5.在Kubernetes集群中，某应用实例因内存使用率持续超过Limit而频繁被OOMKiller杀死。针对该问题，最有效的架构优化措施是（）。A.直接移除Pod的Resources.Limits配置，避免系统限制B.调整JVM堆参数与容器内存Limit匹配，并配置HorizontalPodAutoscaler基于内存指标进行扩容C.将Pod的QoS等级设置为BestEffort，优先调度资源D.仅增加节点数量，不做容器配置调整6.在大型分布式链路追踪系统中，为保证海量Span数据的高效采集与存储，通常会采用采样策略。以下关于采样策略的说法，错误的是（）。A.头部采样（Head-basedSampling）在请求入口处决定是否采样，无法感知整体调用链的最终状态，可能导致错误链路未被采集B.尾部采样（Tail-basedSampling）需要缓存全量Span，内存开销大，但能根据链路结果（如是否报错）精确采样C.概率采样（如固定比例1%）实现简单，但对低频高价值错误请求的捕获能力较弱D.为降低存储成本，一旦决定不采样，则该请求产生的所有Span数据必须全部丢弃，不允许在本地暂存7.关于关系型数据库分库分表策略，下列分片键选择方案中，最易产生数据倾斜问题的是（）。A.按用户ID的哈希值对分片数取模B.按订单创建时间的月份进行范围分片C.按卖家ID的哈希值进行分片，但部分大卖家的订单量占全站50%以上D.按订单ID的雪花算法结果进行取模分片8.在单体应用向微服务演进过程中，对于“绞杀者模式”（StranglerPattern）的应用，下列描述不正确的是（）。A.在原有单体应用外围建立新的微服务，通过反向代理或网关将特定功能路由到新服务B.该模式允许新旧功能并行运行，并逐步将流量从单体迁移至微服务C.绞杀者模式要求必须一次性重写整个单体应用，不能局部替换D.该模式降低了大规模重构的风险，属于渐进式迁移策略9.在Linux操作系统中，某高并发网络服务采用epoll模型管理Socket连接。当epoll_wait返回就绪事件时，对于水平触发（LT）和边缘触发（ET）模式，下列说法正确的是（）。A.在LT模式下，若应用程序未将Socket缓冲区中的数据一次性读完，后续epoll_wait不会再次返回该Socket的就绪事件B.在ET模式下，若应用程序未将数据读完，后续epoll_wait仍会持续通知该Socket可读，直到缓冲区为空C.在LT模式下，应用程序必须使用非阻塞IO，否则会阻塞进程D.在ET模式下，通常要求应用程序使用非阻塞IO循环读取数据，直到产生EAGAIN错误，否则可能遗漏剩余数据10.在分布式缓存Redis集群中，若使用RedisCluster模式，当客户端写入一个Key时，该Key对应的HashSlot为100。此时集群中节点A负责Slot0-200，节点B负责Slot201-400。请求被客户端发送至节点B，节点B收到后应（）。A.接受该请求，并将数据转发至节点A保存B.接受该请求并保存数据，同时异步同步至节点AC.向客户端返回MOVED100节点A_IP:Port错误，由客户端重定向至节点AD.向客户端返回ASK100节点A_IP:Port错误，由客户端重定向至节点A11.关于网关（APIGateway）在微服务架构中的职责，下列说法中不属于网关核心职责的是（）。A.统一鉴权与限流，将安全策略集中管理B.负责业务逻辑编排，如将多个服务的查询结果在网关内进行聚合与计算C.协议转换，支持客户端使用HTTP/HTTPS协议访问后端的RPC或gRPC服务D.动态路由与负载均衡，根据请求路径或Header将请求分发至对应服务实例12.在设计高可用架构时，多活数据中心是重要方案之一。同城双活与异地多活相比，下列描述不正确的是（）。A.同城双活由于物理距离短（通常<50公里），网络延时低，便于实现数据库层面的双写或实时同步B.异地多活能够有效抵御地域级灾难（如地震），但跨地域网络延迟可能导致数据同步延迟较大C.同城双活中，两个数据中心可以同时对外提供服务，流量分发可通过DNS或负载均衡器实现D.异地多活无需考虑数据冲突问题，因为用户只在一个数据中心写入数据13.在保障系统安全性的架构设计中，针对SQL注入攻击，下列防御措施中效果最弱的是（）。A.使用预编译语句（PreparedStatement）和参数化查询B.对用户输入进行严格的转义处理，在拼接到SQL语句前过滤单引号、分号等特殊字符C.部署Web应用防火墙（WAF），基于正则规则拦截包含SQL关键字的请求D.采用ORM框架（如MyBatis-Plus、Hibernate）并使用其提供的参数绑定机制14.关于消息队列的可靠性投递机制，以下方案中能保证消息100%不丢失且不重复的是（）。A.生产者发送消息后，消费者消费成功即发送ACK，若生产者未收到Broker确认则重发B.采用“本地消息表+定时任务”方案，确保生产者本地事务与消息发送原子性，消费者端依靠业务幂等性应对重复消息C.生产者采用同步发送，发送失败则抛出异常重试，直到Broker返回成功D.消费者拉取消息后立即提交offset，然后再处理业务逻辑15.某大数据平台采用Lambda架构，同时维护批处理层和速度层。当需要对用户行为数据进行实时推荐时，下列职责分配中，典型属于速度层（SpeedLayer）工作的是（）。A.使用SparkSQL定期对前一天的全量行为日志进行离线分析，生成用户偏好模型B.使用Flink实时消费Kafka中的用户点击流，结合Redis中的用户实时特征计算并更新实时推荐结果C.将清洗后的原始日志数据存储至HDFS，用于数据仓库的批量建模D.通过Sqoop定期将业务数据库中的数据导入Hive表，供批处理分析使用二、多项选择题（本大题共5小题，每小题3分，共15分。每小题给出的选项中，有两个或两个以上选项符合题目要求，全部选对得3分，选对但不全得1分，有选错得0分。）16.在容器化部署环境中，关于Docker与Kubernetes的安全加固策略，下列措施正确的有（）。A.以非root用户身份运行容器进程，避免容器内进程具有宿主机的root权限B.在Kubernetes中配置PodSecurityPolicy（或PodSecurityAdmission），限制容器启用特权模式（privileged:true）C.在Dockerfile中使用多阶段构建，仅将运行所需的最小二进制文件拷贝至最终镜像，减小攻击面D.允许容器直接挂载宿主机的敏感目录（如/etc），以便容器内应用读取宿主机配置17.在设计高并发秒杀系统时，为防止超卖并降低数据库压力，常见架构方案中合理的有（）。A.使用Redis的Lua脚本原子性执行“库存预减”操作，若扣减成功则生成订单请求进入消息队列B.将库存数据预先加载至Redis，直接在Redis中完成库存扣减，通过数据库最终扣减兜底C.前端静态页面部署于CDN，通过验证码或答题机制限制瞬时请求量D.应用层使用分布式锁（如Redisson）锁住所有请求，直至库存扣减完成并释放锁18.关于分布式事务方案中TCC（Try-Confirm-Cancel）模式，下列说法正确的有（）。A.Try阶段负责资源检查和预留，不执行真正的业务操作B.Confirm阶段执行真正的业务操作，且需要保证幂等性C.Cancel阶段用于回滚Try阶段预留的资源，若Cancel操作失败，需要重试机制或人工介入D.TCC模式适用于强一致性要求极高、且业务操作可拆分为预留和确认两步的场景19.关于系统性能测试与容量规划，下列说法正确的有（）。A.进行压力测试时，通常需要关注TPS（每秒事务数）、响应时间、资源利用率（CPU、内存、IO）等核心指标B.容量规划的目标是精确预测系统未来一年的峰值负载，因此必须严格依据业务部门提供的增长率数据，该数据通常非常准确C.建立性能基线模型后，可通过线性扩展性测试，评估集群增加节点后性能是否呈线性增长D.全链路压测通常在预发环境进行，为了避免影响生产环境，不应在生产环境进行任何压测20.关于分布式文件存储系统（如Ceph、MinIO）的架构特性，下列描述正确的有（）。A.Ceph采用CRUSH算法控制数据分布，客户端可直接与OSD交互，无需经过中心化元数据服务器，消除了元数据瓶颈B.MinIO采用纠删码（ErasureCoding）技术，将数据切片并计算校验块，相比多副本策略能有效降低存储冗余率C.为保证数据强一致性与高可用，分布式文件系统通常要求所有数据写入必须等待所有副本或校验块写入成功后才返回D.S3兼容接口已成为对象存储的事实标准，使得应用可以无缝迁移至不同的对象存储服务三、填空题（本大题共5小题，每小题2分，共10分。请在横线上填入正确的内容。）21.在微服务架构中，为解决客户端需要维护多个服务地址的问题，通常会引入_______组件，负责服务实例的注册与发现。常见的开源实现包括NetflixEureka、ApacheZookeeper、Consul等。22.在分布式系统中，为解决多个节点之间的时钟不同步问题，通常使用逻辑时钟代替物理时钟，其中Lamport时间戳通过维护_______关系来定义事件的偏序，而VectorClock则能够检测事件之间的并发关系。23.在Linux系统中，用于查看系统网络连接状态（如TCP连接数、端口监听情况）的常用命令是_______。24.在容量规划中，已知某单节点服务峰值处理能力为2000QPS，当前服务部署了3个节点，实测集群整体峰值QPS仅为4200。这种现象通常表明系统存在_______问题（如数据库连接池耗尽、缓存穿透、线程阻塞等），而非节点数量不足。25.在数据库索引优化中，对于联合索引`(a,b,c)`，当查询条件为`WHEREa=1ANDc=2`时，该索引只能使用到最左前缀_______列，c列无法走索引，这种现象被称为“_______”原则。四、简答题（本大题共3小题，每小题8分，共24分。要求回答要点明确，逻辑清晰。）26.在微服务架构中，服务间通信通常采用同步调用（如HTTP/REST、gRPC）和异步调用（如消息队列）。请分别阐述同步调用与异步调用的优缺点，并给出各自适用的典型业务场景（至少各两个场景）。27.某电商系统订单表数据量已超过1亿行，查询性能严重下降。请设计一种基于分库分表与读写分离的架构优化方案，要求说明分片键选择策略、分片算法、数据迁移方案以及查询路由方案（针对非分片键查询）。28.简述缓存穿透、缓存击穿、缓存雪崩的区别，并分别给出至少两种有效的解决方案。五、应用题（本大题共3小题，第29题12分，第30题14分，第31题15分，共41分。要求写出详细分析过程和计算步骤。）29.场景描述：某社交平台“关注Feed流”功能，用户A关注了1000个用户。当A刷新首页时，需要聚合这1000个被关注者最近发布的动态，并按时间倒序排列，分页返回。当前系统采用关系型数据库，通过SQL查询`SELECT*FROMfeedWHEREuser_idIN(A的关注列表)ORDERBYcreated_atDESCLIMIT20`。随着数据量增大，该查询响应时间超过2秒。请回答以下问题：（1）分析该SQL查询慢的根本原因（至少从索引使用、数据扫描范围、排序开销三方面分析）。（4分）（2）设计一个基于“拉模式”+“缓存”的优化方案，画出核心组件交互流程（可用文字描述），并说明该方案相比原始SQL的优势。（4分）（3）针对该Feed流系统，若采用“推模式”进行架构重构，请说明推模式的核心思想、优点以及可能引入的存储问题及解决方案。（4分）30.场景描述：某在线考试系统在特定时间点（如9:00开考）会有大量考生同时登录并提交答案。系统由Nginx集群、应用服务器集群（Tomcat/SpringBoot）、MySQL数据库（主从架构）、Redis缓存集群构成。考试开始时，发现系统响应缓慢，监控数据显示应用服务器CPU使用率不高，但数据库CPU使用率接近100%，且大量SQL查询为`SELECT`操作，查询内容涉及考生个人信息、考试批次信息等。请回答以下问题：（1）分析数据库CPU飙升的可能原因（从缓存策略、连接池配置、SQL写法、数据库参数等方面分析）。（4分）（2）请提出至少5条具体的优化措施，以缓解数据库压力并提升系统吞吐量。（5分）（3）假设考试结束后，成绩汇总模块需要按批次统计每个考生的总分并生成排名。该统计任务耗时较长。请设计一种异步化处理方案，并说明如何保证统计结果最终一致且不丢失。（5分）31.场景描述：某分布式存储系统采用一主三从架构（1个Master，3个Slave），使用异步复制。Master节点与Slave节点之间的网络延迟平均为5ms。系统每秒写入事务量为500TPS，每个事务产生的Binlog大小为10KB。请计算并回答以下问题：（1）在极端情况下（Master突然宕机），可能丢失的最大数据量是多少（KB）？请写出计算过程。（3分）（2）若采用半同步复制（即Master等待至少一个Slave确认收到Binlog后才提交事务），则一个事务的提交延迟至少增加多少时间？此时若每事务提交延迟增加10ms，系统吞吐量理论最大为多少TPS？（3分）（3）若系统要求RPO（恢复点目标）为0，即不允许丢失任何已提交事务，请设计方案说明应如何改造复制架构（可结合MySQLGroupReplication或分布式事务消息队列实现）。（4分）（4）结合CAP定理，分析上述强一致方案在极端网络分区情况下，系统应如何取舍，并说明理由。（4分）参考答案及解析一、单项选择题1.B解析：Saga模式中，编排方式由中心化协调器（如流程引擎、状态机）统一指挥各参与服务的执行与补偿；协同方式则通过事件驱动，各服务自行订阅事件并响应。A错误：Saga不强制要求事件溯源，但事件溯源可作为实现方式之一。C错误：协同方式控制流依赖事件总线，但不一定是消息队列的持久化能力，更强调事件发布/订阅机制。D错误：Saga适用于长事务场景，与读写比例无关；两阶段提交协议在分布式系统中通常不被推荐用于高并发场景，因其阻塞性严重。2.B解析：CAP定理指出在分区（P）发生时，只能在一致性（C）和可用性（A）之间权衡。A错误：金融系统必须保证强一致，应选择CP而非AP。C错误：分布式锁服务为保证互斥安全，必须选择CP，且通过多数派机制（如Zookeeper）可有效避免脑裂。D错误：CAP定理是分布式系统设计的指导，但存在许多优化策略（如最终一致性、BASE理论）进行折中。3.A解析：异步复制下，主库提交事务后并不等待备库接收Binlog。若主库宕机，备库尚未同步的Binlog数据将丢失，这是RPO>0的根本原因。B错误：Binlog格式（ROW/STATEMENT）不影响数据丢失，只影响复制语义。C错误：切换时设置备库只读是为了避免外部写入，与数据丢失无关。D错误：连接池连接数不是导致数据丢失的原因。4.C解析：对于动态个性化内容，CDN边缘节点无法直接缓存最终响应，但可通过边缘计算在边缘节点执行逻辑，向源站API网关动态请求个性化数据，并结合缓存静态框架内容，降低回源压力。A错误：忽略Cookie会导致用户间数据错乱。B错误：完全禁止缓存会使CDN失去价值。D错误：缓存用户特定请求1个月，会导致用户信息更新不及时，且浪费存储空间。5.B解析：应用内存溢出通常是因为容器内存Limit小于应用实际所需内存（如JVM堆+元空间+线程栈等）。正确做法是调整JVM堆参数与容器Limit匹配，并配置HPA（基于内存指标）以自动扩容。A错误：移除Limits会导致节点资源失控，可能引发节点级故障。C错误：BestEffortQoS的Pod在节点资源紧张时优先被驱逐，不适合生产环境。D错误：仅增加节点数量而不调整容器配置，无法解决单个Pod内存不足的问题。6.D解析：尾部采样时，未采样请求的Span数据可在本地暂存（例如写入本地文件或缓冲区），待后续聚合判断是否需要上报，因此D错误。A、B、C描述均正确。7.C解析：分片键应尽量使数据均匀分布。按卖家ID分片，若存在超级大卖家（如头部卖家），则其相关订单数据会集中存储于单个分片，导致数据倾斜和热点问题。A、D通过哈希取模通常能较好均匀分布；B按时间范围分片，在特定时间点（如大促）会产生写入热点，但相比固定卖家倾斜，时间维度尚可通过分片粒度调整缓解。8.C解析：绞杀者模式的核心思想是渐进式替换，可以在单体应用外围逐步拦截并替换特定功能，不需要一次性重写整个应用。C选项描述错误。A、B、D均正确描述了绞杀者模式的特点。9.D解析：epoll的LT模式是默认模式，只要缓冲区有数据，epoll_wait就会持续通知；ET模式仅在状态变化时通知一次，因此ET模式下必须循环读取至EAGAIN，否则会遗漏数据。A错误：LT模式下未读完数据，epoll_wait会继续通知。B错误：ET模式不会持续通知，只通知一次。C错误：LT和ET模式都建议使用非阻塞IO，但LT模式使用阻塞IO也勉强可用，只是不推荐；ET模式必须使用非阻塞IO。10.C解析：RedisCluster中，客户端根据CRC16(key)%16384计算HashSlot，并将请求路由至对应节点。若客户端将请求发送至错误节点（非Slot所在节点），该节点会返回MOVED错误，告知客户端正确的节点地址，客户端需重定向请求。ASK错误用于迁移过程中的临时重定向，与MOVED不同。因此选C。11.B解析：API网关的核心职责包括路由转发、统一鉴权、限流、协议转换、日志监控等。业务逻辑编排通常不应放在网关层，否则网关会变得笨重并成为性能瓶颈，应放在后端服务（如BFF层）。B错误。12.D解析：异地多活中，由于网络延迟较高，通常需要处理跨地域的数据冲突问题。即使设计为“用户只在一个数据中心写入”，也需要考虑用户跨地域访问时的路由策略（如基于用户地理位置路由），且需要处理数据同步冲突（如修改同一条数据）。因此D错误。A、B、C描述均正确。13.C解析：预编译语句、参数化查询、严格转义和ORM参数绑定均是针对SQL注入的有效防御。WAF基于规则匹配，存在绕过可能，不能作为主要防御手段，只能作为辅助。因此效果最弱的是C。14.B解析：A错误：消费者ACK后生产者重发会导致重复消费，且无法保证生产者消息不丢失。B正确：本地消息表方案通过数据库事务保证业务操作与消息记录同时成功，消费者端通过幂等（如唯一键）保证不重复处理。C错误：同步发送保证发送成功，但无法保证消息不重复（Broker可能已存储但返回超时）。D错误：消费者先提交offset再处理业务，若处理失败则消息丢失。15.B解析：速度层负责处理实时数据流，提供低延迟的增量视图。Flink消费Kafka实时流并计算推荐结果属于速度层典型工作。A、C、D均属于批处理层（BatchLayer）工作。二、多项选择题16.A、B、C解析：D错误：容器挂载宿主机敏感目录（如/etc）会带来严重安全风险，一旦容器被攻破，宿主机系统文件将面临篡改风险，应禁止此类挂载。A、B、C均为正确的容器安全加固措施。17.A、B、C解析：A正确：使用Lua脚本在Redis中原子扣减库存，避免并发超卖。B正确：库存预加载至Redis，通过Redis扣减，数据库最终扣减兜底，是典型秒杀方案。C正确：CDN缓存静态页面、验证码限流可减轻服务器压力。D错误：对所有请求加分布式锁会导致请求串行化，系统吞吐量极低，不适合高并发秒杀场景。18.A、B、C、D解析：TCC模式要求业务操作能拆分为Try（资源预留）、Confirm（确认执行）、Cancel（回滚预留）三个阶段。所有阶段都需要实现幂等性，且Cancel失败需要重试或人工处理。TCC适用于强一致性要求高、且业务可拆分的场景。四个选项均正确。19.A、C解析：B错误：业务部门提供的增长率数据往往具有不确定性，容量规划需要结合历史数据、趋势预测、业务活动计划等多方面信息，不能依赖单一数据。D错误：全链路压测可以在生产环境进行，但需要提前做好数据隔离（如使用影子库表）、流量控制（如渐进式加压）和应急预案，并非不能在生产环境压测。20.A、B、D解析：C错误：为保证强一致性与高可用，需要权衡性能。多数分布式文件系统（如Ceph）采用多副本同步写，但MinIO等对象存储采用纠删码写入，通常只需等待足够的数据块和校验块写入成功即可返回，无需等待所有块写入完成。C描述过于绝对。A、B、D描述正确。三、填空题21.注册中心（或服务注册中心）解析：微服务架构中，服务提供者启动时向注册中心注册自身地址，服务消费者通过注册中心获取可用服务实例列表。22.Happened-Before（或“发生于之前”）解析：Lamport时间戳通过定义事件的Happened-Before关系来建立偏序，用于同步逻辑时钟。23.netstat（或ss）解析：netstat-anp或ss-anp可查看网络连接、监听端口等；ss是netstat的现代替代工具。24.性能瓶颈（或资源争用、扩展性瓶颈）解析：集群性能未能随节点数线性扩展，通常是由于存在共享资源瓶颈，如数据库连接池、缓存、线程池、磁盘IO等。25.a；最左前缀（最左匹配）解析：联合索引遵循最左前缀原则，查询条件中缺少中间列b时，索引只能使用a列定位数据，c列无法走索引。四、简答题26.答案要点：（1）同步调用（HTTP/REST、gRPC、Dubbo）：优点：实时性强，调用方能够立即获得结果，业务逻辑清晰，易于理解和调试。缺点：耦合性强，调用方需等待被调用方响应，若被调用方性能下降会阻塞调用方线程；系统整体可用性受限于链路中最慢的服务；在调用链较长时，延迟累积明显。适用场景：实时性要求高的业务，如用户登录鉴权、订单查询、支付结果查询等；内部服务间需要强一致的请求-响应模式，如RPC调用。（2）异步调用（消息队列）：优点：解耦，发送方无需等待接收方处理结果；削峰填谷，能够缓冲突发流量；提高系统响应速度，发送方发送消息后即可继续执行。缺点：最终一致性，接收方处理结果存在延迟；调试和追踪复杂，需要额外机制（如消息ID、TraceID）关联请求；可能出现消息丢失或重复消费，需设计幂等和补偿机制。适用场景：高并发写操作，如秒杀下单、日志采集、用户行为跟踪；业务链路较长且无需实时反馈的场景，如订单完成后发送通知短信、积分累计、数据同步等。27.答案要点：（1）分片键选择策略：由于订单表查询通常以用户ID或订单ID为主，建议选择订单ID或用户ID作为分片键。若按用户ID分片：同一用户的订单集中在同一分片，便于查询某用户订单列表；但存在数据倾斜风险（大用户订单量多）。若按订单ID分片：数据均匀分布，但对“查询某用户的订单列表”场景需路由至所有分片，再聚合结果。推荐方案：以用户ID作为分片键（订单表包含用户ID字段），通过用户ID哈希取模分片，保证同一用户数据分布在同一库表。（2）分片算法：一致性哈希（如环形哈希）或取模算法（如user_id%分片数）。取模算法简单易实现，但分片数变更需数据迁移；一致性哈希在扩容时仅需迁移部分数据。（3）数据迁移方案：a.历史数据全量迁移：通过ETL工具（如DataX）将旧库数据按新分片规则导入各分片。b.增量同步：在迁移期间，通过订阅Binlog（如Canal）将增量数据同步至各分片。c.双写策略：在迁移切换窗口，应用层同时写旧库和新分片，待数据校验一致后切换读写流量。（4）查询路由方案：a.分片键查询：如WHEREuser_id=?，根据分片算法直接路由至对应分片。b.非分片键查询（如按订单号查询订单）：引入映射表或ES索引，存储订单ID与分片键（user_id）的映射关系。先查询映射得到user_id，再路由至对应分片。c.全分片扫描+聚合：对于无法通过映射表确定的查询（如按时间范围查询），需遍历所有分片并聚合结果，通常用于后台离线报表，可结合并行查询和内存归并。28.答案要点：（1）缓存穿透：查询一个不存在的数据，缓存和数据库中都没有，导致请求直接打到数据库。解决方案：a.缓存空值：将空结果（null）也缓存起来，设置较短的TTL（如5分钟），防止同一不存在的数据频繁穿透。b.布隆过滤器（BloomFilter）：在缓存层前置布隆过滤器，判断key是否存在，若不存在则直接返回，拦截无效请求。c.参数校验：在应用层对非法参数（如id<=0）进行拦截。（2）缓存击穿：一个热点key在缓存失效的瞬间，大量并发请求同时查询该key，请求全部落到数据库。解决方案：a.互斥锁（Mutex）：当缓存失效时，只允许一个线程去查询数据库并重建缓存，其他线程等待缓存重建完成后读取缓存。b.逻辑过期：在缓存中设置逻辑过期时间（而非物理TTL），过期后由后台线程异步重建缓存，查询请求先返回旧值，避免阻塞。c.热点key永不过期：对热点key设置物理永不过期，由后台定期更新。（3）缓存雪崩：大量key在同一时间失效，或缓存节点宕机，导致海量请求直接访问数据库，引发数据库崩溃。解决方案：a.缓存TTL随机化：设置缓存过期时间时，在基础时间上增加随机值（如±10%），避免大量key同时失效。b.多级缓存：使用本地缓存（如Caffeine）+分布式缓存（Redis）二级缓存架构，即使Redis宕机，本地缓存仍可支撑部分流量。c.服务降级与熔断：当数据库压力过大时，开启降级（返回默认值或错误信息）或熔断（快速失败），保护数据库。d.集群高可用：Redis采用主从+哨兵或Cluster模式，防止缓存节点宕机导致缓存整体不可用。五、应用题29.答案：（1）SQL查询慢的根本原因：a.索引使用：WHERE条件为`user_idIN(1000个用户ID)`，即使存在`(user_id,created_at)`联合索引，MySQL优化器对于IN列表较长的查询，通常会评估全表扫描或索引扫描的成本。由于IN列表长度过大（1000个），优化器可能放弃索引，改为全表扫描（type=ALL或range），导致IO开销巨大。b.数据扫描范围：若采用索引范围扫描，则需要扫描这1000个用户的所有发布记录，并进行排序取TOP20。随着关注用户发布动态增多，需要扫描的行数可能达到数万甚至数十万行，且无法利用LIMIT提前终止（需排序后取Top20）。c.排序开销：ORDERBYcreated_atDESC需要对扫描结果进行文件排序（filesort）。若扫描行数庞大，且排序字段无索引辅助，则会在临时表或磁盘上进行排序，消耗大量CPU和磁盘IO。（2）“拉模式”+缓存优化方案：方案设计：a.为每个用户维护一个“时间线缓存”（TimelineCache），存储在Redis中，数据结构为ZSET，score为动态发布的时间戳，member为动态ID。例如，key为`timeline:{user_id}`。b.用户A关注了1000个用户，当A刷新Feed流时：应用服务器首先从Redis查询`ZREVRANGEtimeline:10001019`获取前20条动态ID。若缓存未命中（用户首次刷新或缓存过期），则执行原始SQL查询（或采用多线程并发查询被关注用户的动态），将结果写入缓存，再返回给前端。c.当被关注用户（如用户B）发布新动态时：写入Feed表。异步任务（如通过MQ）将新动态ID推入所有关注者（如A）的Timeline缓存中：`ZADDtimeline:10001<timestamp><feed_id>`。同时控制缓存长度（如仅保留最近1000条动态ID），防止ZSET无限膨胀。d.缓存未命中时的兜底：使用多线程（线程池）并发查询被关注用户的动态，每个线程查询一个用户最近N条动态，然后合并排序取TOP20。优势：查询性能大幅提升：RedisZSET的ZREVRANGE操作时间复杂度为O(logN+M)，仅需返回20条，微秒级响应。降低数据库压力：将读请求从数据库转移至缓存，数据库仅需处理写入请求和缓存未命中时的兜底查询。排序开销极小：ZSET天然按score排序，无需额外排序。（3）推模式（Write-Fanout）核心思想及问题：核心思想：在用户发布动态时，主动将该动态写入其所有关注者的Timeline中（即“写放大”）。例如，用户B发布动态后，系统将动态ID推送给B的所有粉丝（如A）的Timeline缓存。优点：读操作极快：用户刷新时直接读取自己的Timeline即可，无需聚合查询，响应时间极低。数据库读压力小：查询路径中不涉及被关注用户动态的聚合操作。可能引入的存储问题及解决方案：问题1：热点用户写放大问题。如果一个超级大V拥有1亿粉丝，每发一条动态需要写入1亿个粉丝的Timeline，导致写操作瓶颈。解决方案：采用“混合模式”。对于粉丝数超过阈值（如100万）的大V，不执行推模式，而是保留“拉模式”；普通用户执行推模式。粉丝刷新时，需要合并普通用户Timeline（缓存中已有）和大V的“拉取”动态。问题2：存储成本巨大。每个用户的Timeline需要存储大量动态ID，假设系统有1亿用户，每个用户存储500条动态，则需存储500亿条记录。解决方案：控制Timeline长度（如仅存最近200条），并通过定期清理（如LRU或定期删除过期数据）控制存储成本。同时，仅存储动态ID（长整型），而非完整内容，减少内存占用。30.答案：（1）数据库CPU飙升的可能原因：a.缓存策略失效：大量查询未命中Redis缓存，导致请求穿透至数据库。可能原因包括：缓存Key设计不合理（如未包含考试批次ID）、缓存过期时间设置过短、或缓存预热失败。b.连接池配置过大：应用服务器连接池最大连接数设置过大，导致数据库同时处理大量并发连接，上下文切换开销增大，CPU飙升。c.SQL写法问题：大量SQL未使用索引或索引失效（如隐式类型转换、函数操作），导致全表扫描，CPU和IO开销巨大。d.数据库参数配置不合理：如InnoDB缓冲池大小过小，导致数据无法缓存于内存，频繁进行磁盘读写；或查询缓存（QueryCache）开启但命中率低，反而增加CPU开销。e.热点数据集中：考试开始时，所有考生同时查询考试批次信息、考生个人信息，这些数据集中在少数数据页，导致并发访问同一行数据，产生锁竞争和CPU等待。（2）具体优化措施：a.优化Redis缓存策略：在考试开始前进行缓存预热，将考试批次信息、考生基本信息（如姓名、照片、考场号）预加载至Redis。设置合理的TTL（如考试期间不过期，考试结束后延迟删除）。采用多级缓存（本地Caffeine+Redis），减少Redis网络开销。b.优化SQL语句和索引：为高频查询字段（如考生ID、批次ID）建立联合索引。避免在索引列上使用函数或隐式转换。使用覆盖索引（CoveringIndex），避免回表查询。c.限制应用服务器连接池大小：根据数据库规格和压测数据，合理配置连接池（如Druid、HikariCP）的最大连接数（如20-50），避免过多连接争抢CPU。d.数据库参数调优：增大InnoDB缓冲池（innodb_buffer_pool_size）至物理内存的70%左右；关闭QueryCache（MySQL8.0已移除）；调整并发线程数（innodb_thread_concurrency）等。e.读写分离与分流：将考试期间的查询流量引导至只读副本（Slave），主库仅处理写入（如提交答案）。在应用层通过读写分离中间件（如ShardingSphere）自动路由。f.应用层限流与降级：通过Sentinel或Hystrix对查询接口进行限流，防止瞬时流量压垮数据库。当数据库压力达到阈值时，降级为返回静态页面或缓存数据。（3）异步化处理方案设计：a.方案设计：考试成绩汇总模块不直接同步查询数据库进行统计，而是通过消息队列（如RocketMQ、Kafka）触发。考试结束后，管理后台发送一条“批次成绩汇总任务”消息至MQ。异步消费者接收消息后，执行以下步骤：i.从订单/答卷表中批量查询该批次所有考生的成绩数据（分页查询，每页1000条）。ii.在内存中计算总分，并按分数排序。iii.将统计结果（排名列表）写入Redis缓存（或结果表）。iv.处理完成后，更新任务状态（如任务表status=成功），并发送通知至管理后台。b.保证最终一致且不丢失的措施：消息可靠性：使用RocketMQ的事务消息，保证“考试状态更新”和“发送汇总消息”两个操作的原子性。若消息发送失败，则定时任务重试查询未完成批次并补发消息。消费幂等性：在消费端使用批次I