4. 对账任务并行化基础

对账任务天然具备“可切分、可聚合”的特征：它通常按业务日期、渠道、币种、账套等维度处理海量流水，最终输出差异明细与汇总结果。当单机串行处理无法在时间窗口内完成时，并行化是提升吞吐的第一手段。但并行化不是简单多开线程，而是要先选对计算模型，再设计任务拆分与数据分片，最后用负载均衡把长尾压下去。

一、核心原理：三种并行计算模型

对账场景中常见的并行模型可以归纳为三类，它们的资源边界和适用条件差异明显。

• 数据并行：把同一套对账逻辑复制到多个执行单元，每个单元处理不同分片的数据。适合“逻辑一致、数据可分”的场景，例如按渠道分片后各自跑“平台流水 vs 银行流水”的比对。
• 任务并行：把对账流程拆成多个独立阶段或子任务，例如“拉取流水、清洗、匹配、差异归类、汇总”分别并行。适合阶段间依赖弱、可流水线化的场景。
• 流水线并行：将阶段串成管道，不同数据批次在不同阶段同时推进。适合单批次耗时长、但批次之间无强依赖的场景，能显著缩短整体完成时间。

二、任务拆分策略：从“能拆”到“拆得均匀”

任务拆分的核心目标是让每个子任务的计算量接近，同时避免跨分片依赖。对账任务常用的拆分维度如下：

1. 按时间分片：以账务日期或小时为单位切分，适合流水按时间递增写入的场景。注意跨日切分可能产生边界流水遗漏。
2. 按业务维度分片：按渠道、商户、币种、账套拆分，天然隔离，适合多租户对账。
3. 按数据量分片：先统计每个键的流水条数，再按条数做范围切分，避免“一个渠道占80%数据”导致倾斜。
4. 按主键哈希分片：对订单号或流水号做哈希取模，保证同一笔业务落到同一分片，适合需要精确匹配的场景。

拆分后要定义清晰的“分片键”和“聚合键”。分片键决定并行度，聚合键决定结果如何合并。例如按渠道分片、按日期聚合，则每个分片输出“渠道+日期”的差异汇总，最后由汇总任务合并。

三、数据分片与负载均衡：把长尾压下去

数据分片解决“数据放在哪”，负载均衡解决“谁来处理”。两者配合不当，会出现部分节点空转、部分节点排队。常见做法是动态分片加工作窃取：先把数据切成远多于执行单元的小块，放入任务队列，空闲执行单元主动领取。这样即使某些分片特别大，也不会长期绑定在某个节点上。

下面是一个按“渠道+日期”生成分片并按数据量排序后动态调度的伪代码示例：

shards = []
for channel in channels:
    for day in date_range:
        cnt = count_flow(channel, day)
        shards.append({channel, day, cnt})

# 按数据量降序，优先处理大分片，减少尾部等待
shards.sort(key=lambda s: s.cnt, reverse=True)

queue = Queue(shards)
results = []
def worker():
    while not queue.empty():
        shard = queue.get()
        r = reconcile(shard.channel, shard.day)
        results.append(r)

start N workers
wait all workers done
merge(results)

负载均衡还需要关注“倾斜检测”。可以在运行中输出每个分片的处理耗时和条数，若某分片耗时超过平均值3倍，说明分片粒度或拆分维度需要调整。

四、案例与误区复盘

某支付平台日终对账，单机串行处理约需4小时，无法满足凌晨2点前出结果的要求。改造时先按“渠道+日期”拆成约200个分片，再按数据量降序放入队列，启动8个Worker动态领取。结果整体耗时降到35分钟，但仍有2个分片耗时超过20分钟，原因是某渠道当天有大量补单流水，数据量是平均值的6倍。

复盘后做了两件事：一是把大渠道再按“小时”二次拆分，二是增加倾斜检测，当分片条数超过阈值时自动细分。调整后最长分片耗时降到6分钟，整体稳定在25分钟以内。

总结来看，对账并行化的基础可以概括为：选对计算模型决定并行上限，合理拆分决定并行效率，动态分片与负载均衡决定长尾能否被压住。三者缺一不可，任何一环设计不当，都会让“并行”退化为“部分节点忙、部分节点等”的伪并行。