PHP微服务中JWT黑名单无瓶颈无单点故障同步方案咨询

问题背景 #

我正在开发一个基于微服务架构的项目，每个服务都是独立的PHP应用，均依赖JWT进行身份认证与授权。当前核心痛点是：令牌撤销（加入黑名单）后，无法让所有服务立即识别该令牌无效。

现有尝试方案的局限性：

• 本地独立黑名单：仅发起撤销的服务知晓令牌失效，其他服务存在感知延迟
• 共享缓存/中央数据库（如Redis）：存在单点故障风险，易成为性能瓶颈
• 消息队列（RabbitMQ/Kafka）发布撤销事件：引入额外运维开销，离线服务无法及时同步
• 短期令牌自动过期：无法满足即时安全撤销的业务需求

当前使用firebase/php-jwt的简化验证代码：

use Firebase\JWT\JWT;
use Firebase\JWT\Key;

function isBlacklisted(string $jti): bool
{
    // 本地数据库查询黑名单jti的逻辑占位
    return false; 
}

$jwt = $_SERVER['HTTP_AUTHORIZATION'] ?? '';
$secretKey = 'MY_SECRET_KEY';

try {
    // 解码并验证签名
    $decoded = JWT::decode($jwt, new Key($secretKey, 'HS256'));

    // 检查jti是否在黑名单中
    $jti = $decoded->jti ?? null;
    if ($jti && isBlacklisted($jti)) {
        throw new Exception('Token has been revoked');
    }

    echo "Token is valid!";
} catch (Exception $e) {
    echo "Invalid or revoked token!";
}

需求：不依赖集中式数据存储或服务，实现所有服务间撤销令牌的即时同步，求可行解决方案或创新思路。

可行解决方案 #

1. Gossip协议驱动的黑名单分布式同步 #

采用去中心化的Gossip（流言）协议实现黑名单增量同步：

• 每个服务维护本地黑名单，同时定期向随机选取的其他服务节点推送自身的黑名单增量（新撤销的jti）
• 接收增量的节点将新jti加入本地黑名单，并继续转发给其他节点，实现病毒式扩散
• 配置同步频率（如1秒/次）和转发次数，平衡即时性与网络开销
• 离线节点恢复时，主动向多个节点拉取全量黑名单快照，再同步后续增量，确保数据一致性

2. 基于撤销批次的无状态令牌验证 #

修改JWT payload结构，引入用户撤销批次标识：

• 签发令牌时，为每个用户分配初始值为0的revocation_batch字段并写入JWT payload
• 当需要撤销用户所有令牌时，将该用户的revocation_batch值递增（存储在各服务本地的用户数据库中）
• 服务验证令牌时，对比令牌中的revocation_batch与本地数据库中该用户的当前值：若令牌值小于当前值，则判定令牌已被撤销
• 优势：无需维护jti黑名单，仅需同步极小数据量的用户批次值；局限性：仅支持批量撤销用户所有令牌，无法单独撤销单个令牌

3. 分布式哈希表（DHT）存储黑名单状态 #

基于Chord等DHT协议构建去中心化的黑名单存储网络：

• 每个服务节点作为DHT的一个节点，负责存储一部分jti的撤销状态，并维护副本节点
• 验证令牌时，通过jti的哈希值定位到负责存储该jti的节点，查询撤销状态；若目标节点离线，自动切换到副本节点查询
• 撤销令牌时，将jti写入对应的DHT节点，系统自动同步到副本节点，避免单点故障

4. 本地缓存+反向查询兜底机制 #

结合本地黑名单缓存与定向反向查询：

• 服务优先查询本地黑名单，若未找到匹配的jti，则通过令牌中的签发服务标识，向签发该令牌的服务发起反向查询
• 签发服务维护自身签发的所有令牌的撤销状态，收到查询后返回结果
• 查询结果在本地缓存一段时间，减少重复查询的网络开销；适合撤销频率较低的业务场景

内容的提问来源于stack exchange，提问作者Kamyar Safari