3、数据采集层优化：埋点设计原则、SDK异步化、批量发送与背压机制

数据采集层，说白了就是整个实时指标系统的「入口」。入口要是堵了，后面再好的计算引擎、再快的存储，全白搭。我见过太多团队把精力花在 Flink 调优上，结果发现瓶颈在客户端埋点——SDK 同步阻塞，网络抖动一下，业务线程全挂。

这一章，咱们就聚焦三个核心问题：埋点怎么设计才不坑、SDK 怎么做到非阻塞、发送失败时怎么优雅地「踩刹车」。

3.1 埋点设计原则：少、准、稳

埋点不是越多越好。我接手过一个项目，客户端每秒钟上报 200+ 个事件，其中一半是「页面进入」「页面离开」这种冗余数据。结果呢？网关先扛不住，Kafka 分区积压，实时指标延迟从 3 秒飙到 2 分钟。

所以，埋点设计我习惯遵循三个原则：

• 少：只采集真正用于聚合计算的字段。能客户端算的，别丢到服务端算。
• 准：时间戳必须在客户端生成，用设备本地时钟，别依赖服务端时间。
• 稳：埋点代码不能影响主业务流程。哪怕 SDK 挂了，业务也不能崩。

举个例子，一个电商下单事件，我通常只保留：

字段	说明	是否必须
event_id	全局唯一 ID，用于去重	是
user_id	用户标识	是
event_type	事件类型，如 "order.create"	是
timestamp	客户端时间戳（毫秒）	是
body	业务数据 JSON，如 { "amount": 99.9 }	是
extra	扩展字段，用于 A/B 测试等	否

嗯，这里要注意：body 里的字段也要收敛。我见过有人把整个订单对象序列化后塞进去，一个事件 50KB，这谁受得了？

3.2 SDK 异步化：别让埋点拖慢业务

埋点 SDK 最忌讳什么？同步阻塞。你想想看，用户下单，结果因为埋点 SDK 在等待网络响应，下单接口多等了 200 毫秒。这体验，用户不骂娘才怪。

我个人的做法是：SDK 内部必须全异步。业务线程调用埋点 API 后，数据立刻写入一个无锁队列（比如 Disruptor 或 JCTools），然后立即返回。后台由一个独立的「发送线程」批量消费队列中的数据。

核心代码骨架大概长这样：

// 伪代码：SDK 异步化核心
public class Tracker {
    private final RingBuffer<Event> buffer;  // 无锁环形缓冲区
    private final BatchSender sender;         // 批量发送器

    public void track(Event event) {
        // 业务线程：写入队列，O(1) 时间，绝不阻塞
        buffer.publish(event);
    }

    // 后台线程：批量消费并发送
    class BatchSender implements Runnable {
        public void run() {
            while (true) {
                List<Event> batch = buffer.drain(MAX_BATCH_SIZE);
                if (!batch.isEmpty()) {
                    httpClient.post(batch);  // 批量发送
                }
            }
        }
    }
}

为什么用 RingBuffer 而不是 BlockingQueue？因为 RingBuffer 是固定容量、无锁的，写入延迟通常在纳秒级。BlockingQueue 在竞争激烈时会有锁争用，延迟可能飙升到微秒级。对于高频埋点场景，这个差距很致命。

3.3 批量发送：攒够了再发

单个事件一条 HTTP 请求？那是灾难。网络开销远大于序列化开销。我做过压测：单条发送，1000 个事件需要 1000 次 TCP 握手，延迟累计 10 秒以上；批量发送，1000 个事件打包成一次请求，延迟不到 100 毫秒。

批量发送有两个关键参数：

• 批量大小：攒够多少条再发。我一般设 500 或 1000 条。
• 最大等待时间：如果一直攒不够，最多等多久。我习惯设 500 毫秒。

两个条件满足任意一个，就触发发送。这叫「时间和数量双触发」。

// 伪代码：批量发送逻辑
public class BatchSender {
    private final List<Event> batch = new ArrayList<>();
    private long lastSendTime = System.currentTimeMillis();

    public void append(Event event) {
        batch.add(event);
        if (batch.size() >= 500 || 
            System.currentTimeMillis() - lastSendTime > 500) {
            flush();
        }
    }

    public void flush() {
        if (batch.isEmpty()) return;
        httpClient.post(batch);  // 一次 POST 发送整个批次
        batch.clear();
        lastSendTime = System.currentTimeMillis();
    }
}

3.4 背压机制：踩刹车是一门艺术

数据采集层最怕什么？下游（Kafka、服务端）扛不住了，但客户端还在拼命发。结果就是：客户端 OOM、网络连接池爆满、下游被冲垮。这就是典型的「背压缺失」。

背压，说白了就是「告诉上游慢点发」。我习惯在 SDK 里实现三级背压策略：

1. 本地队列水位监控：队列使用率超过 70% 时，降低发送频率（比如从 10ms 一次降到 50ms 一次）。
2. 发送失败降级：连续 3 次发送失败，直接丢弃新数据，不再写入队列。同时记录丢弃计数，用于监控告警。
3. 动态限流：根据服务端返回的 HTTP 429（Too Many Requests）或 503，自动降低批量大小或增加发送间隔。

我画了一张图，把整个数据采集层的流程串起来：

你看，整个流程的核心就是：业务线程快进快出，发送线程异步批量，背压信号闭环反馈。这三者缺一不可。

3.5 避坑指南：我踩过的三个坑

最后，分享几个我亲身经历过的坑，希望能帮你少走弯路。

• 坑一：时间戳用服务端时间。我曾经有个项目，所有埋点时间戳都在服务端生成。结果客户端网络延迟 5 秒，事件时间全乱套。后来改成客户端生成时间戳，并在发送时带上客户端发送时间，服务端用这两个时间估算网络延迟，做时间校准。
• 坑二：批量发送不设超时。有一次下游 Kafka 挂了，SDK 还在不断重试，结果客户端内存被打满。后来我加了「最大等待时间」和「最大重试次数」，超过阈值直接丢弃。
• 坑三：背压只做本地限流。本地限流只能保护客户端自己，保护不了下游。我后来加了「服务端主动背压」——服务端在负载高时返回 429，客户端收到后自动降低发送速率。这才是真正的闭环。