SOA数据复制与架构优化：SSO服务部署及读库选型咨询

• 你当前基于USER表低写频次设计的读写分离架构已经能满足基础需求，仍有几个可优化的方向：
  • SSO服务无状态改造：既然已经做了负载均衡，不要将登录会话存在单实例本地内存，避免节点故障后用户会话批量丢失。可以选择将会话存在统一存储，或者使用JWT自包含令牌降低服务端会话查询频次。
  • 主从同步一致性兜底：虽然USER表写操作少，但修改密码、更新账号信息这类操作完成后，主从同步存在毫秒级延迟。建议写操作完成后同步淘汰读库旧数据，或者对改密码后立即登录这类敏感请求强制走主库查询，避免出现改密后短时间内新密码无法登录的问题。
  • 增加入口流量防护：SSO是全站核心入口，建议补充限流、熔断规则，避免暴力破解、恶意攻击把服务打垮，影响全站登录能力。
  • 读层水平扩展预留：如果后续USER量级超过千万，单读库仍然会有性能瓶颈，可以提前按用户ID做哈希分片规则设计，后续需要扩容时直接拆分多个读实例即可，不需要改核心逻辑。

• 你的场景刚好匹配Redis的适用范围：USER表写少读多，登录查询都是按账号、手机号、用户ID这类唯一键查单行核心数据，用Redis做读存储性能比关系型读库高10~100倍，完全能扛住SSO的高并发查询压力。
• 具体落地步骤：
  1. 全量数据初始化：先将主库中USER表的全量核心数据（仅保留登录需要的密码哈希、账号状态、权限标记等字段，不要存冗余信息）一次性导入Redis，存储结构用String类型即可，key可以设计为user:login:手机号、user:id:用户ID这类格式，方便不同场景查询。
  2. 增量数据同步：主库USER表触发写操作时，要么在业务写逻辑中同步更新/删除Redis对应的key，要么监听主库binlog异步更新Redis，因为写频次极低，一致性很容易保障。
  3. 穿透防护：针对不存在的用户查询请求（比如暴力破解用的无效账号），可以缓存空值或者增加布隆过滤器过滤非法请求，避免请求穿透到主库。
  4. 降级预案：提前做好Redis故障时自动切回关系型读库的降级逻辑，不会影响登录功能的可用性。

注意绝对不要把用户密码明文存入Redis，仅存储加密后的哈希值即可，避免数据泄露风险。

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