09 设计一个强一致性方案保障故障转移时会话共享

基于Redis的会话共享实现

方案核心：Redis Cluster + 同步写策略

1
2
3
4
5
6
7
8

# Redis节点配置（6节点示例：3主3从）
redis-cluster:
  master1: 192.168.1.1:6379
  slave1:  192.168.1.2:6380
  master2: 192.168.1.3:6379
  slave2:  192.168.1.4:6380
  master3: 192.168.1.5:6379
  slave3:  192.168.1.6:6380

实现步骤
1.数据分片策略
使用CRC16算法对Session Key哈希，分配到16384个槽位。
每个主节点负责约5461个槽（如您简历中的分库分表经验）。

2.强一致性写入

1
2
3
4
5

// Java客户端（Lettuce）强制同步复制
RedisCommands<String, String> commands = client.connect().sync();
commands.set("session:user123", "{...}");
// 使用WAIT命令确保写入同步到N个副本
commands.wait(1, 5000); // 等待至少1个副本确认，超时5秒

代价：写入延迟增加（约+10ms），但保障数据持久化。
3.故障转移处理
Gossip协议：节点间互相探测状态，半数以上节点认为主节点下线则触发故障转移。
从节点提升：优先选择复制偏移量（replication offset）最大的从节点成为新主

CAP权衡与工程化挑战

CAP选择：CP（一致性+分区容忍）
分区场景：当网络分裂导致主节点与集群失联时：
写操作拒绝：失联主节点拒绝新写入，直到集群恢复（通过CLUSTERDOWN错误码）。
读操作降级：客户端缓存旧会话（如5秒），若超时则提示“系统维护中”。

对比哨兵模式的局限性

哨兵模式（AP）：
主从异步复制，故障转移可能导致数据丢失（如主节点未同步最新数据到从节点）。
适用场景：会话可容忍短暂不一致（如用户重新登录）。
Cluster模式（CP）：
同步写+严格故障转移，保障数据强一致。
适用场景：金融/医疗等对会话状态敏感的领域。

3.优化措施
优化1：热点会话分片
问题：明星用户（如李佳琦）的会话访问量极高，导致单个分片压力过大
优化2：本地缓存降级

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 使用Caffeine作为本地缓存
LoadingCache<String, Session> localCache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(5, TimeUnit.SECONDS)
    .build(key -> redisCluster.get(key));

// 读取逻辑
public Session getSession(String userId) {
    try {
        return localCache.get(userId);
    } catch (RedisClusterDownException e) {
        return localCache.getIfPresent(userId); // 降级返回5秒内旧数据
    }
}

集群故障时仍可提供5秒内的会话数据，避免大面积用户登出
优化3：增量同步检查

1
2
3
4

# 定时检查主从数据一致性
redis-cli --cluster check 192.168.1.1:6379 \
    --cluster fix \
    --cluster-milliseconds 5000

总结:通过Redis Cluster强一致写入+热点分片+本地缓存降级，结合简历中高并发处理和消息幂等性设计经验，实现分布式会话的高可用与强一致性