建行金科 面试备考手册

引入权限预计算机制：用户登录或权限变更时生成权限快照，结合 Token 或缓存复用，减少每次请求都进行完整 ABAC 计算的开销。

L1: Gateway 本地缓存（毫秒级）→ L2: Redis 分布式缓存（按 user/role 维度）→ L3: Policy Snapshot Store。大部分请求在缓存层完成判断，减少进入计算层的流量。

权限变更时，通过异步事件通知更新缓存和预计算结果，保证最终一致性，同时避免同步计算带来的性能压力。

DB 读副本 + PDP 节点水平扩展——作为兜底保障，不是核心优化思路。

缓存设置较短 TTL（1–5 分钟），权限变更时立即触发 key invalidation。作用：缩短窗口期，但不能完全解决一致性问题。

缓存中存储 (user_id, permission_result, policy_version)。每次请求时，同时读取最新 policy_version，版本不一致则缓存失效，触发重新计算。这是逻辑上避免使用过期权限的核心机制。

权限变更必须按序：先更新 policy store → 再更新 version（单调递增）→ 再异步清理缓存。确保旧权限永远不会被当作新权限使用。

对关键操作（资金转账、权限变更等），即使缓存命中也进行轻量级二次权限校验，作为最终兜底。

在 AWS Oncall 期间，我们监控到一个数据处理服务出现间歇性失败和延迟升高的问题。

需要定位根因，快速止血，并防止同类问题再次发生。

通过监控指标（latency、error rate、stream backlog）定位到问题集中在数据接入链路，而非核心处理逻辑。分段追踪后发现异常集中在外部数据提供方的流式数据接口——该接口存在网络抖动，传输中断后原有代码无断点续传机制，导致整个处理任务失败。

我设计并实现了基于 Checkpoint 的流式重试机制：数据传输过程中记录消费进度，异常发生时自动重建连接，从最近 Checkpoint 继续消费，避免全量任务失败。编写设计方案 → 团队评审 → 代码实现 → 本地验证 → CI/CD 发布。

发布后监控指标恢复正常，任务失败率显著下降。复盘将问题归纳为"外部依赖不可靠 + 内部缺乏幂等与恢复机制"，推动在类似数据管道中引入统一容错设计规范。

在AWS工作期间，我和另一位同事共同指导一位实习生完成项目，在数据传输协议选型上产生了不同意见。

我倾向于使用 JSON，因为生态成熟、调试方便；另一位同事倾向于二进制协议，因为性能和传输效率更高。

我们没有直接争论哪种技术更先进，而是先明确项目目标。由于这是一个实习项目，目标是帮助实习生理解系统设计并顺利完成开发，因此可读性、可调试性和学习成本比极致性能更重要。

最终团队达成一致，采用 JSON 方案。这次经历让我意识到，技术决策并不是单纯比较技术优劣，而是要结合项目目标、团队情况和实际收益进行权衡。

背景设定，一句话说清楚项目/场景

你的具体任务/职责/挑战

你个人做了什么（区别于团队）—— 定位思路、设计方案、实施过程

可量化的结果 + 复盘/收获（体现反思能力）