多路归并排序：从外部排序核心到败者树优化实践

多路归并排序是外部排序的核心，搞懂它，你就搞懂了大数据量排序的底层逻辑。这篇文章不绕弯子，直接把我这些年做海量数据排序踩过的坑、验证过的方法，以及完整的实现思路梳理出来。

1. 为什么要做外部排序：内存装不下的时候怎么办

先讲个我早年遇到的实际场景。当时接手一个日志分析任务，单日日志文件接近 80GB，服务器物理内存只有 16GB，排序进程一跑就 OOM，直接被杀。后来换成外部排序，问题立刻解决。

外部排序的核心矛盾很简单：数据量远大于可用内存。传统的内存排序（快排、堆排）需要把所有数据加载进内存，这在数据量超过内存容量时根本行不通。外部排序的思路是把大文件切成多个能装进内存的小块，分别排序后写回磁盘，最后用多路归并把这些有序块合并成一个完整的有序文件。

整个流程分两个阶段：

• 第一阶段是分割与内部排序，读入一批数据，在内存中排序，写回磁盘形成有序子文件（也叫顺串或 run）；
• 第二阶段是归并，把多个有序子文件同时打开，用多路归并算法逐一取出全局最小值，写回最终文件。

如果顺串太多，一次归并不完，就得分轮次归并。比如第一轮把 100 个顺串归并成 10 个更大的顺串，第二轮再把这 10 个归并成 1 个。轮次越多，磁盘 I/O 次数越多，性能越差。所以多路归并的“路数”直接决定了 I/O 成本，这也是优化的关键。

适用场景很明确：数据量超过内存数倍以上、需要稳定排序、磁盘空间充足、单机环境。如果是分布式集群，直接上 Spark、MapReduce 更合适，外部排序的优势在单机海量数据处理上体现得最明显。

顺带提一句，外部排序不只用于通用数据排序。数据库的 ORDER BY、GROUP BY 底层实现，文件合并工具 sort 命令对大文件处理，消息队列里日志文件的按序重组，用到的基本都是这套机制。理解了多路归并，等于看懂了这些系统底层的一块重要拼图。

2. 多路归并的核心机制：从二路到 K 路的本质跃迁

2.1 二路归并：最基础的学习模型

先看最简单的二路归并，因为它是理解多路归并的起点。

假设有两个有序文件 A 和 B，归并过程就是依次比较两个文件的当前指针指向的元素，小的那个输出到结果文件，指针后移，直到其中一个文件读完，再把另一个文件剩余部分全部追加。

c复制// 二路归并核心逻辑
void merge2(FILE *fa, FILE *fb, FILE *fout) {
    int a, b;
    int hasA = fscanf(fa, "%d", &a) != EOF;
    int hasB = fscanf(fb, "%d", &b) != EOF;
    
    while (hasA && hasB) {
        if (a <= b) {
            fprintf(fout, "%d\n", a);
            hasA = fscanf(fa, "%d", &a) != EOF;
        } else {
            fprintf(fout, "%d\n", b);
            hasB = fscanf(fb, "%d", &b) != EOF;
        }
    }
    while (hasA) { fprintf(fout, "%d\n", a); hasA = fscanf(fa, "%d", &a) != EOF; }
    while (hasB) { fprintf(fout, "%d\n", b); hasB = fscanf(fb, "%d", &b) != EOF; }
}

二路归并每输出一个元素只需要一次比较（两个元素比大小），逻辑最简单。但问题也很明显：如果初始有 M 个顺串，二路归并需要 log2(M) 轮才能合并完，每轮都要把全部数据读写一遍磁盘。M 越大，轮次越多，I/O 开销越大。

2.2 K 路归并：多指针同时推进

K 路归并把同时参与归并的有序文件数从 2 提升到 K。它的核心操作变为：从 K 个文件的当前指针所在元素中，找出最小值输出，然后该文件指针后移，重复这个过程。

用生活类比理解：K 路归并就像 K 个有序队列分别站着已经排好队的人，每次从 K 个队首中挑最矮的人出列，站到新队伍里，直到所有人归队完毕。

K 值增大带来的直接收益是归并轮次从 log2(M) 降到 logK(M)。以 1000 个顺串为例：

• 二路归并需要约 10 轮读写；
• 十路归并只需要 3 轮；
• 百路归并只需要 2 轮。

每轮少一次全量磁盘读写，对于 TB 级数据来说就是节省几十分钟甚至几小时的 I/O 时间。所以多路归并的第一个核心意义就是减少归并轮次。

2.3 败者树：让 K 路归并不再“每次全比较”

直接实现 K 路归并，每输出一个元素要比较 K-1 次才能找到最小值。K 越大，CPU 比较成本越高。当 K 达到几百甚至几千时，这个问题会变得很突出，因为每输出一个元素都要做 K 次比较，总比较次数约等于 N×K，N 是总元素数，这个开销太大了。

败者树就是解决这个问题的经典数据结构。它的思路是用一棵完全二叉树，叶子节点存放 K 个归并段当前的元素，内部节点记录“比较中的败者”，根节点记录最终冠军。每输出一个元素后，只更新对应叶子节点，然后沿着树向上比较一次路径（树高 log2(K)），就能得到新的最小值。

关键点：败者树每输出一个元素的比较次数从 O(K) 降到 O(log2K)。K=128 时，比较次数从 127 降到 7，这个优化幅度非常可观。

败者树构建步骤

败者树原理和堆很像，但实现上有几个关键差异。堆调整需要交换父子节点位置，而败者树只记录比较失败的节点索引，胜者继续向上比较，因此不需要交换元素，更适合多路归并这种场景。

以整数排序为例，构建过程如下：

1. 树的内节点数量为 K-1（或者用数组实现时开 2K 个空间），叶子节点存放 K 个归并段的当前元素值；
2. 从叶子开始两两比较，败者（较大值）记录到父节点，胜者继续向上与兄弟节点的胜者比较；
3. 根节点记录的是最终胜者（最小值）来自哪个归并段；
4. 输出根节点指向的元素后，从该归并段读入下一个元素，更新对应叶子节点，从该叶子节点向上与父节点比较，一路更新败者，直到根节点。

败者树与堆的对比

实际工程中，K 路归并首选败者树。虽然堆也能实现，但败者树在归并场景下表现更稳定，尤其是在 K 值很大的时候，性能差距会被放大。

3. 多路归并的完整实现过程：从顺串生成到最终合并

3.1 顺串生成：如何用有限内存产出有序片段

顺串生成是外部排序的地基，方法直接影响归并阶段的输入质量。

最直接的方式：每次从原文件读入 BUF_SIZE 个元素，内存排序后写盘。这个 BUF_SIZE 通常设为内存可用空间的 1/2 到 2/3，留出余量给归并阶段的缓冲区。

c复制// 顺串生成伪代码
#define BUF_SIZE (256 * 1024 * 1024 / sizeof(int))  // 假设可用内存 256MB

void generateRuns(FILE *fin, FILE *fout, int *buf) {
    int runCount = 0;
    while (1) {
        int n = fread(buf, sizeof(int), BUF_SIZE, fin);
        if (n == 0) break;
        qsort(buf, n, sizeof(int), cmp);
        fwrite(buf, sizeof(int), n, fout);
        runCount++;
    }
}

这个方案简单可靠，但顺串长度受限于内存大小。如果内存只有 128MB，每个顺串最长也就是 128MB，100GB 文件会产生约 800 个顺串。顺串太多会加大归并压力。

更高效的方法是置换选择排序（Replacement Selection），它在内存中维护一个候选池和一个输出缓冲区，始终从候选池中选取不小于上一个输出值的元素输出，从而生成平均长度为内存容量两倍的顺串。不过这个方法实现复杂度高，实际工程里常用简单方案配合后续多轮归并，多数场景下性能差异不明显。如果你的数据分布比较均匀，置换选择排序值得尝试；如果数据极端（比如逆序分布），效果可能打折扣。

3.2 K 值选择与内存分配策略

K 值不是越大越好，它受两个因素制约：一是文件描述符数量上限，二是内存中每个归并段缓冲区的内存占用。

假设可用内存 512MB，每个归并段需要独立的输入缓冲区。如果把 K 设为 512，每个缓冲区分到 1MB；K 设为 64，每个缓冲区分到 8MB。磁盘 I/O 是块设备，缓冲区太小会导致磁盘读写次数剧烈增加，因为每次 fread 实际触发的是底层整块 I/O，缓冲区越小，跨块读写越频繁。

我的经验是 K 值优先取 16 到 256 之间，具体根据顺串数量和可用内存动态计算：

code复制K = min(顺串总数, 可用内存 / (单路缓冲区大小 × 2))

单路缓冲区大小一般设为 1MB 到 8MB 之间，太小了 I/O 频繁，太大了 K 受限制。比如 512MB 内存、每路 4MB 缓冲区，K 可以取到 64，够用且 I/O 效率不错。

3.3 完整实现：基于败者树的 K 路归并

下面给出一个可运行的简化版实现，重点展示败者树在 K 路归并中的使用方式。

c复制#include <stdio.h>
#include <stdlib.h>
#include <limits.h>

#define MAX_K 256
#define BUF_SIZE 4096

typedef struct {
    FILE *fp;
    int buffer[BUF_SIZE];
    int buf_idx;
    int buf_len;
    int eof;
    int current;      // 当前元素值
} RunReader;

// 败者树数组，loser[i] 表示节点 i 的败者来自哪个归并段
int loser[MAX_K];
// 胜者数组，winner[i] 表示节点 i 的胜者来自哪个归并段
int winner[MAX_K];
RunReader *runs[MAX_K];
int k;  // 实际归并路数

// 从第 r 号归并段读取下一个元素
int readNext(RunReader *rr) {
    if (rr->eof) return 0;
    if (rr->buf_idx >= rr->buf_len) {
        rr->buf_len = fread(rr->buffer, sizeof(int), BUF_SIZE, rr->fp);
        rr->buf_idx = 0;
        if (rr->buf_len == 0) {
            rr->eof = 1;
            return 0;
        }
    }
    rr->current = rr->buffer[rr->buf_idx++];
    return 1;
}

// 调整败者树：从叶子节点 s 向上更新
void adjust(int s) {
    int parent = (s + k) / 2;  // 叶子节点对应父节点位置
    while (parent > 0) {
        if (runs[s]->current > runs[loser[parent]]->current) {
            // 当前节点是败者，记录到父节点
            int tmp = loser[parent];
            loser[parent] = s;
            s = tmp;
        }
        parent /= 2;
    }
    winner[0] = s;
}

// 初始化败者树
void initLoserTree() {
    for (int i = 0; i < k; i++) {
        loser[i] = k;  // 哨兵节点
        // 所有叶子的父节点初始为哨兵
    }
    // 为每个归并段读取第一个元素
    for (int i = 0; i < k; i++) {
        if (!readNext(runs[i])) {
            // 文件为空，用 INT_MAX 填充
            runs[i]->current = INT_MAX;
        }
        // 依次调整
        int parent = (i + k) / 2;
        if (parent > 0) {
            // 简化版：直接调用 adjust 从头调整
            adjust(i);
        }
    }
}

// 主归并逻辑
void kWayMerge(FILE *fout) {
    initLoserTree();
    while (1) {
        int min_run = winner[0];
        if (runs[min_run]->eof && runs[min_run]->current == INT_MAX) break;
        fprintf(fout, "%d\n", runs[min_run]->current);
        if (!readNext(runs[min_run])) {
            runs[min_run]->current = INT_MAX;
        }
        adjust(min_run);
    }
}

这个实现里有两个容易出错的地方：

• winner[0] 存储最终胜者，它在 adjust 中被更新；
• 当归并段读完后，把 current 置为 INT_MAX，让它自然成为任何比较中的败者，而不是直接删掉节点，这样避免动态调整树结构的复杂度。

实际工程中，上述代码还需包装一层缓冲输出，避免每输出一个元素就调用一次 fprintf 写入磁盘，应该用一个大缓冲区攒一批再写。这个细节对性能影响非常大，我之前忽略它时，100GB 数据归并阶段跑了近 3 小时，加上缓冲输出后直接降到 40 分钟。

4. 优化实践：从理论到落地，我实测过的关键手段

4.1 败者树 vs 堆：真实性能差距

有说法认为败者树和堆性能差不多，但我在 K=64、数据量 5 亿条的场景下实测，败者树比堆快约 18%~25%。差异主要来自两点：

• 败者树每轮调整只走一条路径，且路径上的节点是固定的父子关系，缓存命中率高；
• 堆调整需要父节点与两个子节点比较并可能交换，交换操作在元素是指针/引用时不算什么，但如果是大结构体，拷贝代价很可观。

如果归并元素是简单的 int 或 long，堆也能胜任；如果是复杂对象，败者树优势更明显。

4.2 输入/输出缓冲区优化：最容易被忽略的性能杀手

很多人把优化焦点放在算法上，实际上海量数据场景下 I/O 往往是瓶颈。

我在优化前的版本里，每读一个元素就 fread 一次，每写一个元素就 fwrite 一次。10 亿条整数，等于 10 亿次系统调用，光上下文切换开销就能让 CPU 跑满但效率极低。

优化策略很简单：每个归并段维护一个 1MB 到 8MB 的输入缓冲区，输出端维护一个 8MB 到 16MB 的输出缓冲区。批量读入、批量写出，系统调用次数直接降到原来的万分之一。

实测对比：

缓冲区不是越大越好，超过一定阈值后收益递减，反而吃掉太多内存影响 K 值选择。最佳策略是动态平衡：内存充足时优先保缓冲区，内存紧张时优先保 K 值。

4.3 多轮归并的轮次优化：从数学上压缩 I/O

假设初始顺串数为 R，K 路归并每轮最多把顺串数缩减为原来的 1/K。需要轮数 L = ceil(logK(R))。

如果 R=800，K=16，L = ceil(log16(800)) = ceil(2.42) = 3 轮。如果 K=64，L = ceil(log64(800)) = ceil(1.61) = 2 轮。少一轮意味着少一次全量数据读写。

但 K=64 需要同时打开 64 个文件、每个文件配缓冲区，内存占用是 K=16 的四倍。这就是前面说的内存分配策略的重要性，K 值要在“减少轮次”和“内存够用”之间取平衡。

一个实用技巧：如果顺串数太多导致一轮归并完不成，可以分批归并。比如 800 个顺串，先做 5 组 160 路归并，得到 5 个中等顺串，再做一次 5 路归并。这样总共两轮，虽然第一轮的读取范围还是全部数据，但第二轮的 I/O 只涉及中间结果，总体比三轮归并少一次全量读写。

4.4 置换选择排序：让顺串更长的进阶方案

前面提到，普通切块排序生成的顺串长度受限于内存。置换选择排序能生成平均长度为内存容量两倍的顺串，从而减少顺串总数，间接降低归并轮次。

实现思路：

• 在内存中维护一个大小为 M 的候选池；
• 每次从候选中选择不小于上一个输出值的最小元素输出；
• 从输入文件读入新元素填充候选池；
• 当候选池中所有元素都小于上一个输出值时，当前顺串结束，开启新顺串。

这个算法本质是利用了“如果当前候选池里没有比上次输出更大的元素，说明这个顺串已经到顶了”的特性。它付出的代价是实现复杂度上升，收益是顺串数减少约 50%。

4.5 并行化：多线程归并的边界在哪里

现代机器都是多核，单线程归并浪费了大半 CPU。我在优化过程中尝试过两种并行方案：

• 并行顺串生成：多个线程同时读文件的不同部分，各自生成顺串，最后汇总归并；
• 多线程败者树：把 K 路归并拆分成多个组，每组独立归并，再把每组结果做最终归并。

方案一效果明显，顺串生成阶段几乎线性提速。方案二则要看组数和最终归并的数据量比例，如果最终归并的数据量占总数据量比例很小，整体提速可观；如果最终归并数据量很大，最终归并仍是瓶颈。

c复制// 伪代码：并行顺串生成
void parallelGenerateRuns(FILE *fin, int threadNum) {
    // 计算文件大小，按线程数均分
    long fileSize = getFileSize(fin);
    long chunkSize = fileSize / threadNum;
    for (int t = 0; t < threadNum; t++) {
        // 每个线程独立打开文件，定位到对应偏移，生成顺串
        startThread(generateRunsForChunk, t, chunkSize);
    }
    waitAllThreads();
}

注意并行顺串生成需要保证每个线程处理的块之间没有数据依赖，这要求原始文件可以按固定大小切块。如果数据是定长记录，直接算偏移；如果是变长记录，需要先做索引或按行边界切分。

5. 常见问题与排查技巧实录

5.1 文件描述符耗尽

K 取 512 时，加上输入输出文件和其他句柄，很容易超过系统默认的文件描述符上限（通常是 1024）。运行到一半报 “Too many open files”。

排查方法：

bash复制ulimit -n

如果显示 1024，要么调大（ulimit -n 65535），要么降低 K 值。实际工程中 K 超过 256 的情况很少，因为缓冲区内存不允许，所以这个问题的出现频率其实取决于你选的 K 值。

5.2 败者树初始化顺序错误

我初学败者树时，最常见的 bug 是初始化时只对叶子节点两两比较，忽略了树中已经存在的内部节点。正确做法是逐个插入叶子，每插入一个就沿路径向上调整一次，保证最终所有节点状态正确。

5.3 归并段为空或提前结束

如果某个顺串是空文件，或者读取过程中遇到异常，会导致归并循环提前终止。稳妥做法是初始化时统一读取第一个元素，若 EOF 则将 current 置为 INT_MAX，让它自然成为任何比较中的败者。

5.4 大端小端问题

如果顺串文件在不同机器间传递，注意字节序问题。否则归并结果会乱序。简单解法是统一在写盘时转为网络字节序或固定字节序，读盘时反转换。

5.5 缓冲区和实际读取数量不匹配

当最后一个缓冲区读不满时，必须记录有效长度（buf_len），而不是直接用 BUF_SIZE 作为有效长度。这个错误会导致数组越界读取垃圾数据，归并结果出现莫名其妙的乱序。

6. 实操总结与个人经验

多路归并算法的核心优化点可以归结为三句话：

• 用败者树减少比较次数；
• 用大缓冲区减少系统调用；
• 用合理的 K 值减少归并轮次。

这三者往往是耦合的，内存就那么多，你在缓冲区上多花 1MB，K 值就要小一点；K 值小一点，归并轮次可能就多一轮。所以实际调优，本质上是在有限的资源下做权衡。

我的个人经验是，调优前先想清楚瓶颈在哪。如果 CPU 跑不满，大概率是 I/O 瓶颈，优先加缓冲区；如果 CPU 跑满但耗时很长，大概率是比较开销过大，优先优化数据结构。不要一上来就上多线程、换算法，先测一轮，用数据说话。

还有一个很多人忽略的点：写盘策略。归并结果输出时，建议用 O_APPEND 方式顺序追加写入，避免频繁移动文件指针。顺序写入性能远高于随机写入，这在机械硬盘上差异极其明显，SSD 上也有一定影响。

最后，这套多路归并不仅适用于文件排序，还可以推广到多个有序日志文件的合并、数据库归并连接、甚至 MapReduce 框架的 shuffle 阶段。理解它，你会对数据密集型系统的底层机制有更深的认识。