数据同步基础：同步 vs 异步

做DLP系统，避不开的一个选择题就是：同步还是异步？我记得刚接触这行时，总觉得异步听起来更高级，恨不得所有接口都用异步。结果呢？踩了不少坑。这一节咱们就把这两种模式的本质、优缺点以及适用场景理清楚。

2.1 到底什么是同步？

同步模式，说白了就是「你等我」。客户端发起一个请求，服务端处理完才返回响应。在这个期间，调用方一直拿着连接不放，干等着。

// 同步调用 - 简单粗暴
public DataSyncResult syncPolicyUpdate(Policy policy) {
    // 1. 发送请求
    PolicySyncRequest request = new PolicySyncRequest(policy);
    // 2. 阻塞等待响应（线程在这里停住了）
    PolicySyncResponse response = syncClient.send(request);
    // 3. 拿到结果后继续往下走
    return new DataSyncResult(response.getStatus(), response.getVersion());
}

我在项目中遇到过这样的场景：某银行的策略下发，要求100%实时生效。审计要求任何策略变更必须在1秒内体现在所有边缘节点上。这种情况，异步根本没法用——因为用户需要立刻知道结果，失败了要当场回滚。

2.2 异步模式的核心逻辑

异步就不同了。调用方发完请求就撤，不用傻等。服务端处理完了，通过回调、轮询或者消息队列通知结果。

// 异步调用 - 通过回调通知结果
public void asyncPolicyUpdate(Policy policy, Callback callback) {
    // 1. 把任务丢进队列，立刻返回
    asyncClient.enqueue(new PolicyTask(policy), taskId -> {
        // 2. 后台线程慢慢处理
        PolicySyncResult result = processPolicy(policy);
        // 3. 处理完后回调通知
        callback.onComplete(result);
    });
    // 4. 方法已经返回了，调用方可以干别的事情
}

为什么要这样做？你想想看，DLP系统中策略分发往往涉及几十个、甚至上百个边缘节点。如果每个节点都走同步，一次策略更新可能要等几分钟——这还没算重试和超时。异步的好处就是：接口秒级返回，后端用队列慢慢消化，用户体验好得多。

2.3 异步的三种常见模式

实际项目中，异步不是一种固定的写法，它有很多变形。我个人把它们分成三类：

1. 回调模式：调用方传一个回调函数进去，服务端处理完调用它。优点是简单直接，缺点是容易陷入「回调地狱」——嵌套太深，代码很难维护。
2. Future/Promise模式：调用方拿到一个占位符（Future），后面通过get()主动获取结果。这种模式比回调清晰，但本质还是阻塞的——只是把阻塞点后移了。
3. 消息队列模式：这也是DLP系统中最推荐的模式。请求发到队列，消费者慢慢处理，结果写入结果表或者发送到另一个队列。调用方通过查询或者通知来获取最终结果。

// 消息队列模式 - DLP策略分发的推荐做法
public class PolicyDistributor {
    private final QueueClient queueClient;
    private final ResultStore resultStore;
    
    public String asyncDistribute(String policyId, Policy policy) {
        // 1. 生成唯一追踪ID
        String traceId = UUID.randomUUID().toString();
        // 2. 提交到分发队列
        queueClient.publish("policy.distribute", new DistributeMessage(traceId, policy));
        // 3. 立即返回traceId
        return traceId;
    }
    
    // 外部通过traceId查询结果
    public DistributeResult queryResult(String traceId) {
        return resultStore.get(traceId);
    }
}

2.4 同步真的没用了吗？

肯定不是。同步模式在DLP系统中依然有自己的位置。比如策略的「增量实时同步」——只同步变化的部分，数据量小，要求高一致性，同步就是最佳选择。再比如配置中心的写操作，必须保证写入成功后立刻可读，这时异步的最终一致性反而会成为问题。

我一般这样选：

• 控制面操作（策略变更、规则更新、配置下发）→ 异步为主，但关键链路保留同步兜底
• 数据面操作（日志同步、会话同步、行为记录）→ 异步优先，大数据量场景必须异步
• 管理面操作（系统启停、状态查询、健康检查）→ 同步，这类操作耗时短、频率低，不值得引入异步复杂度

2.5 实践中的选择策略

讲了这么多，到底怎么选？我总结了一个简单的决策树：

• 如果业务要求强一致性（比如策略生效后必须立刻能拦截到这次更新）→ 走同步
• 如果接口响应时间要求高（比如API必须100ms内返回）→ 走异步
• 如果数据量大（比如一次同步几万条策略）→ 走异步
• 如果链路长（需要调用多个外部服务）→ 走异步，或者用异步编排