技术顾问笔试试题及答案

技术顾问笔试试题及答案一、单项选择题（每题2分，共20分）1.以下关于TCP三次握手的描述中，错误的是（）A.第一次握手：客户端发送SYN=1，seq=x的报文B.第二次握手：服务器发送SYN=1、ACK=1，seq=y，ack=x+1的报文C.第三次握手：客户端发送ACK=1，seq=x+1，ack=y+1的报文D.三次握手的目的是为了确认双方的发送和接收能力答案：无错误选项。（注：本题设计为干扰项陷阱，实际四次挥手易混淆，三次握手标准流程中ABCD均正确，需考生仔细辨析常见误区。）2.某电商系统的订单表（order）包含字段：order_id（主键）、user_id、amount（金额）、create_time（创建时间），现需统计近30天每个用户的订单总金额，最优的SQL语句是（）A.SELECTuser_id,SUM(amount)FROMorderWHEREcreate_time>NOW()-INTERVAL30DAYGROUPBYuser_idB.SELECTuser_id,SUM(amount)FROMorderWHEREcreate_timeBETWEENDATE_SUB(NOW(),INTERVAL30DAY)ANDNOW()GROUPBYuser_idC.SELECTuser_id,SUM(amount)FROMorderGROUPBYuser_idHAVINGcreate_time>NOW()-INTERVAL30DAYD.SELECTuser_id,SUM(amount)FROMorderWHEREcreate_time>=DATE_ADD(NOW(),INTERVAL-30DAY)GROUPBYuser_id答案：D。解析：A选项中NOW()-INTERVAL30DAY可能因时区问题导致边界错误；B选项BETWEEN包含两端点，但NOW()是动态值，可能导致统计范围偏移；C选项HAVING子句在分组后过滤，无法利用create_time索引，性能较差；D选项DATE_ADD明确指定时间范围，且WHERE条件可利用create_time索引，效率更高。3.微服务架构中，服务间通信使用gRPC相比HTTP/1.1的优势不包括（）A.基于HTTP/2，支持多路复用B.二进制协议，数据序列化效率更高C.天然支持服务发现与负载均衡D.自动提供跨语言客户端代码答案：C。解析：gRPC本身不提供服务发现和负载均衡功能，需依赖Consul、Eureka等中间件或K8s的Service机制实现；A、B、D均为gRPC的典型优势。4.某分布式系统出现“脑裂”（SplitBrain）问题，最有效的解决方法是（）A.增加心跳检测的频率B.引入仲裁机制（如ZooKeeper或共享存储）C.提高节点的网络带宽D.对关键数据进行多副本同步答案：B。解析：脑裂本质是节点间通信中断导致各自认为对方失效，仲裁机制通过第三方权威节点裁决主节点身份，是根本解决方案；A、C仅优化通信检测，无法解决仲裁问题；D是数据冗余措施，不直接处理脑裂。5.以下关于数据库索引的描述，错误的是（）A.唯一索引可以保证列值的唯一性B.覆盖索引（CoveringIndex）可以避免回表查询C.联合索引的顺序应遵循“最左匹配原则”D.索引越多，查询性能一定越好答案：D。解析：索引会增加写操作（INSERT/UPDATE/DELETE）的开销，过多索引可能导致写性能下降，需根据业务读写比例权衡；A、B、C均正确。二、简答题（每题8分，共40分）1.请描述如何排查线上服务器CPU使用率持续90%以上的问题。答案：（1）定位进程：使用top命令查看CPU占用最高的进程PID；（2）分析线程：通过top-Hp<PID>定位进程内高CPU的线程，记录线程ID（转换为十六进制）；（3）提供线程快照：使用jstack（Java）或gdb（C/C++）导出进程的线程堆栈，结合十六进制线程ID找到对应栈帧，分析是否存在死循环、高复杂度计算或锁竞争；（4）检查系统层面：使用vmstat查看上下文切换次数（cs列），若异常升高可能是线程频繁切换导致；使用iostat检查磁盘IO是否过高（可能触发大量CPU用于IO等待）；（5）代码层面：结合APM工具（如SkyWalking、Pinpoint）追踪慢调用，定位热点代码；检查是否有未优化的循环、正则表达式或递归调用；（6）资源限制：确认是否因内存不足导致频繁Swap，CPU被用于页面交换；（7）外部依赖：检查是否有第三方服务响应延迟，导致本地线程阻塞后被唤醒时集中占用CPU。2.设计一个高并发场景下的用户登录接口，需要考虑哪些关键技术点？答案：（1）防暴力破解：通过验证码（图形/短信）、登录失败次数限制（如5分钟内5次失败则锁定账号）、IP访问频率控制（如每分钟10次）；（2）身份验证优化：密码采用PBKDF2或BCrypt哈希（带盐值），避免明文传输；使用JWT（需设置合理过期时间）或Token+Redis存储会话（分布式场景下）；（3）流量削峰：通过Nginx限流（如限制单个IP每秒10次请求）、网关层（如Sentinel）做熔断降级；（4）数据库保护：登录验证涉及查询用户表，需对user_name字段建立索引；使用读写分离，主库处理写（如密码错误次数更新），从库处理读（用户信息查询）；（5）分布式Session：若后端是微服务架构，避免Session绑定（如通过Nginx的ip_hash），改用Redis存储Session信息，设置合理的过期时间和淘汰策略；（6）日志与监控：记录登录失败原因（密码错误/账号锁定）、耗时、IP来源；监控接口QPS、错误率、数据库查询耗时，及时触发告警；（7）安全加固：HTTPS加密传输，防止中间人攻击；检查是否存在SQL注入（需使用预编译语句）、XSS（如返回的用户信息需转义）。3.说明Kubernetes中Pod、ReplicaSet、Deployment的关系及各自作用。答案：（1）Pod是K8s的最小调度单元，封装一个或多个容器（共享网络和存储），代表单个应用实例；（2）ReplicaSet的作用是确保指定数量的Pod副本始终运行（通过标签选择器关联Pod），实现水平扩展和故障恢复；（3）Deployment是更高阶的控制器，管理ReplicaSet的生命周期（如滚动更新、回滚），支持声明式定义应用的部署策略（如更新策略、滚动批次大小、回滚版本）；关系：Deployment通过创建ReplicaSet来管理Pod，ReplicaSet负责维持Pod的期望副本数，Pod是实际运行的容器组。Deployment→ReplicaSet→Pod形成层级控制链，Deployment允许用户无需直接操作ReplicaSet即可完成复杂的部署操作。4.简述API设计中“RESTful”与“GraphQL”的主要差异及适用场景。答案：主要差异：（1）数据获取方式：RESTful通过不同URL（资源路径）和HTTP方法（GET/POST）定义操作，客户端需调用多个接口获取关联数据；GraphQL通过单个POST请求（发送查询语句）获取指定字段的数据，客户端控制返回字段；（2）版本控制：RESTful通常通过URL（如/v1/user）或请求头（Accept:application/vnd.example.v1+json）管理版本；GraphQL通过模式（Schema）演进（新增字段不影响旧客户端，废弃字段标记为@deprecated）；（3）服务端压力：RESTful可能因客户端需要关联数据而多次调用接口，增加服务端负载；GraphQL通过单次请求减少网络开销，但需服务端高效解析复杂查询（可能存在深度嵌套查询导致的性能问题）；适用场景：RESTful适合资源导向、接口功能稳定、需要缓存（如CDN缓存GET请求）的场景（如电商商品详情页）；GraphQL适合客户端需求多变（如不同终端需要不同数据字段）、需要减少网络请求次数的场景（如移动端应用，网络带宽有限）。5.如何评估一个技术方案的可行性？请列举至少5个评估维度。答案：（1）技术适配性：方案是否与现有技术栈兼容（如Java系统引入Go服务需考虑跨语言调用成本），是否符合团队技术储备（避免选择团队完全陌生的技术）；（2）性能指标：关键性能参数（如QPS、延迟、吞吐量）是否满足业务需求（如电商大促要求接口响应时间<500ms），是否有容量规划（如预估3年后用户增长带来的资源需求）；（3）成本投入：包括开发成本（人力/时间）、运维成本（服务器/监控/故障排查）、第三方服务成本（如使用云数据库的费用）；（4）风险可控性：是否存在单点故障（如依赖单一第三方服务），是否有容灾方案（如主备切换、多活架构），异常场景处理（如网络中断时的重试策略）；（5）扩展性：方案是否支持水平扩展（如数据库分库分表、服务无状态化），新功能是否容易集成（如模块化设计、接口松耦合）；（6）合规与安全：是否符合数据隐私法规（如GDPR、等保三级），敏感数据处理（如加密存储、传输），是否存在安全漏洞（如SQL注入、越权访问）。三、案例分析题（每题20分，共40分）案例1：某金融公司现有核心交易系统基于单体架构，采用MySQL单库单表存储交易记录（日交易量约500万条，数据量已达10亿条），近期出现以下问题：（1）交易接口响应时间从200ms上升至800ms；（2）数据库备份时间超过8小时，影响日常维护；（3）开发新功能时，修改代码容易引发其他模块故障。请设计改进方案，要求包含架构调整、数据库优化、开发流程优化三部分，并说明关键实施步骤。答案：一、架构调整方案目标：从单体架构迁移至微服务架构，按业务功能拆分服务（如交易服务、账户服务、风控服务）。关键步骤：1.服务拆分：通过领域驱动设计（DDD）识别核心域（交易处理）、支撑域（账户管理）、通用域（日志服务），将交易系统拆分为独立的交易服务（负责交易创建、状态更新）、账户服务（负责余额扣减），使用gRPC或HTTP/2进行服务间通信；2.引入API网关：统一入口，实现身份验证、限流（如限制单个服务每秒1000次请求）、路由（根据请求路径转发至对应微服务）；3.异步化处理：非核心操作（如交易通知、日志记录）通过消息队列（Kafka/RabbitMQ）异步执行，减少主线程等待时间（如交易提交后发送消息至队列，由独立消费者处理通知）；4.服务治理：使用服务注册中心（Consul/Eureka）实现服务发现，结合Hystrix或Sentinel实现熔断（如交易服务调用账户服务失败率超50%则熔断，返回降级信息）、负载均衡（轮询/加权随机）。二、数据库优化方案目标：解决单库单表性能瓶颈，优化备份效率。关键步骤：1.分库分表：按交易时间（按月）做水平分表（如交易表拆分为trade_202401、trade_202402），按用户ID取模（如1024库）做水平分库，减少单表数据量（单表控制在1亿条以内）；2.读写分离：主库处理写操作（交易创建、更新），从库处理读操作（交易查询），通过中间件（如MyCat、ShardingSphere）自动路由；3.索引优化：针对高频查询（如根据user_id和create_time查询交易记录）创建联合索引（user_id,create_time），删除冗余索引（如仅基于create_time的索引，若已被联合索引覆盖）；4.备份策略调整：使用物理备份工具（如PerconaXtraBackup）替代逻辑备份（mysqldump），缩短备份时间；对分库后的数据按库并行备份（如同时备份10个从库），总时间从8小时降至1小时内；5.引入缓存：高频查询的交易详情（如近30天的交易）缓存至Redis（设置TTL=7天），减少数据库读压力（缓存命中率目标90%以上）。三、开发流程优化方案目标：降低功能修改的耦合风险，提升研发效率。关键步骤：1.模块化设计：每个微服务独立代码仓库，使用Maven/Gradle管理依赖，避免共享代码导致的级联修改（如交易服务和账户服务不再共用同一个Utils模块，改为通过API调用）；2.自动化测试：增加单元测试（覆盖率≥80%）、集成测试（验证服务间调用）、契约测试（使用Pact定义服务间接口规范，确保提供者和消费者代码兼容）；3.灰度发布：新功能上线时通过API网关按比例（如10%用户）灰度，监控接口错误率、耗时，无异常后全量发布；4.分支策略：采用GitFlow，主分支（main）仅允许通过CI/CD流水线合并经过测试的代码，开发分支（develop）用于功能集成，避免直接修改主分支导致的故障；5.日志与监控：为每个微服务添加唯一请求ID（TraceID），通过ELK（Elasticsearch+Logstash+Kibana）集中日志，结合Prometheus+Grafana监控服务QPS、错误率、数据库慢查询（阈值设置为≥1s），快速定位问题。案例2：某企业计划将本地数据中心的业务系统迁移至阿里云，涉及财务系统（敏感数据）、OA系统（内部协作）、电商网站（面向用户）。作为技术顾问，需制定迁移方案。请回答以下问题：（1）迁移前需要完成哪些准备工作？（2）针对三类系统的特点，分别设计迁移策略（包括迁移方式、数据同步方法、风险控制措施）。答案：（1）迁移前准备工作：①资产清点：梳理本地系统的服务器数量（CPU/内存/磁盘配置）、数据库类型（MySQL/Oracle）及数据量（如财务系统数据库200GB）、依赖的第三方服务（如短信网关）；②业务评估：分析系统的业务优先级（财务系统为最高优先级，需最小化停机时间）、流量峰值（电商网站大促期间QPS达5000）、数据敏感性（财务系统需符合等保三级要求）；③网络规划：申请阿里云专有网络（VPC），规划IP地址段（如/16），建立本地数据中心与阿里云的VPN连接（或购买物理专线，提升传输稳定性）；④安全合规：评估财务系统迁移后的数据存储位置（选择同地域合规的可用区），加密方案（如数据库加密使用阿里云KMS管理密钥），访问控制（通过RAM角色限制不同系统的访问权限）；⑤测试环境搭建：在阿里云上搭建与本地相同的测试环境（包括数据库、中间件），验证应用兼容性（如OA系统的Java版本是否与阿里云ECS的JDK匹配）、性能（如电商网站在云服务器上的响应时间是否满足要求）。（2）三类系统的迁移策略：财务系统（敏感数据）迁移方式：采用“停机迁移+双活过渡”。数据同步方法：①全量迁移：使用阿里云DTS（数据传输服务）将本地MySQL/Oracle数据库全量迁移至阿里云RDS（设置为只读模式）；②增量同步：在本地数据库开启Binlog，通过DTS实时同步增量数据至RDS，确保迁移期间数据一致；③切换验证：选择业务低峰期（如凌晨）停止本地财务系统写入，待增量同步完成后，将应用连接切换至阿里云RDS（设置为读写模式），验证交易正确性（如核对当日凭证数量）。风险控制：①数据加密：迁移过程中使用SSL加密传输，存储时启用RDS透明数据加密（TDE）；②回滚方案：保留本地数据库7天，切换后若出现性能问题（如查询耗时超1s），通过DTS反向同步数据回滚至本地；③访问控制：仅允许财务部门IP通过VPN访问财务系统，禁用公网暴露，使用WAF（Web应用防火墙）拦截SQL注入攻击。OA系统（内部协作）迁移方式：“逐步迁移+本地共存”。数据同步方法：①文件迁移：OA系统的附件（如文档、图片）通过阿里云OSS迁移工具（ossutil）并行上传至OSS（设置存储类型为标准存储，确保低延迟访问）；②数据库迁移：使用DTS迁移本地MySQL数据库至阿里云RDS，由于OA系统对实时性要求较低（允许延迟30分钟），可采用定时全量同步（每日凌晨1点）+手动触发增量同步；③应用迁移：将OA系统的Tomcat服务器迁移至阿里云ECS（选择与本地相同的实例规格c6.large），通过Nginx做负载均衡（本地OA与云端OA共存，通过DNS解析逐步切换用户访问）。风险控制：①兼容性测试：迁移前在测试环境验证OA系统的LDAP集成（