后端开发试题及答案

后端开发试题及答案一、选择题（每题3分，共15分）1.以下关于MySQL索引的描述，错误的是（）A.主键索引自动创建，属于聚簇索引B.联合索引遵循最左匹配原则C.覆盖索引可以避免回表查询D.索引越多，查询性能一定越好答案：D解析：索引会增加写操作（INSERT/UPDATE/DELETE）的开销，过多索引可能导致写性能下降，需根据业务场景权衡。2.HTTP协议中，206状态码表示（）A.资源部分可用B.请求成功但无内容返回C.重定向到新URLD.请求被服务器拒绝答案：A解析：206（PartialContent）用于分块传输场景（如大文件下载），表示响应是请求资源的部分内容。3.数据库事务的隔离级别中，“可重复读”能解决的问题是（）A.脏读B.幻读C.更新丢失D.以上都不对答案：A解析：可重复读（RepeatableRead）保证同一事务内多次读取结果一致，解决脏读（读取未提交数据），但无法完全避免幻读（事务内新插入数据导致的不一致）。4.以下哪种场景适合使用消息队列（）A.实时性要求极高的支付扣款B.日志收集与异步分析C.用户登录状态校验D.数据库主从同步答案：B解析：消息队列适用于异步解耦、流量削峰场景，日志收集后异步分析符合该场景；支付扣款需强一致性，不适合异步；登录校验需实时响应；主从同步通常由数据库自身机制实现。5.关于Java中线程池的描述，错误的是（）A.FixedThreadPool核心线程数等于最大线程数B.CachedThreadPool适用于短时间内大量任务的场景C.线程池的拒绝策略包括AbortPolicy、CallerRunsPolicy等D.线程池的keepAliveTime仅对非核心线程有效答案：D解析：若设置allowCoreThreadTimeOut为true，核心线程也会在空闲超时后被回收，此时keepAliveTime对核心线程有效。二、简答题（每题8分，共40分）1.简述RESTfulAPI的设计原则，并举例说明资源的URI设计。答案：RESTful设计原则包括：资源导向：用名词表示资源（如/users、/orders），避免动词（如/getUser）；HTTP方法映射操作：GET（查询）、POST（创建）、PUT（全量更新）、PATCH（部分更新）、DELETE（删除）；状态无关联：每个请求包含足够信息，服务器不保存客户端状态；统一接口：通过URI标识资源，通过HTTP头传递元数据（如Content-Type）；超媒体驱动（HATEOAS）：响应中包含关联资源的链接（如查询用户时返回/orders?userId=123的链接）。示例：获取ID为123的用户订单列表，URI设计为GET/users/123/orders。2.如何优化MySQL慢查询？请列举至少4种方法。答案：（1）分析慢查询日志，定位执行时间长的SQL；（2）使用EXPLAIN查看执行计划，检查是否全表扫描（type=ALL）、索引是否生效（key字段是否为NULL）；（3）为WHERE、JOIN、ORDERBY、GROUPBY中的列添加合适索引（避免冗余索引）；（4）优化SQL写法：避免SELECT（使用覆盖索引）、减少子查询（改用JOIN）、避免在索引列上使用函数或表达式（如WHEREDATE(create_time)='2024-01-01'应改为create_timeBETWEEN'2024-01-01'AND'2024-01-02'）；（4）优化SQL写法：避免SELECT（使用覆盖索引）、减少子查询（改用JOIN）、避免在索引列上使用函数或表达式（如WHEREDATE(create_time)='2024-01-01'应改为create_timeBETWEEN'2024-01-01'AND'2024-01-02'）；（5）对大表进行分库分表（如按时间或ID哈希分片）；（6）增加缓存（如Redis）减少数据库查询次数。3.分布式锁的常见实现方式有哪些？对比Redis和ZooKeeper实现的优缺点。答案：常见实现方式：Redis（基于setNX+过期时间）、ZooKeeper（基于临时顺序节点）、数据库（基于唯一索引）。Redis与ZooKeeper对比：性能：Redis基于内存，QPS更高，适合高并发场景；ZooKeeper需写入磁盘并同步集群，性能较低；可靠性：ZooKeeper通过ZAB协议保证强一致性，锁释放更可靠（临时节点随会话失效自动删除）；Redis主从切换时可能出现锁丢失（如主节点写入锁后未同步到从节点就宕机）；锁特性：ZooKeeper支持公平锁（按节点顺序获取），Redis需额外逻辑实现公平性；复杂度：Redis实现简单（依赖set命令），ZooKeeper需监听节点变化，代码复杂度高。4.解释Java中接口和抽象类的区别，并举例说明使用场景。答案：区别：接口中方法默认是publicabstract（Java8前），抽象类可包含具体方法；类可实现多个接口，但只能继承一个抽象类；接口不能定义成员变量（除staticfinal常量），抽象类可定义普通成员变量；接口强调“行为规范”，抽象类强调“模板设计”。场景示例：接口：定义统一行为（如支付接口PayService，包含pay()、refund()方法，具体实现由AlipayService、WechatPayService完成）；抽象类：定义公共模板（如Excel导出抽象类AbstractExcelExporter，包含通用的buildHeader()方法，子类实现buildData()方法填充具体数据）。5.简述JWT（JSONWebToken）的结构和使用流程。答案：JWT由三部分组成，用点分隔：头部（Header）：包含算法（如HS256）和令牌类型（JWT），Base64Url编码；载荷（Payload）：包含声明（如用户ID、过期时间exp、签发时间iat），Base64Url编码；签名（Signature）：对前两部分的签名，防止数据篡改，计算方式为：HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),密钥)。使用流程：（1）用户登录验证成功后，服务器生成JWT并返回客户端；（2）客户端后续请求在HTTP头部（如Authorization:Bearer<token>）携带JWT；（3）服务器接收后验证签名有效性，解析载荷获取用户信息；（4）若JWT过期或签名错误，返回401Unauthorized。三、编程题（每题15分，共30分）1.用Java实现一个LRU（最近最少使用）缓存，要求线程安全，支持设置最大容量，提供put和get方法。答案：```javaimportjava.util.LinkedHashMap;importjava.util.Map;importjava.util.concurrent.locks.ReadWriteLock;importjava.util.concurrent.locks.ReentrantReadWriteLock;publicclassLRUCache<K,V>{privatefinalintmaxCapacity;privatefinalMap<K,V>cache;privatefinalReadWriteLocklock=newReentrantReadWriteLock();publicLRUCache(intmaxCapacity){if(maxCapacity<=0){thrownewIllegalArgumentException("maxCapacitymustbepositive");}this.maxCapacity=maxCapacity;//初始化LinkedHashMap，按访问顺序排序（accessOrder=true）this.cache=newLinkedHashMap<K,V>(16,0.75f,true){@OverrideprotectedbooleanremoveEldestEntry(Map.Entry<K,V>eldest){returnsize()>maxCapacity;}};}publicVget(Kkey){lock.readLock().lock();try{returncache.get(key);}finally{lock.readLock().unlock();}}publicvoidput(Kkey,Vvalue){lock.writeLock().lock();try{cache.put(key,value);}finally{lock.writeLock().unlock();}}}```解析：使用LinkedHashMap的访问顺序特性（accessOrder=true），每次get/put操作会将节点移到链表尾部（最近访问），当容量超过maxCapacity时，通过removeEldestEntry移除最旧节点。通过ReentrantReadWriteLock保证线程安全，读操作共享锁，写操作独占锁。2.设计一个用户登录接口（POST/api/login），要求说明请求参数、验证逻辑、安全措施及响应格式（JSON）。答案：（1）请求参数（JSON）：```json{"username":"test_user","password":"user_password","captcha":"1234"//可选，防暴力破解}```（2）验证逻辑：参数校验：检查username、password非空（使用JSR303注解@NotBlank）；验证码校验（若开启）：验证captcha与Redis中存储的验证码是否一致；密码验证：从数据库查询用户盐值（salt），将明文密码与salt拼接后用BCrypt哈希，与数据库存储的哈希值比对；账户状态检查：是否禁用、锁定（如连续输错5次密码锁定30分钟）。（3）安全措施：密码传输：前端使用HTTPS加密，后端禁止明文存储（必须加盐哈希）；防暴力破解：限制登录失败次数（如5次/分钟），失败次数存入Redis（带过期时间）；会话管理：验证成功后生成JWT（包含用户ID、角色，过期时间设为30分钟），返回给客户端；防重放攻击：JWT使用HS256签名，服务器存储密钥，拒绝非法签名的token；敏感信息脱敏：响应中不返回密码、盐值等信息。（4）响应格式：成功：```json{"code":200,"message":"loginsuccess","data":{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...","expireTime":1714567890//时间戳，单位秒}}```失败（如密码错误）：```json{"code":401,"message":"invalidusernameorpassword","data":null}```四、设计题（15分）设计一个高并发场景下的订单系统，需考虑以下问题：（1）如何避免超卖？（2）如何保证分布式事务一致性？（3）如何处理大促期间的流量洪峰？答案：（1）避免超卖的解决方案：库存预扣减：下单时先扣减库存（而非支付后），使用数据库乐观锁（版本号机制）：UPDATEstockSETcount=count-1,version=version+1WHEREproduct_id=?ANDversion=?；缓存预加载：大促前将热门商品库存加载到Redis（如库存数量存为string类型），下单时先通过Lua脚本原子扣减Redis库存（避免并发问题），扣减成功再同步到数据库；限流防刷：对同一用户、同一商品的下单请求限流（如10次/秒），防止恶意刷单。（2）分布式事务一致性：订单服务与库存服务、支付服务的交互需保证原子性。采用“事务消息”方案（如RocketMQ的事务消息）：①订单服务发送半消息（未提交）到消息队列；②订单服务本地创建订单（状态为“待支付”）；③订单服务提交半消息，库存服务消费消息并扣减库存；④支付成功后，订单服务更新订单状态为“已支付”；⑤若库存扣减失败或支付超时，通过补偿机制回滚订单（状态改为“已取消”）并恢复库存。（3）流量洪峰处理：流量分层：①前端层：静态资源（如商品详情页）走CDN，动态