跨数据中心复制（XDCR）是 Couchbase 多集群架构的关键能力，可以在不同物理位置之间持续同步数据。单向复制通常比较安全，但双向或环形复制一旦启用，同一条文档就可能被两个站点同时修改，XDCR 必须决定最终以哪个版本为准。这个过程并不是简单的后写入覆盖，而是涉及版本元数据比对与冲突解决规则。

一、XDCR 冲突是如何被检测到的

XDCR 复制单元是文档，但复制过程并不会比较文档正文的每个字符。Couchbase 在每次写入时为文档维护一个 CAS 值，这是一个64位整数，表示最近的变更标识。除了 CAS，文档还包含内部修订号 rev、标志位和过期时间。XDCR 在把文档发往目标集群前，会把源集群的 CAS、修订号、集群标识以及修改时间等写入文档的扩展属性，也就是 XATTR 中的 _xdcr 键。目标集群收到数据后，会拿这些元数据和本地已有版本做比较。

是否存在冲突，取决于源版本和本地版本之间的因果关系。如果本地版本正是源版本之前同步过来的基线，那么新版本就是基线的直接子更新，可以安全覆盖；如果两个版本互相不是父子关系，说明文档在两个数据中心分别被修改过，XDCR 就会进入冲突处理流程。举个例子，集群 A 写入文档得到 CAS=100，集群 B 几乎同时写入得到 CAS=200，两个版本各自认为自己是基于旧的 CAS=50，它们之间没有继承关系，冲突就产生了。

正是这种基于元数据的检测机制，让 XDCR 避免盲目覆盖。如果只比较文档内容，两个不同业务字段的修改也可能导致误判。元数据提供了跨集群的版本顺序信息，为后续策略执行打下基础。

常见的复制元数据字段如下：

二、三种冲突解决策略与自定义解析器

Couchbase XDCR 提供三类冲突解决方式：时间戳、序列号和自定义解析器。时间戳策略就是比较两个版本的修改时间，以较新的时间戳为准，属于最后写入胜利（LWW）模型。它实现简单，适合单活写入或对顺序敏感度不高的场景。但时间戳策略有一个明显缺点：如果两个数据中心的服务器时钟不同步，可能出现旧版本时间戳反而更大，导致新数据被错误覆盖。因此生产环境必须配合 NTP 同步或优先使用其他策略。

序列号策略不依赖时间，而是比较源集群的变更序列号，通常由一个单调递增的整数表示。对于两个版本来自不同集群的情况，XDCR 会结合集群标识和序列号判断胜负。序列号策略在源集群内部顺序严格时非常稳定，但如果多个源并发写入，需要确保序号生成规则合理。

自定义解析器是最灵活的方式，能够读取文档业务字段做出决策。例如订单文档可以比较状态优先级，会员文档可以按最后活跃时间处理。要启用自定义解析器，需要先上传一个 JavaScript 函数。下面是一个基于优先级和时间戳的冲突解析函数示例：

function resolveByPriority(localMeta, remoteMeta) {
    // 其中 localMeta 和 remoteMeta 为冲突双方元数据，包含 content 字段
    if (localMeta.priority > remoteMeta.priority) {
        return localMeta;
    }
    if (localMeta.priority < remoteMeta.priority) {
        return remoteMeta;
    }
    return localMeta.last_updated > remoteMeta.last_updated ? localMeta : remoteMeta;
}

函数需要上传到 Couchbase 集群，并通过复制规则指定。可以使用 REST API 创建复制时把 conflictResolutionType 设为 custom，再通过 conflictResolver 参数指定函数名。下面是一个 curl 配置示例：

curl -X POST -u Administrator:password \
  http://127.0.0.1:8091/controller/createReplication \
  -d fromBucket=orders \
  -d toCluster=remoteClusterName \
  -d toBucket=orders \
  -d replicationType=continuous \
  -d conflictResolutionType=custom \
  -d conflictResolver=resolveByPriority

除了 REST API，也可以使用 Couchbase CLI 或 Web 控制台配置。无论哪种方式，自定义函数都应该在测试环境充分验证，尤其是需要处理字段缺失、类型不符等边界情况。

三、冲突监控与排查建议

在 XDCR 运行期间，可以通过 Web 控制台的 XDCR 标签页查看复制延迟、待复制数量以及冲突计数。如果冲突数持续上升，说明两个集群对同一批文档的并发写入很频繁，也可能意味着当前策略不符合业务预期。日志中也会记录冲突处理的详细信息，便于定位具体文档。

想要手动检查冲突文档时，可以使用 Couchbase SDK 读取文档及 XATTR 中的 _xdcr 信息，或者通过命令行工具查看统计。例如用 cbstats 查看 XDCR 相关指标：

cbstats -u Administrator -p password -b orders localhost:11210 xdcr

如果已经发生大规模错误覆盖，需要暂停相关复制任务，从备份或源集群恢复文档，再分析冲突根因。也可以在应用层避免双活同时写同一文档，例如通过文档 ID 路由到固定数据中心，减少冲突窗口。

最佳实践上，双活且两个中心都可能写同一文档时，建议优先评估自定义解析器；单中心写、另一个中心只读备灾时，时间戳策略足够简单；序列号策略适合内部序号严格、且写入源相对确定的拓扑。同时要监控各节点时间偏移，定期检查 XDCR 复制延迟，任何冲突策略上线前都应该在模拟双活环境执行并发写入测试。