从零构建高可用skill复制层：架构设计与实现详解

2次阅读

没有评论

共计 1678 个字符，预计需要花费 5 分钟才能阅读完成。

在分布式系统中，skill 复制层负责将数据变更同步到多个节点，确保系统的高可用性和容错能力。但在实际应用中，我们常常面临以下挑战：

网络分区：当节点间网络出现故障时，可能导致数据不一致
并发冲突：多个节点同时修改同一数据时如何处理冲突
性能瓶颈：同步复制可能带来显著的延迟
故障恢复：节点宕机后如何快速恢复数据一致性

Write-Ahead Logging(WAL)是传统数据库常用的复制技术：

优点：
实现相对简单
保证强一致性
适合金融等对一致性要求高的场景
缺点：
网络分区时可能阻塞写入
需要解决日志压缩问题

Conflict-free Replicated Data Types(CRDT)采用最终一致性模型：

优点：
天然支持分区容忍
自动解决冲突
适合协同编辑等场景
缺点：
数据结构受限
可能出现暂时不一致

type Operation struct {
    Key       string
    Value     interface{}
    Timestamp int64 // 使用逻辑时钟
    ClientID  string // 客户端标识
}

type ReplicationLayer struct {log       []Operation // WAL 日志
    state     map[string]interface{} // 当前状态
    peers     []string // 其他节点地址
    mutex     sync.RWMutex // 读写锁
}

客户端发起写请求
将操作追加到本地 WAL 日志
异步复制到其他节点
收到多数节点确认后提交

func (r *ReplicationLayer) Propose(op Operation) error {r.mutex.Lock()
    defer r.mutex.Unlock()

    // 1. 本地记录
    r.log = append(r.log, op)

    // 2. 并行复制
    var wg sync.WaitGroup
    success := 1 // 本地已成功

    for _, peer := range r.peers {wg.Add(1)
        go func(p string) {defer wg.Done()
            if err := r.sendToPeer(p, op); err == nil {atomic.AddInt32(&success, 1)
            }
        }(peer)
    }

    wg.Wait()

    // 3. 检查是否达到多数派
    if success > len(r.peers)/2+1 {r.apply(op) // 应用到状态机
        return nil
    }
    return errors.New("无法达成共识")
}

我们采用 LWW(Last-Writer-Wins)策略处理冲突：

func (r *ReplicationLayer) resolveConflict(existing, new *Operation) *Operation {
    if new.Timestamp > existing.Timestamp {return new} else if new.Timestamp == existing.Timestamp {
        // 时间戳相同，按客户端 ID 排序
        if new.ClientID > existing.ClientID {return new}
    }
    return existing
}

我们在 3 节点集群上进行了测试(配置：4 核 CPU/8GB 内存)：