系统架构师系统设计面试题及答案

2026年系统架构师系统设计面试题及答案题型一：分布式系统设计（共3题，每题20分）题目1（20分）：背景：某电商平台计划在2026年上线一个支持全球用户的高并发订单系统，预估峰值QPS为10万，订单数据量每天增长约50万条。系统需满足以下要求：1.高可用性：节点故障自动容灾，RPO≤1分钟，RTO≤5分钟。2.低延迟：订单创建和查询接口响应时间不超过200ms。3.数据一致性：订单状态变更需最终一致性，允许短暂不一致（如用户下单后1秒内可能显示“待支付”）。4.地域扩展：支持欧美、亚太、中东三大区域，每个区域需独立部署，跨区域订单需自动路由到最近节点。要求：-设计系统整体架构图，标注核心组件及交互流程。-说明如何实现高可用、低延迟和数据一致性。-提出至少两种可扩展方案（如读写分离、弹性伸缩）。答案与解析：架构设计（图略，文字描述）：系统采用多区域分布式架构，核心组件包括：1.接入层（APIGateway）：负责请求路由、限流和负载均衡，采用全球CDN节点分发流量。2.订单服务（OrderService）：微服务架构，按区域部署（如欧美区、亚太区），使用Redis缓存热点订单，RocksDB存储事务日志。3.订单存储（分布式数据库）：-写端：使用Raft协议的TiKV或CockroachDB，确保强一致性写入。-读端：通过ShardingSphere分库分表，配合本地缓存+异地多活副本实现快速查询。4.消息队列（Kafka/Flink）：订单变更事件异步推送至下游（如支付、风控系统）。5.跨区域同步（gRPC+MTLS）：使用双向TLS加密的gRPC实现区域间状态同步。关键设计点：-高可用：-多副本部署：订单服务每个区域部署3个副本（Active-Passive），使用ZooKeeper实现故障自动切换。-异地多活：订单存储采用多区域副本，通过Raft日志同步，保证跨区域故障时数据不丢失。-低延迟：-本地缓存：Redis集群缓存高频查询订单（如订单详情），TTL设置为300s。-异步化：支付回调通过消息队列处理，避免同步阻塞。-数据一致性：-最终一致性方案：订单创建后写入消息队列，下游系统通过补偿事务（如重试机制）确保状态同步。-可扩展方案：1.读写分离：订单服务写端使用Raft主库，读端通过分库分表路由到从库。2.弹性伸缩：使用Kubernetes+HorizontalPodAutoscaler（HPA）自动扩容订单服务副本。题目2（20分）：背景：某金融科技公司需要设计一个实时信贷审批系统，要求在用户提交申请后30秒内给出审批结果，支持千万级用户并发申请。系统需满足：1.实时性：信贷评分计算、反欺诈校验需并行处理。2.安全性：用户敏感信息（如收入、征信）需加密存储和传输。3.可解释性：审批结果需提供关键评分依据（如“收入达标，但征信查询过于频繁”）。要求：-设计系统架构，说明如何实现实时计算和并行处理。-提出至少两种抗作弊方案。-解释如何保证数据安全性和可解释性。答案与解析：架构设计（图略，文字描述）：系统采用流批一体架构，核心组件包括：1.接入层（KafkaStreams）：用户申请接入后，通过TLS加密传输至消息队列，并做初步校验（如参数格式）。2.实时计算引擎（Flink）：-信贷评分：使用FlinkCEP（ComplexEventProcessing）实时计算用户行为特征（如查询征信次数）。-反欺诈校验：调用第三方反欺诈API（如1秒内响应），结果缓存至Redis。3.信贷决策引擎（规则引擎）：根据实时计算结果，结合预设规则（如“征信查询超过3次拒绝”）输出审批结果。4.存储层：-敏感数据加密存储（如使用AWSKMS或阿里云SEK），使用属性加密技术（如HomomorphicEncryption）支持查询时解密。-审批日志使用分布式时序数据库（如InfluxDB）记录，支持按时间反查依据。关键设计点：-实时计算与并行处理：-Flink任务拆分：将信贷评分和反欺诈校验拆分为独立子任务，通过Flink任务并行执行。-状态共享：使用FlinkStateBackend（如RocksDB）存储用户会话状态，避免重复计算。-抗作弊方案：1.设备指纹+IP黑名单：对高频异常请求（如1分钟内10次申请）触发风控告警。2.活体检测：在接入层嵌入活体检测（如动态滑块验证码）。-数据安全与可解释性：-数据安全：敏感数据使用AES-256加密，传输通过TLS1.3加密。-可解释性：审批日志记录计算步骤（如“征信评分占30%权重，当前得分为85”），前端以可视化形式展示（如“收入达标，但查询征信次数过高”）。题目3（20分）：背景：某物流公司需要设计一个智能调度系统，每天处理超过100万单，需在1小时内完成路径规划并下发任务给司机。系统需满足：1.动态路由：实时响应路况变化（如堵车、修路），自动调整路径。2.任务分配：根据司机位置、订单时效性、载重限制等动态分配任务。3.容错性：司机离线时，任务自动迁移到其他司机。要求：-设计系统架构，说明如何实现动态路由和任务分配。-提出至少一种容错方案。-解释如何优化系统扩展性。答案与解析：架构设计（图略，文字描述）：系统采用事件驱动架构，核心组件包括：1.接入层（Pulsar）：接收司机位置上报（通过WebSocket）和订单请求（HTTP/2），消息体压缩传输。2.调度引擎（Kubernetes+SpringCloud）：-路径规划：调用第三方地图API（如高德地图SDK），结合实时路况动态调整路径。-任务分配：使用贪心算法+优先级队列（订单类型、时效性、距离排序）。3.司机端SDK：司机App实时同步位置和任务状态，离线时通过本地缓存执行任务。4.存储层：-任务队列（RabbitMQ）：按区域分片，确保高可用。-路径缓存（RedisCluster）：存储热点路径（如城市中心区域），减少API调用。关键设计点：-动态路由与任务分配：-动态路由：调度引擎每5分钟拉取地图API路况信息，使用A算法计算最优路径。-任务分配：司机状态（在线/离线）通过WebSocket实时更新，调度引擎触发重分配。-容错方案：-本地任务缓存：司机离线时，SDK将任务存储本地，恢复连接后自动同步至云端。-扩展性优化：1.区域化部署：按城市划分调度节点，减少跨区域网络延迟。2.服务化拆分：将路径规划、任务分配拆分为独立服务，支持独立扩容。题型二：云原生与容器化技术（共2题，每题25分）题目4（25分）：背景：某电商SaaS服务商需要将现有单体应用拆分为微服务，并迁移至AWS云平台。应用特点：1.交易系统：高并发（峰值QPS5万），依赖事务数据库（PostgreSQL）。2.用户服务：状态无中心化（如用户等级、积分）。3.运维痛点：手动扩容耗时，依赖状态文件（如Redis持久化）。要求：-设计微服务拆分方案及云原生改造方案。-说明如何解决事务数据库拆分问题。-提出至少两种运维自动化方案。答案与解析：拆分方案（图略，文字描述）：1.交易系统拆分：-订单服务（PostgreSQL）：保留事务性，按订单号分库分表（如ShardingSphere）。-库存服务（MySQL）：异步更新库存，使用Redis缓存热点库存。2.用户服务拆分：-用户信息（状态化）：使用无状态Redis集群。-用户等级（中心化）：新建LevelService，使用DynamoDB（支持TTL过期）。云原生改造方案：1.容器化：使用Dockerfile打包服务，通过ECSFargate实现弹性伸缩。2.服务发现：使用AWSALB（ApplicationLoadBalancer）+NginxIngressController。3.配置中心：使用AWSParameterStore，动态下发配置。事务数据库拆分方案：-分布式事务方案：-2PC+补偿事务：订单服务调用库存服务时，使用消息队列（SQS）保证最终一致性。-本地消息表：在PostgreSQL中增加消息表，异步同步到下游系统。运维自动化方案：1.基础设施即代码（IaC）：使用Terraform管理AWS资源（VPC、RDS、S3）。2.CI/CD：GitHubActions自动化构建、测试、部署，配合Canary发布。题目5（25分）：背景：某直播平台需要设计一个支持百万并发用户的实时互动系统，包括弹幕、点赞、礼物等功能。系统需满足：1.低延迟：弹幕消息需在用户发送后100ms内显示。2.高并发写入：每秒处理超过50万条弹幕消息。3.可观测性：需监控消息队列积压、服务响应时间等指标。要求：-设计系统架构，说明如何实现低延迟和高并发。-提出至少两种可观测性方案。-解释如何处理消息重复问题。答案与解析：架构设计（图略，文字描述）：系统采用流批一体化架构，核心组件包括：1.接入层（Nginx+WebSocket）：用户连接后建立WebSocket长连接，使用Brotli压缩传输。2.消息队列（Kafka）：消息分区按用户ID哈希，每个分区1GB，消息重试3次后丢弃。3.消息处理：-弹幕服务（Flink）：使用FlinkCEP检测重复弹幕（如“哈哈哈”连续出现3次），并统计用户发言频率。-实时计算：计算热点弹幕（如“前方高能”），用于首页推荐。4.存储层：-RedisCluster：缓存热点用户弹幕（如最近100条），TTL60s。-关系型数据库（PostgreSQL）：记录用户发言历史（按日期分表）。关键设计点：-低延迟与高并发：-消息队列优化：Kafka分区数设置为1000，每个分区由1个Flink任务处理。-异步化：弹幕展示通过WebSocket推送，避免同步阻塞。-可观测性方案：1.Prometheus+Grafana：监控Kafka队列积压（如`kafka.message.in.fifo`指标）。2.SkyWalking：全链路追踪，定位慢请求（如弹幕入库耗时）。-消息重复处理：-幂等设计：弹幕服务使用Redis事务（SETNX+EXPIRE）防止重复入库。-去重逻辑：通过Flink的状态管理（如`StateBackend`）统计用户最近1分钟发言次数。题型三：数据库与存储设计（共2题，每题25分）题目6（25分）：背景：某外卖平台需要设计一个支持亿级用户的订单数据库，要求：1.高并发写入：每秒写入超过100万订单，支持秒杀场景。2.数据一致性：订单创建后需强一致性，但库存扣减可最终一致。3.多租户隔离：不同商家订单需物理隔离。要求：-设计数据库架构，说明如何实现高并发写入和数据一致性。-提出至少两种多租户隔离方案。-解释如何优化热点数据查询。答案与解析：数据库架构（图略，文字描述）：1.数据库选型：-写端：CockroachDB（支持分布式事务和强一致性）。-读端：TiKV（支持水平分片和快速查询）。2.表结构：sqlCREATETABLEorders(order_idUUIDPRIMARYKEY,user_idUUID,merchant_idUUID,order_timeTIMESTAMP,statusVARCHAR(10));3.索引优化：-主键索引（order_id），二级索引（user_id、merchant_id）。关键设计点：-高并发写入与数据一致性：-写入分片：按`user_id`哈希分片，每个分片由独立节点处理。-库存扣减方案：1.订单创建写入消息队列（Kafka），库存服务消费消息扣减库存（可容忍1秒延迟）。2.若库存不足，订单状态改为“待支付”，后续超时自动取消。-多租户隔离方案：1.物理隔离：每个商家数据存储在独立分片（如`orders_merchant_1`）。2.逻辑隔离：前端通过SQL参数（如`WHEREmerchant_id=?`）过滤数据。-热点数据查询优化：-预加载数据：商家首页订单通过RedisCluster缓存（如“最近100单”）。-查询分片：用户订单查询时，根据`user_id`路由到对应分片。题目7（25分）：背景：某社交平台需要设计一个支持视频点播的系统，日均播放量1亿次，需满足：1.高并发读取：视频播放请求需在200ms内返回。2.存储成本优化：视频文件按热度分级存储（热视频使用SSD，冷视频使用HDD）。3.防盗链：需防止用户通过工具盗链播放视频。要求：-设计存储架构，说明如何实现高并发读取和存储成本优化。-提出至少一种防盗链方案。-解释如何处理视频冷热分层。答案与解析：存储架构（图略，文字描述）：1.存储层：-热视频：AWSEBSSSD（如gp3型），配合CloudFront加速。-冷视频：S3GlacierDeepArchive（延迟访问，低成本）。2.CDN缓存：-CloudFront缓存热点视频（如“最近播放榜”），TTL24h。-边缘节点动态刷新缓存（如用户首次请求时预热）。关键设计点：-高并发读取与存储成本优化：-分级存储策略：1.热度评估：通过播放量、点赞数等指标，使用Elasticache（RedisCluster）