# 面试题
118 篇文章与「面试题」相关的全部文章。
秒杀系统如何设计？
一、挑战 高并发、库存有限、防超卖、防刷。 二、优化手段 1. 前端 按钮置灰，防止重复提交。 答题/验证码防机器人。 2. 网关层 限流（用户维度、IP 维度）。 静态资源 CDN。 3. 应用层 Redis 预减库存，判断是否还有库存。 异步下单：请求写 MQ，消费者处理订单。 本地缓存挡热点商
服务降级和熔断的区别？
一、降级（Degrade） 主动关闭非核心功能，保证核心功能可用。 如大促时关闭评论、推荐，保交易。 是一种策略，通常按预设规则触发。 二、熔断（Circuit Breaker） 下游服务故障时，上游不再调用，直接返回降级结果。 类似电路保险丝，防止故障蔓延。 基于错误率、响应时间等指标自动触发。
常见的限流算法？
一、固定窗口 把时间分成固定窗口，窗口内计数，超过阈值限流。 - 优点：简单。 - 缺点：窗口边界可能突刺（如窗口末尾和下一个窗口开头各来一半，合起来超限）。 二、滑动窗口 把窗口分成多个小格子，随时间滑动，统计格子总数。 - 解决固定窗口的边界问题。 - 实现稍复杂。 三、漏桶算法 请求进桶，桶以
高并发下的缓存策略？
一、缓存层级 L1：浏览器缓存。 L2：CDN 缓存。 L3：Nginx/网关缓存。 L4：应用本地缓存（Caffeine、Guava）。 L5：分布式缓存（Redis）。 L6：数据库。 二、缓存更新策略 Cache Aside：应用先查缓存，没有查数据库，写入缓存。删除缓存（不是更新）。最常用。
高并发系统的优化手段有哪些？
一、前端优化 CDN 加速静态资源。 浏览器缓存、资源合并压缩。 页面懒加载、预加载。 二、网关层 Nginx 负载均衡，动静分离。 限流（令牌桶、漏桶）。 缓存静态页面。 三、应用层 多级缓存：本地缓存（Caffeine）+ 分布式缓存（Redis）。 异步化：消息队列削峰填谷。 线程池调优，合理
ShardingSphere 的核心功能？
一、定位 ShardingSphere 是分布式数据库中间件，提供分库分表、读写分离、数据加密等能力。 二、三种模式 ShardingSphere-JDBC：嵌入应用，JAR 包方式，性能好但只支持 Java。 ShardingSphere-Proxy：独立部署代理，支持多语言，有网络开销。 Sha
分库分表扩容如何平滑迁移？
一、取模扩容问题 user_id % 4 改为 % 8，大部分数据需要迁移。 二、方案一：停机迁移 停机，写脚本把数据按新规则重新分配。 简单但有停机时间。 三、方案二：双写 + 迁移 新数据同时写旧分片和新分片。 后台把旧数据迁移到新分片。 校验一致后，切读到新分片。 停写旧分片。 - 不停机但复
分布式 ID 生成方案有哪些？
一、UUID 优点：本地生成，无网络开销，唯一。 缺点：无序，索引效率低；太长。 二、数据库自增 优点：简单，有序。 缺点：单库瓶颈；分库后不全局唯一。 三、号段模式 从数据库批量获取 ID 段（如 1-1000），在内存中使用。 优点：性能高，减少数据库压力。 缺点：服务重启可能断号。 四、Sno
如何选择分片键？
一、选择原则 查询频率高：最常用的查询条件字段，如 user_id、order_id。 分布均匀：避免数据倾斜，如不要用性别（只有两个值）。 业务关联：关联表用相同分片键，减少跨库 join。 不可变：分片键值一旦确定不能改。 二、常见分片键 用户 ID：用户相关数据，如订单按 user_id 分片
分库分表有哪些策略？
一、垂直拆分 垂直分库：按业务拆分库，如用户库、订单库、商品库。 垂直分表：按字段拆分表，如主表存常用字段，扩展表存大字段。 解决：单库压力、单表字段过多。 二、水平拆分 水平分库：同一张表数据按规则分到多个库。 水平分表：同一张表数据按规则分到多张表。 解决：单表数据量过大。 三、分片规则 范围：
Netty 如何实现心跳检测？
一、IdleStateHandler Netty 提供 IdleStateHandler 检测空闲状态。 ch.pipeline().addLast(new IdleStateHandler(5, 0, 0, TimeUnit.SECONDS)); 三个参数：读空闲时间、写空闲时间、所有空闲时间。
Netty 如何解决粘包拆包？
一、问题 TCP 是字节流，没有消息边界，多个请求可能粘在一起（粘包），一个请求可能被拆分（拆包）。 二、解决方案 固定长度：FixedLengthFrameDecoder，每条消息固定长度。 特殊分隔符：DelimiterBasedFrameDecoder，按换行符等分隔。 长度字段：Length
Netty 的 ByteBuf 设计？
一、与 ByteBuffer 对比 JDK ByteBuffer 只有一个 position，读写切换需 flip()，易出错。 ByteBuf 有 readerIndex 和 writerIndex 两个指针，读写分离，无需 flip。 二、核心方法 readXxx() / writeXxx()：
Netty 的 ChannelPipeline 机制？
一、定义 每个 Channel 有一个 Pipeline，由多个 ChannelHandler 组成，形成责任链。入站和出站事件在 Pipeline 中传播。 二、入站和出站 InboundHandler：处理入站事件（读、连接建立等），从 head 向 tail 传播。 OutboundHandl
Netty 的 Reactor 线程模型？
一、Reactor 模式 基于事件驱动，I/O 多路复用监听多个连接，事件就绪后分发给处理器。 二、Netty 三种模型 单线程 Reactor：一个线程处理所有连接的 accept 和 I/O，简单但不适合高并发。 多线程 Reactor：一个 Acceptor 线程接收连接，I/O 由线程池处理
Dubbo 和 OpenFeign 的区别？
一、对比 维度 Dubbo OpenFeign 协议 多协议（dubbo 默认） HTTP 性能 高（二进制协议） 较低（HTTP+JSON） 服务治理 完善（路由、熔断、限流） 需配合 Sentinel 注册中心 必需 必需 语言 Java 为主 跨语言（HTTP） 适用 内部服务调用 内外通用
Dubbo 的 RPC 调用过程？
一、代理层 Consumer 调用接口方法，实际调用的是代理对象（JDK 动态代理或 Javassist）。 二、路由层 Cluster：集群容错，处理调用失败。 Directory：管理 Provider 列表。 Router：根据路由规则过滤 Provider。 LoadBalance：从 Pr
Dubbo 的 SPI 机制？
一、SPI 定义 Service Provider Interface，服务提供接口。Java 有自带 SPI，Dubbo 对其增强。 二、Dubbo SPI 优势 按需加载，不一次性加载所有实现。 支持自适应扩展（@Adaptive），运行时动态选择实现。 支持自动包装（Wrapper），AOP
Dubbo 的负载均衡策略？
一、四种策略 Random（默认）：随机，按权重加权随机。 RoundRobin：轮询，按权重轮询，慢的 Provider 会累积请求。 LeastActive：最少活跃调用，慢的 Provider 收到更少请求。 ConsistentHash：一致性哈希，相同参数请求到同一 Provider。 二
Dubbo 的整体架构？
一、核心角色 Provider：服务提供者，暴露服务。 Consumer：服务消费者，调用远程服务。 Registry：注册中心，服务注册与发现。 Monitor：监控中心，统计调用次数和耗时。 Container：服务运行容器。 二、调用流程 Provider 启动时向 Registry 注册服务