密码管理体系概述：为什么需要高可用

说到密码的高可用，很多人第一反应是：「不就加个重试嘛，断了再连不就行了？」

其实没那么简单。我刚开始做密码中间件的时候，也是这么想的。结果上线当天晚上就被告警电话叫醒——重试风暴把所有下游打挂了。嗯，那时候我才真正意识到，密码服务的高可用，根本不是「加个循环」就能搞定的事。

密码服务，远比你想的脆弱

密码操作在整个系统里，算得上是最特殊的环节。你想想看，一次普通的数据库查询，失败了你可以等会儿再查。但密码验证呢？

• 一次失败 = 用户被拒之门外。用户可不管你是网络抖了还是服务挂了，登不进去就是你的锅。
• 密码验证服务通常是热点。登录、支付、修改敏感信息，处处都要校验密码。高峰期一秒几万次请求都是常态。
• 下游服务不一定扛得住。我见过太多把密码服务挂在老旧的 LDAP 或者单点 Redis 上的案例，平时还行，一有波动就直接雪崩。

说白了，密码服务的高可用，不是为了炫技，而是为了不让用户在最关键的时刻对你失去信任。

核心原因：密码服务的不可逆性

为什么我们要单独强调密码的高可用？因为很多操作是可以补偿的。

操作类型	失败后能怎么做	影响范围
数据查询	页面降级显示缓存数据	体验变差，但还能用
消息推送	放入死信队列，后续重推	延迟，但不影响核心
密码验证	无法降级，验证失败必须报错	用户完全无法操作
密码修改	不能重试，可能造成新旧密码不一致	用户账号状态混乱

看到没？密码操作一旦失败，没有「将就用」的选项。我之前在项目中就吃过这个亏——为了追求响应速度，把密码验证的 timeout 设得很短，结果一次网络抖动导致大批用户登录失败，客服电话直接被打爆。

从单点到集群：高可用的意义

搭建密码服务，最怕的就是单点故障。

举个例子，你的密码服务只有一台机器在跑。那台机器硬盘坏了、网络断了、甚至只是内存满了，整个系统的登录功能就瘫痪了。用户连密码都改不了，这叫什么？这叫业务中断。

所以我们需要做两件事：

1. 服务本身要冗余。多节点、多机房、甚至多云部署。一台挂了，另一台立刻接上。
2. 重试机制要智能。不能傻乎乎地对着同一个挂掉的节点重试，要能自动切换到健康的节点。

我个人的习惯是，在密码服务的前面统一加一层「重试网关」。这个网关不负责实际的密码校验，只负责把请求分发到不同的后端节点，并在失败时按照策略进行重试。这样做的好处是，后端的密码服务可以专注做校验，不需要染指重试逻辑。

重试机制：最后一道防线

有人可能会问：「我都做了多节点了，为什么还要重试？」

原因很简单——多节点解决的是机器级别的高可用，但网络抖动、瞬时高负载、GC 暂停这些细粒度的故障，节点冗余也未必能完全覆盖。你想想看，如果两个节点都在同一台机柜里，一个交换机断电，两个节点一起挂，这时候重试机制就是救命稻草。

重试机制的本质，是给系统一次「重新来过」的机会。但要注意，重试不是无脑重复。我见过最坑的写法：

// 千万别这么写！
while (true) {
    try {
        result = passwordService.verify(request);
        break;
    } catch (Exception e) {
        // 继续重试
    }
}

这种代码放到线上，等于给自己埋了一颗定时炸弹。一旦密码服务不可用，这个循环会立刻打满 CPU，并且把异常日志撑爆磁盘，造成二次故障。

真正的重试机制需要：

• 有限次数：比如最多重试 3 次，超过次数直接降级或者报错。
• 间隔策略：固定间隔、递增间隔、还是指数退避？要根据场景选。
• 熔断保护：如果连续失败达到阈值，直接切断重试，避免雪崩。

高可用不是万能的

最后说一句大实话：高可用不便宜。

你部署三个节点，做负载均衡、熔断降级、重试编排，这些都需要成本。很多时候，产品经理会问：「我们的密码服务能 99.999% 可用吗？」我会反问他：「你的业务量需要吗？」

• 如果是银行、支付、政务这种系统，确实需要上多机房 + 智能重试。
• 如果是内部 OA、考勤打卡这种系统，单节点 + 简单重试可能就够用了。

我现在的原则是：先保证核心链路的高可用，再逐步扩展到次要业务。不要一开始就想着建个庞大的高可用体系，结果维护成本比服务本身还高。