1. 对比背景

GroupDataProcessor (GDP) 是项目中已有的通用异步"边攒边发"框架，基于 GroupDataContainer + DistributeLocker + 共享线程池实现。

V2 PushEventHandler 是专为 WebSocket 推送引擎设计的新方案，基于 Disruptor + 共享锁数组 + 专属 Sender 线程池实现。

两者都实现了"边合并边发送"的核心模式。本文从架构、线程模型、锁机制、数据流、重试、性能六个维度进行深度对比。

2. 架构原理对比

2.1 GroupDataProcessor 架构

2.2 V2 PushEventHandler 架构

2.3 核心架构差异

3. 线程模型对比

3.1 GDP 线程模型

调用方线程 (业务线程, 可能很多)
     │
     ▼
 addData() → DistributeLocker.lockRun(key) → merge + 回调
     │                                          │
     │                              taskFutureMap 无 RunningTask?
     │                                          │ 是
     │                                  scheduleRun(key, delay)
     │                                          │
     ▼                                          ▼
   返回                            共享 ExecutorService
                                         │
                                  scheduleProcess(key)
                                  ├── lockRun: copyForUse
                                  ├── processor.run   ← 无锁
                                  └── lockRun: clearData + 再调度

3.2 V2 线程模型

业务线程 (多个)
     │
     ▼
 publish() → Disruptor Ring Buffer
                    │
                    ▼
          Disruptor 消费线程 (单个, 固定)
          │ synchronized(lock): merge + 调度判断
          │
          ▼
     Sender-0 / Sender-1 / Sender-2 / Sender-3
     (每个 coreSize=1, hash(key)%4 选择)
     ├── synchronized(lock): copyForUse
     ├── wsPushProcess            ← 无锁
     └── synchronized(lock): mergeRemove

线程模型对比表

4. 锁与同步机制对比

4.1 锁实现对比

4.2 单事件周期锁操作量化

一个完整的事件周期 = 数据入队(merge) + 拷贝(copy) + 发送(send) + 清理(remove)。

4.3 竞争场景对比

场景 A: 多业务线程并发 addData 同一 key

场景 B: merge 和 send 并发争同一 key

5. 数据流全路径对比

5.1 数据入队 (add / merge)

GDP: addData

addData(List<T> dataList)
  → 按 key 分组: Map<Object, List<T>>
  → 对每个 key:
      locker.lockRun(key, () -> {
          for (T data : datas) {
              innerAdd(key, data);    // merge 到 dataMap
          }
          lockRunner.run(finalData); // 回调: 检查 taskFutureMap, 首次则 scheduleRun
      });

V2: onEvent

onEvent(PushEvent event, ...)
  → incoming = event.getPushModelTaskGroup()
  → synchronized(getLock(batchKey)) {
        merge incoming 到 batchMap;
        if (!activeSenders.contains(key)) {
            activeSenders.add(key);
            shouldSchedule = true;
        }
    }
  → if (shouldSchedule) senderExecutors[slot].execute(senderLoop);

5.2 发送循环 (scheduleProcess / senderLoop)

GDP: scheduleProcess

scheduleProcess(dataKey, identityObj)
  → copyPushData = dataContainer.copyForUse(dataKey);  // 锁内 copy
  → processor.run(copyPushData);                        // 无锁 send
  → clearPushData = copyPushData;                       // 成功标记
  → dataContainer.clearData(dataKey, clearPushData, lockRunner);
      // 锁内: mergeRemove + 判断是否还有数据
      // lockRunner: 还有数据 → scheduleRun(dataKey, delayTime)
      //             无数据 → taskFutureMap.remove(dataKey)

V2: senderLoop

senderLoop(batchKey, retryCount)
  → while (true):
      synchronized(lock) { copy = agg.copyForUse() }   // 锁内 copy
      if empty → synchronized(lock) { cleanupKey } → return
      wsPushProcess(copy);                               // 无锁 send
      synchronized(lock) { agg.mergeRemove(copy) }      // 锁内 remove
      // while 继续 → 回到锁内 copyForUse 检查

5.3 并行时序对比

GDP 时序

V2 时序

6. 重试机制对比

7. 性能量化对比

7.1 每事件周期操作计数

7.2 内存开销

7.3 延迟分析

7.4 吞吐量对比

瓶颈分析

8. 场景化深度分析

场景 A: 正常低频 (1K key, 1K events/sec)

场景 B: 高频突发 (100 key, 500K events/sec)

场景 C: 网络抖动 (wsPushProcess 间歇慢 50ms)

场景 D: 大量 key (100K key, 低频)

场景 E: 链路长时间故障 (wsPushProcess 持续失败 10 分钟)

9. 结论

9.1 相同点 (继承自 GDP 的核心模式)

9.2 V2 相对 GDP 的改进

9.3 GDP 的优势 (V2 未覆盖)

9.4 一句话总结