在Node.js Express微服务应用中创建并维护Redis会话存储副本

你的异步同步方案完全可行，这个专属的鉴权侧Redis存储确实更接近缓存性质：它仅用于承载高频鉴权读请求，数据完全来自认证服务的主Redis，不需要独立持久化，就算数据丢失也可以从主库重新同步恢复。

如果采用这个方案，需要注意几个核心问题：

• 同步逻辑可以直接用Redis原生的发布订阅（Pub/Sub）实现：认证服务每次新增、更新、删除会话时，向指定通道推送变更事件，鉴权侧Redis订阅该通道后自动同步对应数据，不需要自己开发复杂的跨服务通信逻辑
• 要加兜底校验逻辑：如果鉴权侧Redis未查询到目标会话，不要直接返回401，先主动请求认证服务的主Redis拉取会话，拉取成功后写入鉴权Redis再完成鉴权，避免同步延迟导致的合法请求被误拦截
• 同步会话时要携带过期时间配置，保证两侧Redis的会话过期时间完全一致，避免鉴权侧存储已过期的无效会话

以下方案落地成本和稳定性都优于自定义异步同步，可根据业务场景选择：

方案1：Redis原生主从复制（最适配你的需求） #

直接将鉴权服务使用的Redis实例配置为认证服务主Redis的只读从节点，所有同步逻辑由Redis原生实现，不需要修改业务代码：

• 主节点仅处理认证服务的低频率读写请求，鉴权侧的所有高频读请求全部打在从节点，完全隔离读压力对认证服务的影响
• 会话的更新、删除、过期都会自动同步到从节点，不会出现自定义同步逻辑可能导致的数据不一致问题
• 配置成本极低，仅需要在鉴权Redis的配置文件中添加一行 replicaof 主RedisIP 主Redis端口 即可生效

方案2：鉴权逻辑下沉到API网关（架构最简单） #

如果你的业务QPS没有达到十万级以上，完全不需要单独拆分鉴权服务和副本存储：

• 将会话鉴权逻辑直接部署在API网关层，网关直接连接主Redis处理读请求，认证服务仍通过主Redis处理会话的写入更新
• Redis单节点默认可承载10w+/秒的读请求，足够支撑绝大多数业务场景的鉴权需求，不会对低频率的认证写请求产生影响
• 该方案没有额外的同步逻辑和维护成本，不存在数据一致性问题

方案3：改用JWT替代会话存储（完全消除Redis读请求） #

如果你的会话中存储的用户凭证数据量较小，可直接用JWT承载用户授权信息：

• 鉴权时仅需要本地校验JWT签名的合法性，不需要请求Redis查询会话，完全消除鉴权的Redis读请求
• 可通过短有效期JWT+刷新令牌的方式解决JWT无法主动作废的问题，适合会话有效期较短的业务场景

你现有业务中的ensureAuthorisation中间件不需要做核心逻辑修改，仅需要调整会话读取的数据源顺序即可，上层业务路由完全不需要改动。

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