25年11月合创经纬（深圳） Java开发实习二面

#JAVA##JAVA面经##JAVA内推#

核心思路：镜像队列本质是「主队列+从队列数据同步」，通过副本冗余+故障自动切换保证消息不丢失、服务不中断。

标准答案：

RabbitMQ 镜像队列将队列复制到集群中多个节点（主节点+从节点）：

数据同步：生产者发送消息到主队列后，RabbitMQ 会同步复制到所有从队列（默认同步复制，需主从都写入成功才返回）；
故障切换：主节点宕机时，集群自动选举一个从节点升级为主节点，消费者可无缝切换到新主节点消费；
高可用保障：队列元数据（如绑定关系）也同步到从节点，避免主节点故障导致队列不可用。核心是「数据多副本+自动故障转移」，保证消息不丢失、队列服务持续可用。

核心思路：非对称加密靠「私钥签名+公钥验签」，签名包含数据哈希值，篡改后验签失败。

标准答案：

JWT 非对称加密防篡改的核心逻辑：

签名生成：
- 服务端将 JWT 载荷（Payload）按固定规则序列化，计算哈希值（如 SHA256）；
- 用私钥对该哈希值加密，生成签名（Signature），拼接在 JWT 尾部（Header.Payload.Signature）；
验签防篡改：
- 客户端请求时携带 JWT，服务端先用公钥解密签名，得到原始哈希值；
- 重新计算 JWT 载荷的哈希值，与解密后的哈希值对比；
- 若不一致，说明载荷被篡改，直接拒绝请求；若一致，确认数据未被篡改。核心是「私钥仅服务端持有，篡改后哈希值不匹配，验签失败」。

核心思路：细粒度权限刷新需「拆分权限载体+动态校验」，避免刷新整个 JWT，仅更新权限相关内容。

标准答案：

权限与 JWT 解耦：
- JWT 仅存储用户唯一标识（如 user_id），不存储具体权限；
- 权限数据存储在 Redis/MySQL 中，按「用户-角色-权限」粒度维护；
细粒度刷新：
- 权限变更时，直接更新 Redis/MySQL 中的权限数据，无需修改 JWT；
- 接口鉴权时，先校验 JWT 有效性，再从 Redis 拉取当前用户的最新权限，实现权限动态刷新；
兜底优化：
- 给 Redis 权限数据设置与 JWT 相同的过期时间，避免权限残留；
- 敏感权限变更时，可将旧 JWT 加入黑名单，强制用户重新登录获取新 token。核心是「JWT 仅做身份认证，权限动态拉取」，实现细粒度刷新。

核心思路：深度分页（如 limit 100000, 10）慢的本质是「扫描大量无用数据」，优化核心是「减少扫描行数+利用索引定位」。

标准答案：

MySQL 深度分页优化的核心方案：

索引覆盖+主键跳转（最优）：
- 先通过索引找到分页起始位置的主键值：select id from table where ... order by id limit 100000, 1；
- 再通过主键精准查询：select * from table where id >= 起始id order by id limit 10；
禁止 offset 过大：
- 避免直接使用 limit 大offset, 10，改用「上一页最后一条数据的主键」作为条件（游标分页）；
业务优化：
- 限制最大分页页数（如最多支持 1000 页）；
- 热点分页数据缓存到 Redis。核心是「用索引定位起始位置，避免全表扫描大量无用数据」。

核心思路：PageHelper 基于单表 SQL 改写，分表后 SQL 逻辑改变，分页计算规则不适用。

标准答案：

PageHelper 失效的核心原因：

底层原理：PageHelper 通过 MyBatis 拦截器改写 SQL，在 SQL 尾部拼接 limit offset, size，依赖「单表全量数据的行数」计算分页；
分表场景问题：
- 分表后数据分散在多个表中，PageHelper 只能改写 SQL 针对单个表分页，无法汇总所有分表的数据计算总页数/偏移量；
- 例如 limit 100, 10，PageHelper 仅在某一分表中取 100-110 行，而非所有分表的汇总结果；
补充：分表分页需用「分库分表中间件（如 Sharding-JDBC）」，由中间件汇总所有分表数据后再分页。

核心思路：分布式定时任务幂等的核心是「唯一标识+状态校验+防重执行」，避免多节点重复执行同一任务。

标准答案：

任务唯一标识：
- 为每个定时任务生成唯一任务 ID（如 任务名_执行时间_参数哈希）；
执行前防重校验：
- 任务执行前，通过 Redis SETNX 加锁（SET 任务ID 1 NX EX 任务超时时间），加锁成功才执行；
- 或在数据库中记录任务执行状态（待执行/执行中/已完成），执行前校验状态为「待执行」才执行，