岁寒

Lower Latency Is All You Need 降低延迟，提升性能！

JohnLui — Wed, 05 Mar 2025 18:17:33 +0000

引子：从一次服务器迁移说起

2022 年，为了顺应降本增效的市场大环境，我决定把一个非关键服务从云上搬迁到本地机房的二手服务器上，节省一些云服务器的费用。这是一个面向搜索引擎 SEO 的 CMS 站点，重度依赖 ElasticSearch，轻度依赖 MySQL 和 Redis，所以我首先把后端应用和 ES 集群搬迁到了本地，MySQL 暂时留在了云上，本地机房的后端代码直接访问云上数据库。

在 Kong 网关的配合下，倒是也实现了服务的无缝切换，0 停机切换完成了。但是，跑起来之后我发现，之前平均 120ms 的页面响应时间大幅增加到了 500ms 以上，页面明显卡顿。经过我一顿代码追踪，发现本地机房的后端代码每次请求云上数据库，延迟都在 10ms 以上，而云上后端代码的延迟在 1ms 以内。而每个 CMS 页面内的 SQL 查询都有几十条，链式放大的延迟累加下来，页面总响应时间就 500ms 了。随后我把数据库也搬到了本地机房，世界美好了。

从这个故事可以看出，延迟是性能的隐形杀手，做性能优化需要系统性思维。目前常见大规模分布式系统一般会采用所谓异地多活的架构来搭建，其实就是按照地理位置分区：给北京的用户 ID 绑定北京机房，哪怕他出差去了上海，也要把他的请求路由回北京机房，千万不能让上海机房的后端代码直接读写北京机房的数据库，延迟会爆炸的。

带宽的突飞猛进

过去十年，我们日常使用的很多技术的“带宽”在数字上实现了非常夸张的进步：

	2014 年	2024 年	倍率
北京家庭宽带速率	20Mbps 及以下占比 86%	运营商最低家庭带宽 200M~300M，2023Q1 荣膺世界网速最快城市	15
电脑 PCIe 速率	正在普及 PCIe 3.0，X16 约 16GB/S	正在普及 PCIe 5.0，X16 约 64GB/S	4
内存速度	DDR3 1600MHz 为主流，双通道速率 24GB/S	DDR5 5600Mhz 为主流，双通道速率 98GB/S	4
硬盘速度	机械硬盘为主流，100MB/S；最先进的 SATA SSD 500MB/S	PCIe 4.0 SSD 为主流，7000MB/S；最先进的 PCIe 5.0 NVME 14000MB/S	70
WiFi 速率	完全处于 2.4 GHz 时代，最大协议速率 192Mbps	5GHz WiFi-6 已经普及，主流手机及电脑的协议速率均已经普及 2.4Gbps	12.5
移动网络速率	3G 尚未普及，占比低于 50%，速率 200KB/S	5G 几乎普及，速率 50MB/S	250

我们见证了数据传输速度的跨越式发展：PCIe 5.0 协议实现了 64GB/S 的总线带宽，NVMe 固态硬盘的读写速度赶上了十年前内存的读写速度，随机读写性能已达到机械硬盘难以想象的水平，双万兆光纤也已经入户。然而，延迟并没有缩短多少——PCIe 5.0 协议层的 TLP 事务处理延迟仍然维持在纳秒级区间，NVMe SSD 的 4K 随机访问延迟（通常>100μs）与 DDR4 内存（约 15ns）仍存在三个数量级的差距。而在网络通信中，TCP/IP 协议栈的处理开销、网络设备的转发延迟，以及路由决策的时间消耗，都构成了无法仅依靠带宽提升来解决的系统瓶颈。这种延迟累积效应，使得终端用户在高带宽环境下的实际体验并没有获得数字倍数那么巨大的改善。

延迟：高性能计算真正的敌人

可能和大家的直觉不同，在高性能计算（HPC）领域，真正制约系统潜力的不是算力，不是带宽，而是延迟（Latency）。无论是分布式系统的跨节点通信，还是客户端到服务端的网络连接，再到芯片的每一次数据传输，延迟始终像幽灵般贯穿计算链条，吞噬效率、放大瓶颈。理解延迟的本质及其破坏性，是优化系统性能的第一步。

接下来，让我们从大往小，从宏观往微观，从系统架构到数据链路，从网络协议到 Kernel 设计，从磁盘到内存再到缓存，从主板电路到芯片构造推进，逐步探寻延迟对性能的巨大影响。

架构层面的延迟

光速极限

在跨地域强一致性场景中，光速限制是不可突破的物理边界。光纤的折射率约为 1.5，光在光纤中的传播速度为大约 20 万千米/秒。而北京上海直线距离 1088 公里，即便是拉一根笔直的线，再用超大发射功率发射器进行无中继传输，一步从北京打到上海，最低也需要 5.44ms 的延迟。现实中，北京至上海延迟最低的是金融专线，只能控制在刚刚 10ms 以下。

因此，我们一定要规避掉跨地域的数据库调用，否则每个写操作都要等待至少 20ms 的往返延迟，这是无法接受的。这种由宇宙基本常数决定的限制，迫使我们必须在结构层面进行妥协——要么采用最终一致性模型，要么使用地理位置进行系统分区，追求强一致性就只能“处处等”。

选择合适的分布式一致性等级

电商库存系统通过一致性分级可以实现性能跃升：支付环节采用预扣库存的强一致性模型（基于分布式锁实现 ACID 事务），库存展示则采用最终一致性模型（通过异步对账补偿机制保证 BASE 特性）。

异步化架构

当然，我们也可以使用终极大招——异步化改造。例如将同步 RPC 调用转换为消息队列的异步事件流（如 Kafka），再用背压机制（Backpressure）来控制生产消费的速率平衡，这样可以显著提升系统吞吐量。

虽然异步架构可以实现从“等待”到“非阻塞”的范式迁移，但是对流程的改动较大，调试难度很大，出问题了比较难修，需要权衡利弊，只在最合适的场景中使用。正如设计模式是面向对象对象编程范式对现实问题的妥协，异步架构也是图灵机模型对现实问题的妥协。

网络通信中的延迟

协议栈时延放大效应

网络协议栈的逐层封装机制会显著放大端到端延迟。典型的 HTTP 请求需要经历 TCP 三次握手（1.5 RTT）、TLS 密钥协商（1 RTT）等阶段，若遇 DNS 递归查询、反向代理、Keep-Alived 失效重连等情况，单次跨地域 API 调用延迟可能会突破 100ms。

RTT：Round-Trip Time 往返时延 。它表示一个数据包从发送端发出，经过网络传输到达接收端，再由接收端返回确认信息到发送端所需的总时间。Ping 命令输出的值就是 RTT。

传输层拥塞控制优化

高延迟网络中，传统 TCP Cubic 算法在慢启动阶段需多次 RTT 探测带宽，导致首帧渲染时间（TTFB）过长。采用 BBR（Bottleneck Bandwidth and Round-trip propagation time）算法可基于带宽与 RTT 实时建模，动态调整拥塞窗口，在低速网络中可以显著降低首次数据传输延迟。

用户态网络协议栈重构

传统内核网络协议栈因系统调用、内存拷贝（如 sk_buff 复制）导致高吞吐场景（单网卡大于 2Gbps）下性能上不去，远远跑不到网卡的极限。DPDK（Data Plane Development Kit）可以绕过 Kernel，在用户态接管网卡。如果配合使用轮询模式驱动（PMD）、大页内存与 NUMA 亲和性优化等方式，可以实现终极零拷贝网络包处理，单机可稳定处理 200Gbps 流量。

Kernel 的网络架构太落后了，在今天的网卡带宽面前显得性能很差，核心还是内存技术一直没有革命性的突破：数据接收需要 CPU 在用户态和内核态之间切换不止一次，这就要读写内存，而读写内存在 400Gbps 的网络洪流面前实在是太慢了，单通道 DDR4 内存的读写速度都不到 400Gbps。

除了系统软件层面的优化，硬件层面的优化也非常重要。

网络芯片创新

一种常见的硬件方案是采用专用网络处理器（NPU），通过异构计算架构来降低延迟。

将 TCP/IP 协议栈固化到 NPU 中，不再需要 CPU 来计算
RDMA（远程直接内存访问）通过 Verbs API 实现应用层内存直接读写，绕过多层协议栈
大容量 SRAM（如 256MB 片上缓存）实现高频流表项本地查询
可编程流水线支持动态加载 P4 程序（SDN 中一种专为网络数据平面设计的编程语言），实现微秒级协议转换
卸载 TLS 加解密功能到 NPU 中，可以显著加快 TLS 握手速度

物理层传输介质革新

空芯光纤（Hollow-Core Fiber）通过空气介质传输光子，相较传统石英光纤（折射率 1.44）将光速提升 30%，伦敦至纽约金融专线使用这项技术让延迟降低了 5ms。

光子集成电路（PIC）在硅基衬底上集成激光器、调制器与波导，绕过整个“光电转换 - 以太网 - TCP/IP”技术栈，直接在芯片间实现 Tbps 级的光互连，可以将光模块的传输延迟从 3ns 压缩至 200ps，这对超算集群的性能来说至关重要。超级计算机最大的瓶颈就是信息传递的速度，光通信的技术创新将是下一个十年人类攀登超级计算机高峰的利器。

CPU 到内存的延迟

当系统架构与网络优化将延迟压缩到物理极限时，CPU 与内存之间的“最后一公里”就成为了新的战场。现代 CPU 的时钟周期以纳秒（10⁻⁹秒）为单位，而访问内存的延迟却高达百纳秒级——这相当于战斗机驾驶员要等待三分钟才能获得雷达扫描结果，饥渴的 CPU 在等待中浪费了 99% 的计算潜力。

当前 x86 服务器和 PC 上最常用的 DDR 内存技术，在主板设计时却把“内存条数量可随时增减”设为了第一设计目标，而不是限制内存条的配置形式来降低延迟。你看苹果就很聪明，M1 芯片起手就是 Unified Memory 统一内存——直接把 LP-DDR 内存芯片封装在 CPU 芯片的基板上，在物理上降低内存延迟。你说消费者可选的内存配置有限？那是消费者的问题，跟我苹果有什么关系 :D

网络通信是一种可以兼容任何延迟、任何速率的通信技术，随之而来的便是从硬件到软件的复杂。而计算机最基础的硬件通信，如 DDR 内存，PCIe 总线等技术，为了能够和 CPU 进行标准化的超高带宽通信，并保持简单和低成本，会在硬件层面进行标准化设计。例如 DDR 内存就需要保证 CPU 到每一根内存条上的每一个 bank 的延迟（时序偏移）要非常严格地固定，误差要极低，否则就会出现内存错误。这是因为 DDR 内存依赖严格的时序控制，会在时钟的上升沿和下降沿进行两次数据传输。

另外，DDR 内存在通电后其实是一直在不停地自行刷新（充电）的，全部内存行加在一起的刷新周期通常为 64ms，因为存储信息的电容一直在漏电，时间长一点数据就没了，这种充电刷新机制也在极限场景下限制了 DDR 内存的最低读写延迟。

CPU 到缓存的延迟

现代 CPU 架构本质上是一个「内存延迟补偿装置」，其缓存层级设计堪称计算机工程史上最精妙的空间换时间案例：

L1 缓存：分为指令缓存、数据缓存，3-4 周期访问延迟，容量仅数十 KB。其访问速度与寄存器相当，但程序员必须像布置雷区般谨慎，想吃到 L1 缓存的性能，需要严格控制每一个程序块中的变量大小和数量。一般为单个 CPU 核心独享。

L2 缓存：12-15 周期延迟，容量数百 KB。一般为单核心独享或者少量核心簇共享

L3 缓存：一般为芯片 Die 中所有核心共享，30-50 周期延迟，容量数十 MB。AMD 通过 3D V-Cache 技术，让八核 CPU 的三级缓存达到了 128MB，成功在游戏场景中登顶，彻底打破了持续了十多年的“i3 默秒全”噩梦。

这里需要提一嘴，上一次 AMD 打游戏比 Intel 强还是 K8 架构，那一年，AMD 首次把内存控制器从北桥芯片吸收到了 CPU 内部，大幅降低了内存延迟，而当时英特尔掏出来的却是高频低能的奔腾 4，AMD 实现了首次性能登顶。那其实也是一个低延迟打败高频率的故事。

内存墙困境：即使是最快的 DDR5-6400 内存，访问延迟仍在 70ns 以上。当发生缓存未命中时，CPU 流水线会像突然断油的发动机那样陷入空转——内存一日，CPU 一年。

NUMA 架构的局部性：在 4 路 NUMA 服务器中，访问远端内存节点的延迟是本地访问的 2.3 倍。

TLB 击穿：当进程虚拟地址空间超过 TLB 缓存容量时，每次内存访问都需要多级页表查询。为了避免这问题，我们可以采用大页内存技术，这在 Redis 持久化场景中十分有用。

分支预测赌博：现代 CPU 的分支预测准确率可达 95% 以上，但预测失败的惩罚高达 15-20 周期。

SIMD 高级指令集：将循环操作转换为 SSE/AVX 指令，不仅提升吞吐量，更能减少指令解码延迟。ClickHouse 的聚合操作（如 SUM、COUNT、AVG 等）大量使用了 SIMD 向量化指令集，达成了“性能随 CPU 核心数量线性增长”这一可怕成就。例如 AVX512 指令集可以在一个时钟周期内完成 32 次双精度浮点数的计算，或者 64 次单精度浮点数的计算。

那么，SIMD 指令集看起来已经是最适应 AI 时代的计算工具了，为什么现在英伟达能冲上美股是指第一名呢？因为皮衣刀客老黄是真的有两把刷子，从大规模矩阵并行计算到硬件低延迟高带宽互联，最近一些年的英伟达 GPU 就是为 AI 而生的，打游戏早就成了副业。下面我们摊开好好学习一下。

GPU 读写数据的延迟

在通信原理中，延迟和带宽是没有必然联系的两个技术属性。但是在现实世界的硬件设计中，大部分硬件其实是部署在一个二维平面上的（少数是三维），而电流的速度又无法超过光速，这就决定了硬件设计的一个基本原则：带宽换延迟，延迟换带宽。

显存的高带宽其实是高延迟换的

GPU 的 GDDR 显存采用了与传统 DDR 内存完全不同的设计理念——牺牲延迟以换取超高带宽。GDDR 显存的单颗粒数据位宽仅为 32bit，远低于 DDR 内存的 64bit (ECC 模组为 72bit)，但通过极高的工作频率 (目前最新的 GDDR7 单引脚数据传输速率已达到 32Gbps)，配合更多的 Bank 并发访问，最终实现了数倍于 DDR 内存的带宽。这种设计完美契合了 GPU 的应用场景 - 大规模并行计算往往更依赖内存带宽而非单次访问延迟。

为了进一步缓解显存访问延迟的影响，GPU 采用了细粒度、低开销的线程切换机制。当一个线程组 (Warp) 在等待内存访问时，GPU 可以在一个时钟周期内切换到另一个就绪的线程组继续执行，这种超细粒度的线程切换几乎没有开销。配合 GPU 庞大的线程并发能力 (一个 SM 可以同时管理数千个线程)，使得 GPU 能够有效隐藏内存访问延迟。这种设计与传统 CPU 的上下文切换形成鲜明对比 - CPU 切换线程需要保存/恢复大量寄存器状态，开销巨大。

DDR 内存在某种程度上就像是落后的并口硬盘，而 GDDR 才是串口，是新技术，依靠高频取胜！

下一步，适用于大模型推理的显存可能会是混合显存架构，将 HBM3（4096bit/6.4Gbps）与 GDDR6（256bit/18Gbps）组合，在保持整体高带宽的同时，让热数据的访问延迟降到更低。MOE 混合专家架构就很适合这个方案来提速：全量模型放在 GDDR 中，而被激活的专家放在 HBM 中。

GPU 内存层次结构解析

现代 GPU 采用多级内存架构，从寄存器到全局内存，每一级都有特定的容量与访问速度特征。以 NVIDIA Tesla V100 为例，每个流式多处理器 (SM) 拥有 65536 个寄存器，配合 256KB 的 L1/共享内存和全 GPU 共享的 64MB L2 缓存，最终连接到 32GB 高带宽 HBM2 全局内存。

数据访问路径决定了计算性能——从寄存器到 CUDA 核心的数据移动最快，而从全局内存到计算单元则需穿越多层缓存，产生明显延迟。GPU 内存架构特别优化了 32 线程为一组的访问模式，以 128 字节为单位的缓存行设计，能够同时为 32 个线程提供 4 字节操作数。

GPU 通过"延迟隐藏"机制来克服内存访问延迟。当一个线程束因等待内存而停滞时，硬件调度器会立即切换到其他就绪的线程束继续执行。这种细粒度的多线程交织执行，配合合并访存等优化手段，有效掩盖了内存访问的高延迟。从本质上看，GPU 内存层次结构就是围绕着“总平均延迟最低”而非“单次延迟最低”来设计的。

实际上，显存的带宽已经到达了显著的硬件制造瓶颈，当下大模型的优化重点已经从加速矩阵计算深入到了“保持效果的低精度数据表示”和“超大规模并行计算”上。

HBM 与 GDDR6 等高带宽内存技术

在现代 GPU 架构中，内存带宽已成为决定性能上限的关键因素。HBM (High Bandwidth Memory) 和 GDDR6 是两种主流高带宽内存技术，它们采用截然不同的设计理念来解决带宽瓶颈问题。

H100 计算卡的核心部分，除了芯片，还包含 HBM3 高速显存，他们之间通过台积电的 CoWoS 技术封装在同一块基板上。HBM 内存的低延迟和超高带宽，是 H100 高算力的最大贡献者，芯片规模以及台积电的先进制程的贡献反而要更低一点。

HBM 采用 3D 堆叠设计，将多个 DRAM 芯片垂直堆叠并通过硅通孔 (TSV) 互连，显著缩短了信号路径。以 NVIDIA Tesla V100 为例，其 HBM2 配置包含四个堆栈，每个堆栈八颗内存芯片，提供高达 900GB/s 的峰值带宽。而最新的 H100 采用 HBM3 技术，带宽更是达到惊人的 3TB/s。相比之下，GDDR6 采用传统平面布局但通过更高的时钟频率和更宽的总线宽度提升带宽。在 RTX 系列最新的 GPU 中，GDDR7 可提供约 1TB/s 的带宽。

而由于 HBM 内存芯片离 GPU 芯片更近，所以延迟大约只有 GDDR 的一半。此外，当模型量化从 FP32 降至 FP8 时，不仅计算速度提升，更重要的是通过带宽瓶颈的数据量减少了 75%，这解释了为何 H100 的 FP8 格式能显著加速大模型训练与推理。

其实计算机科学没有银弹，带宽的计算公式其实非常简单：位宽 x 频率。位宽就是“一次性读取的数据量”，位宽需要在底层的电气性能设计和硬件制造上下很大的功夫才能提升一点点，而增加频率却可以通过压缩半导体的制程来较为容易地实现，就像当初放弃并口硬盘改为串口硬盘那样，位宽的增长总有极限，信号串扰，光速牢笼带来的通信延迟，以及三维宇宙的空间限制都是阻碍位宽无限增长的枷锁。

PCIe 通道瓶颈与 NVLink 高速互连技术

PCIe 通道长期以来一直是 GPU 与 CPU 之间数据传输的主要瓶颈。以 PCIe 3.0 x16 为例，其 32GB/s 的双向带宽在大规模数据传输场景下显得捉襟见肘。为了突破这一限制，NVIDIA 推出了革命性的 NVLink 高速互连技术。以 Tesla V100 为例，其配备 6 条 NVLink 2.0 通道，每条通道可提供 50GB/s 带宽，总计可实现 300GB/s 的惊人带宽。

在实际部署中，如 IBM AC922 服务器，每个 V100 GPU 通过 NVLink 获得 150GB/s 与主机的带宽连接，同时 GPU 之间也可通过 NVLink 直接进行高速通信。这种架构不仅大幅降低了通信延迟，还能有效支持大规模深度学习训练等数据密集型工作负载。对于需要频繁在 CPU 和 GPU 之间移动数据的应用来说，NVLink 的高带宽特性至关重要，可以充分发挥 GPU 的计算潜能。

NVLink 不仅提供更高带宽，其延迟性能也优于 PCIe。这对于延迟敏感的应用尤为重要，如大规模 AI 模型训练中的梯度同步和推理过程中的批处理。

所谓的 CUDA 霸权，表面上看是 AI 训练中生态软件的接口依赖，但本质上还是其他公司太菜：大模型训练的瓶颈从来就不是单颗芯片的计算容量，而是多卡互联，协同计算的效率。

NVIDIA HGX H100，由 8 个 H100 SXM5 模块加上 4 个 NVSwitch Chip 在同一个 system board 上，NVSwitch Gen3 芯片其实是英伟达给出的硬件级多卡互联超低延迟解决方案。

异步数据传输与预取机制

现代 GPU 架构通过 NVLink 等高速互连技术显著提升了带宽，然而，即使有高带宽，数据传输的延迟成本仍然不可忽视。解决这一问题的核心策略是数据传输与计算的重叠执行。通过 CUDA 流 (streams)，我们可以在某批次数据计算的同时，异步预取下一批次所需数据。这种方式有效隐藏了传输延迟，保持计算单元的高效利用。

在实际实现中，预取机制更为精细。例如，在处理长上下文生成时，可以每 16 次迭代批量发出预取操作，然后逐个检索结果 4。这种策略在某些基准测试中能将 FP32 内核的性能从 140 微秒提升到 75 微秒，显著加快 token 生成速度。

对于大规模数据处理，如 LLM 推理，合理利用预取和异步传输可以将数据传输开销最小化。特别是当使用 HBM3e 等高带宽内存技术时，如何把 1228GB/S 的带宽跑满才是第一个要解决的问题，DeepSeek 团队就深谙此道。

相关日志：

自己动手开发互联网搜索引擎

JohnLui — Mon, 03 Jul 2023 15:04:53 +0000

写在前面

本文是一篇教你做“合法搜索引擎”的文章，一切都符合《网络安全法》和 robots 业界规范的要求，如果你被公司要求爬一些上了反扒措施的网站，我个人建议你马上离职，我已经知道了好几起全公司数百人被一锅端的事件。

开源代码地址：https://github.com/johnlui/DIY-Search-Engine

《爬乙己》

搜索引擎圈的格局，是和别处不同的：只需稍作一番查考，便能获取一篇又一篇八股文，篇篇都是爬虫、索引、排序三板斧。可是这三板斧到底该怎么用代码写出来，却被作者们故意保持沉默，大抵可能确实是抄来的罢。

从我年方二十，便开始在新浪云计算店担任一名伙计，老板告诉我，我长相过于天真，无法应对那些难缠的云计算客户。这些客户时刻都要求我们的服务在线，每当出现故障，不到十秒钟电话就会纷至沓来，比我们的监控系统还要迅捷。所以过了几天，掌柜又说我干不了这事。幸亏云商店那边要人，无须辞退，便改为专管云商店运营的一种无聊职务了。

我从此便整天的坐在电话后面，专管我的职务。虽然只需要挨骂道歉，损失一些尊严，但总觉得有些无聊。掌柜是一副凶脸孔，主顾也没有好声气，教人活泼不得；只有在午饭后，众人一起散步时闲谈起搜索引擎，才能感受到几许欢笑，因此至今仍深刻铭记在心。

由于谷歌被戏称为“哥”，本镇居民就为当地的搜索引擎取了一个绰号，叫作度娘。

度娘一出现，所有人都笑了起来，有的叫到，“度娘，你昨天又加法律法规词了！”他不回答，对后台说，“温两个热搜，要一碟文库豆”，说着便排出九枚广告。我们又故意的高声嚷道，“你一定又骗了人家的钱了！”度娘睁大眼睛说，“你怎么这样凭空污人清白……”“什么清白？我前天亲眼见你卖了莆田系广告，第一屏全是。”度娘便涨红了脸，额上的青筋条条绽出，争辩道，“广告不能算偷……流量！……互联网广告的事，能算偷么？”接连便是难懂的话，什么“免费使用”，什么“CPM”之类，引得众人都哄笑起来：店内外充满了快活的空气。

本文目标

三板斧文章遍地都是，但是真的自己开发出来搜索引擎的人却少之又少，其实，开发一个搜索引擎没那么难，数据量也没有你想象的那么大，倒排索引也没有字面上看着那么炫酷，BM25 算法也没有它的表达式看起来那么夸张，只给几个人用的话也没多少计算压力。

突破自己心灵的枷锁，只靠自己就可以开发一个私有的互联网搜索引擎！

本文是一篇“跟我做”文章，只要你一步一步跟着我做，最后就可以得到一个可以运行的互联网搜索引擎。本文的后端语言采用 Golang，内存数据库采用 Redis，字典存储采用 MySQL，不用费尽心思地研究进程间通信，也不用绞尽脑汁地解决多线程和线程安全问题，也不用自己在磁盘上手搓 B+ 树致密排列，站着就把钱挣了。

第一步，编写高性能爬虫，从互联网上爬取网页

Golang 的协程使得它特别适合拿来开发高性能爬虫，只要利用外部 Redis 做好“协程间通信”，你有多少 CPU 核心 go 都可以吃完，而且代码写起来还特别简单，进程和线程都不需要自己管理。当然，协程功能强大，代码简略，这就导致它的 debug 成本很高：我在写协程代码的时候感觉自己像在炼丹，修改一个字符就可以让程序从龟速提升到十万倍，简直比操控 ChatGPT 还神奇。

在编写爬虫之前，我们需要知道从互联网上爬取内容需要遵纪守法，并遵守robots.txt，否则，可能就要进去和前辈们切磋爬虫技术了。robots.txt 的具体规范大家可以自行搜索，下面跟着我开搞。

新建 go 项目我就不演示了，不会的可以问一下 ChatGPT~

爬虫工作流程

我们先设计一个可以落地的爬虫工作流程。

1. 设计一个 UA

首先我们要给自己的爬虫设定一个 UA，尽量采用较新的 PC 浏览器的 UA 加以改造，加入我们自己的 spider 名称，我的项目叫“Enterprise Search Engine” 简称 ESE，所以我设定的 UA 是 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4280.67 Safari/537.36 ESESpider/1.0，你们可以自己设定。

需要注意的是，部分网站会屏蔽非头部搜索引擎的爬虫，这个需要你们转动聪明的小脑袋瓜自己解决哦。

2. 选择一个爬虫工具库

我选择的是 PuerkitoBio/goquery，它支持自定义 UA 爬取，并可以对爬到的 HTML 页面进行解析，进而得到对我们的搜索引擎十分重要的页面标题、超链接等。

3. 设计数据库

爬虫的数据库倒是特别简单，一个表即可。这个表里面存着页面的 URL 和爬来的标题以及网页文字内容。

CREATE TABLE `pages` (  `id` int unsigned NOT NULL AUTO_INCREMENT,  `url` varchar(768) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT '网页链接',  `host` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT '域名',  `dic_done` tinyint DEFAULT '0' COMMENT '已拆分进词典',  `craw_done` tinyint NOT NULL DEFAULT '0' COMMENT '已爬',  `craw_time` timestamp NOT NULL DEFAULT '2001-01-01 00:00:00' COMMENT '爬取时刻',  `origin_title` varchar(2000) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT '上级页面超链接文字',  `referrer_id` int NOT NULL DEFAULT '0' COMMENT '上级页面ID',  `scheme` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT 'http/https',  `domain1` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT '一级域名后缀',  `domain2` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT '二级域名后缀',  `path` varchar(2000) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT 'URL 路径',  `query` varchar(2000) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT 'URL 查询参数',  `title` varchar(1000) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT '页面标题',  `text` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci COMMENT '页面文字',  `created_at` timestamp NOT NULL DEFAULT '2001-01-01 08:00:00' COMMENT '插入时间',  PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

4. 给爷爬！

爬虫有一个极好的特性：自我增殖。每一个网页里，基本都带有其他网页的链接，这样我们就可以道生一，一生二，二生三，三生万物了。

此时，我们只需要找一个导航网站，手动把该网站的链接插入到数据库里，爬虫就可以开始运作了。各位可以自行挑选可口的页面链接服用。

我们正式进入实操阶段，以下都是可以运行的代码片段，代码逻辑在注释里面讲解。

我采用joho/godotenv来提供.env配置文件读取的能力，你需要提前准备好一个.env文件，并在里面填写好可以使用的 MySQL 数据库信息，具体可以参考项目中的.env.example文件。

func main() {  fmt.Println("My name id enterprise-search-engine!")  // 加载 .env  initENV() // 该函数的具体实现可以参考项目代码  // 开始爬  nextStep(time.Now())  // 阻塞，不跑爬虫时用于阻塞主线程  select {}}// 循环爬func nextStep(startTime time.Time) {  // 初始化 gorm 数据库  dsn0 := os.Getenv("DB_USERNAME0") + ":" +    os.Getenv("DB_PASSWORD0") + "@(" +    os.Getenv("DB_HOST0") + ":" +    os.Getenv("DB_PORT0") + ")/" +    os.Getenv("DB_DATABASE0") + "?charset=utf8mb4&parseTime=True&loc=Local"  gormConfig := gorm.Config{}  db0, _ := gorm.Open(mysql.Open(dsn0), &gormConfig)  // 从数据库里取出本轮需要爬的 100 条 URL  var pagesArray []models.Page  db0.Table("pages").    Where("craw_done", 0).    Order("id").Limit(100).Find(&pagesArray)  tools.DD(pagesArray) // 打印结果  // 限于篇幅，下面用文字描述  1\. 循环展开 pagesArray  2\. 针对每一个 page，使用 curl 工具类获取网页文本  3\. 解析网页文本，提取出标题和页面中含有的超链接  4\. 将标题、一级域名后缀、URL 路径、插入时间等信息补充完全，更新到这一行数据上  5\. 将页面上的超链接插入 pages 表，我们的网页库第一次扩充了！  fmt.Println("跑完一轮", time.Now().Unix()-startTime.Unix(), "秒")  nextStep(time.Now()) // 紧接着跑下一条}

我已经事先将 hao123 的链接插入了 pages 表，所以我运行go build -o ese *.go && ./ese命令之后，得到了如下信息：

My name id enterprise-search-engine!加载.env : /root/enterprise-search-engine/.envAPP_ENV: local[[{1  0 https://www.hao123.com       0 0 2001-01-01 00:00:00 +0800 CST 2001-01-01 08:00:00 +0800 CST 0001-01-01 00:00:00 +0000 UTC}]]

《递龟》

上面的代码中，我们第一次用到了递龟递归：自己调用自己。

5. 合法合规：遵守 robots.txt 规范

我选择用temoto/robotstxt这个库来探查我们的爬虫是否被允许爬取某个 URL，使用一张单独的表来存储每个域名的 robots 规则，并在 Redis 中建立缓存，每次爬取 URL 之前，先进行一次匹配，匹配成功后再爬，保证合法合规。

制造真正的生产级爬虫

《怎样画马》

有了前面这个理论上可以运行的简单爬虫，下面我们就要给这匹马补充亿点细节了：生产环境中，爬虫性能优化是最重要的工作。

从某种程度上来说，搜索引擎的优劣并不取决于搜索算法的优劣，因为算法作为一种“特定问题的简便算法”，一家商业公司比别家强的程度很有限，搜索引擎的真正优劣在于哪家能够以最快的速度索引到互联网上层出不穷的新页面和已经更新过内容的旧页面，在于哪家能够识别哪个网页是价值最高的网页。

识别网页价值方面，李彦宏起家的搜索专利，以及谷歌大名鼎鼎的 PageRank 都拥有异曲同工之妙。但本文的重点不在这个领域，而在于技术实现。让我们回到爬虫性能优化，为什么性能优化如此重要呢？我们构建的是互联网搜索引擎，需要爬海量的数据，因此我们的爬虫需要足够高效：中文互联网有 400 万个网站，3500 亿个网页，哪怕只爬千分之一，3.5 亿个网页也不是开玩笑的，如果只是单线程阻塞地爬，消耗的时间恐怕要以年为单位了。

爬虫性能优化，我们首先需要规划一下硬件。

硬件要求

首先计算磁盘空间，假设一个页面 20KB，在不进行压缩的情况下，一亿个页面就需要 20 * 100000000 / 1024 / 1024 / 1024 = 1.86TB 的磁盘空间，而我们打算使用 MySQL 来存储页面文本，需要的空间会更大一点。

我的爬虫花费了 2 个月的时间，爬到了大约 1 亿个 URL，其中 3600 万个爬到了页面的 HTML 文本存在了数据库里，共消耗了超过 600GB 的磁盘空间。

除了硬性的磁盘空间，剩下的就是尽量多的 CPU 核心数和内存了：CPU 拿来并发爬网页，内存拿来支撑海量协程的消耗，外加用 Redis 为爬虫提速。爬虫阶段对内存的要求还不大，但在后面第二步拆分字典的时候，大内存容量的 Redis 将成为提速利器。

所以，我们对硬件的需求是这样的：一台核心数尽量多的物理机拿来跑我们的 ese 二进制程序，外加高性能数据库（例如16核64GB内存，NVME磁盘），你能搞到多少台数据库就准备多少台，就算你搞到了 65536 台数据库，也能跑满，理论上我们可以无限分库分表。能这么搞是因为网页数据具有离散性，相互之间的关系在爬虫和字典阶段还不存在，在查询阶段才比较重要。

顺着这个思路，有人可能就会想，我用 KV 数据库例如 MongoDB 来存怎么样呢？当然是很好的，但是MongoDB 不适合干的事情实在是太多啦，所以你依然需要 Redis 和 MySQL 的支持，如果你需要爬取更大规模的网页，可以把 MongoDB 用起来，利用进一步推高系统复杂度的方式获得一个显著的性能提升。

下面我们开始进行软件优化，我只讲述关键步骤，各位有什么不明白的地方可以参考项目代码。

重用 HTTP 客户端以防止内存泄露

这个点看起来很小，但当你瞬间并发数十万协程的时候，每个协程 1MB 的内存浪费累积起来都是巨大的，很容易造成 OOM。

我们在 tools 文件夹下创建curl.go工具类，专门用来存放全局 client 和 curl 工具函数：

package toolsimport ... //省略，具体可以参考项目代码// 全局重用 client 对象，4 秒超时，不跟随 301 302 跳转var client = req.C().SetTimeout(time.Second * 4).SetRedirectPolicy(req.NoRedirectPolicy())// 返回 document 对象和状态码func Curl(page models.Page, ch chan int) (*goquery.Document, int) {  ... //省略，具体可以参考项目代码}

基础知识储备：goroutine 协程

我默认你已经了解 go 协程是什么了，它就是一个看起来像魔法的东西。在这里我提供一个理解协程的小诀窍：每个协程在进入磁盘、网络等“只需要后台等待”的任务之后，会把当前 CPU 核心(可以理解成一个图灵机)的指令指针 goto 到下一个协程的起始。

需要注意的是，协程是一种特殊的并发形式，你在并发函数内调用的函数必须都支持并发调用，类似于传统的“线程安全”，如果你一不小心写了不安全的代码，轻则卡顿，重则 crash。

一次取出一批需要爬的 URL，使用协程并发爬

协程代码实操来啦！

// tools.DD(pagesArray) // 打印结果// 创建 channel 数组chs := make([]chan int, len(pagesArray))// 展开 pagesArray 数组for k, v := range pagesArray {// 存储 channel 指针chs[k] = make(chan int)// 阿瓦达啃大瓜！！go craw(v, chs[k], k)}// 注意，下面的代码不可省略，否则你上面 go 出来的那些协程会瞬间退出var results = make(map[int]int)for _, ch := range chs {// 神之一手，收集来自协程的返回数据，并 hold 主线程不瞬间退出r := <-ch_, prs := results[r]if prs {  results[r] += 1} else {  results[r] = 1}}// 当代码执行到这里的时候，说明所有的协程都已经返回数据了fmt.Println("跑完一轮", time.Now().Unix()-startTime.Unix(), "秒")

craw函数协程化：

 // 真的爬，存储标题，内容，以及子链接func craw(status models.Page, ch chan int, index int) {  // 调用 CURL 工具类爬到网页  doc, chVal := tools.Curl(status, ch)  // 对 doc 的处理在这里省略  // 最重要的一步，向 chennel 发送 int 值，该动作是协程结束的标志  ch <- chVal  return}

协程优化做完了，CPU 被吃满了，接下来数据库要成为瓶颈了。

MySQL 性能优化

做到这里，在做普通业务逻辑的时候非常快的 MySQL 已经是整个系统中最慢的一环了：pages 表一天就要增加几百万行，MySQL 会以肉眼可见的速度慢下来。我们要对 MySQL 做性能优化。

何以解忧，唯有索引

首先，收益最大的肯定是加索引，这句话适用于 99% 的场景。

在你磁盘容量够用的情况下，加索引通常可以获得数百倍到数万倍的性能提升。我们先给 url 加个索引，因为我们每爬到一个 URL 都要查一下它是否已经在表里面存在了，这个动作的频率是非常高的，如果我们最终爬到了一亿个页面，那这个对比动作至少会做百亿次。

部分场景下很好用的分库分表

非常幸运，爬虫场景和分库分表非常契合：只要我们能根据 URL 将数据均匀地分散开，不同的 URL 之间是没有多少关系的。那我们该怎么将数据分散开呢？使用散列值！

每一个 URL 在 MD5 之后，都会得到一个形如698d51a19d8a121ce581499d7b701668的 32 位长度的 16 进制数。而这些数字在概率上是均等的，所以理论上我们可以将数亿个 URL 均匀分布在多个库的多个表里。下面问题来了，该怎么分呢？

只有一台数据库，应该分表吗？

如果你看过我的《高并发的哲学原理（八）-- 将 InnoDB 剥的一丝不挂：B+ 树与 Buffer Pool 》的话，就会明白，只要你能接受分表的逻辑代价，那在任何大数据量场景下分表都是有明显收益的，因为随着表容量的增加，那棵 16KB 页块组成的 B+ 树的复杂度增加是超线性的，用牛逼的话说就是：二阶导数持续大于 0。此外，缓存也会失效，你的 MySQL 运行速度会降低到一个令人发指的水平。

所以，即便你只有一台数据库，那也应该分表。如果你的磁盘是 NVME，我觉得单机拿出 MD5 的前两位数字，分出来 16 x 16 = 256 个表是比较不错的。

当然，如果你能搞到 16 台数据库服务器，那拿出第一位 16 进制数字选定物理服务器，再用二三位数字给每台机器分 256 个表也是极好的。

我的真实硬件和分表逻辑

由于我司比较节俭贫穷，机房的服务器都是二手的，实在是拿不出高性能的 NVME 服务器，于是我找 IT 借了两台 ThinkBook 14 寸笔记本装上了 CentOS Stream 9：

把内存扩充到最大，形成了 8GB 板载 + 32GB 内存条一共 40GB 的奇葩配置
CPU 是 AMD Ryzen 5 5600U，虽然是低压版的 CPU，只有六核十二线程，但是也比 Intel 的渣渣 CPU 快多了（Intel：牙膏真的挤完了，一滴都没有了）
磁盘就用自带的 500GB NVME，实测读写速度能跑到 3GB/2GB，十分够用

由于单台机器只有 6 核，我就各给他们分了 128 个表，在每次要执行 SQL 之前，我会先用 URL 作为参数获取一下它对应的数据库服务器和表名。表名获取逻辑如下：

计算此 URL 的 MD5 散列值
取前两位十六进制数字
拼接成类似pages_0f样子的表名
tableName := table + "_" + tools.GetMD5Hash(url)[0:2]

爬虫数据流和架构优化

上面我们已经使用协程把 CPU 全部利用起来了，又使用分库分表技术把数据库硬件全部利用起来了，但是如果你这个时候直接用上面的代码开始跑，会发现速度还是不够快：因为某些工作 MySQL 还是不擅长做。

此时，我们就需要对数据流和架构做出优化了。

拆分仓库表和状态表

原始的 pages 表有 16 个字段，在我们爬的过程中，只用得到五个：id url host craw_done craw_time。而看过我上面的 InnoDB 文章的小伙伴还知道，在页面 HTML 被填充进text字段之后，pages 表的 16KB 页块会出现频繁的调整和指针的乱飞，对 InnoDB 的“局部性”性能涡轮的施展非常不利，会造成 buffer pool 的频繁失效。

所以，为了爬的更快，为 pages 表打造一个性能更强的“影子”就十分重要。于是，我为pages_0f表打造了只包含上面五个字段的status_0f兄弟表，数据从 pages 表里面复制而来，承担一些频繁读写任务：

检查 URL 是否已经在库，即如果以前别的页面上已经出现了这个 URL 了，本次就不需要再入库了
找出下一批需要爬的页面，即craw_done=0的 URL
craw_time 承担日志的作用，用于统计过去一段时间的爬虫效率

除了这些高频操作，存储页面 HTML 和标题等信息的低频操作是可以直接入paqes_0f仓库表的。

实时读取 URL 改为后台定时读取

随着单表数据量的逐渐提升，每一轮开始时从数据库里面批量读出需要爬的 URL 成了一个相对耗时的操作，即便每张表只需要 500ms，那轮询 256 张表总耗时也达到了 128 秒之多，这是无法接受的，所以这个流程也需要异步化。你问为什么不异步同时读取 256 张表？因为 MySQL 最宝贵的就是连接数，这样会让连接数直接爆掉，大家都别玩了，关于连接数我们下面还会有提及。

我们把流程调整一下：每 20 秒从 status 表中搜罗一批需要爬的 URL 放进 Redis 中积累起来，爬的时候直接从 Redis 中读一批。这么做是为了把每一秒的时间都利用起来，尽力填满协程爬虫的胃口。

// 在 main() 中注册定时任务c := cron.New(cron.WithSeconds())// 每 20 秒执行一次 prepareStatusesBackground 函数c.AddFunc("*/20 * * * * *", prepareStatusesBackground)go c.Start()// prepareStatusesBackground 函数中，使用 LPush 向有序列表的头部插入 URLfor _, v := range _statusArray {  taskBytes, _ := json.Marshal(v)  db.Rdb.LPush(db.Ctx, "need_craw_list", taskBytes)}// 每一轮都使用 RPop 从有序列表的尾部读取需要爬的 URLvar statusArr []models.StatusmaxNumber := 1 // 放大倍数，控制每一批的 URL 数量for i := 0; i < 256*maxNumber; i++ {  jsonString := db.Rdb.RPop(db.Ctx, "need_craw_list").Val()  var _status models.Status  err := json.Unmarshal([]byte(jsonString), &_status)  if err != nil {    continue  }  statusArr = append(statusArr, _status)}

十分重要的爬虫压力管控

过去十年，中国互联网每次有搜索引擎新秀崛起，我都要被新爬虫 DDOS 一遍，想想就气。这帮大厂的菜鸟程序员，以为随便一个网站都能承受住 2000 QPS，实际上互联网上 99.9% 网站的极限 QPS 到不了 100，超过 10 都够呛。对了，如果有 YisouSpider 的人看到本文，请回去推动一下你们的爬虫优化，虽然你们的爬虫不会持续高速爬取，但是你们在每分钟的第一秒并发 10 个请求的方法更像是 DDOS，对系统的危害更大...

我们要像谷歌那样，做一个压力均匀的文明爬虫，这就需要我们把每一个域名的爬虫频率都记录下来，并实时进行调整。我基于 Redis 和每个 URL 的 host 做了一个计数器，在每次真的要爬某个 URL 之前，调用一次检测函数，看是否对单个域名的爬虫压力过大。

此外，由于我们的 craw 函数是协程调用的，此时 Redis 就显得更为重要了：它能提供宝贵的“线程安全数据读写”功能，如果你也是sync.Map的受害者，我相信你一定懂我。

我认为，单线程的 Redis 是 go 协程最佳的伙伴，就像 PHP 和 MySQL 那样。

具体代码我就不放了，有需要的同学可以自己去看项目代码哦。

疯狂使用 Redis 加速频繁重复的数据库调用

我们使用协程高速爬到数据了，下一步就是存储这些数据。这个操作看起来很简单，更新一下原来那一行，再插入 N 行新数据不就行了吗，其实不行，还有一个关键步骤需要使用 Redis 来加速：新爬到的 URL 是否已经在数据库里存在了。这个操作看起来简单，但在我们解决了上面这些性能问题以后，庞大的数量就成了这一步最大的问题，每一次查询会越来越慢，查询字数还特别多，这谁顶得住。

如果我们拿 Redis 来存 URL，岂不是需要把所有 URL 都存入 Redis 吗，这内存需求也太大了。这个时候，我们的老朋友，局部性又出现了：由于我们的爬虫是按照顺序爬的，那“朋友的朋友也是朋友”的概率是很大的，所以我们只要在 Redis 里记录一下某条 URL 是否存在，那之后一段时间，这个信息被查到的概率也很大：

// 我们使用一个 Hash 来存储 URL 是否存在的状态statusHashMapKey := "ese_spider_status_exist"statusExist := db.Rdb.HExists(db.Ctx, statusHashMapKey, _url).Val()// 若 HashMap 中不存在，则查询或插入数据库if !statusExist {  ··· 代码省略，不存在则创建这行 page，存在则更新信息 ···  // 无论是否新插入了数据，都将 _url 入 HashMap  db.Rdb.HSet(db.Ctx, statusHashMapKey, _url, 1).Err()}

这段代码看似简单，实测非常好用，唯一的问题就是不能运行太长时间，隔一段时间得清空一次，因为随着时间的流逝，局部性会越来越差。

细心的小伙伴可能已经发现了，既然爬取状态已经用 Redis 来承载了，那还需要区分 pages 和 status 表吗？需要，因为 Redis 也不是全能的，它的基础数据依然是来自 MySQL 的。目前这个架构类似于复杂的三级火箭，看起来提升没那么大，但这小小的提速可能就能让你爬三亿个网页的时间从 3 个月缩减到 1 个月，是非常值的。

另外，如果通过扫描 256 张表中 craw_time 字段的方式来统计“过去 N 分钟爬了多少个 URL、有效页面多少个、因为爬虫压力而略过的页面多少个、网络错误的多少个、多次网络错误后不再重复爬取的多少个”的数据，还是太慢了，也太消耗资源了，这些统计信息也需要使用 Redis 来记录：

// 过去一分钟爬到了多少个页面的 HTMLallStatusKey := "ese_spider_all_status_in_minute_" + strconv.Itoa(int(time.Now().Unix())/60)// 计数器加 1db.Rdb.IncrBy(db.Ctx, allStatusKey, 1).Err()// 续命 1 小时db.Rdb.Expire(db.Ctx, allStatusKey, time.Hour).Err()// 过去一分钟从新爬到的 HTML 里面提取出了多少个新的待爬 URLnewStatusKey := "ese_spider_new_status_in_minute_" + strconv.Itoa(int(time.Now().Unix())/60)// 计数器加 1db.Rdb.IncrBy(db.Ctx, newStatusKey, 1).Err()// 续命 1 小时db.Rdb.Expire(db.Ctx, newStatusKey, time.Hour).Err()

生产爬虫遇到的其他问题

在我们不断提高爬虫速度的过程中，爬虫的复杂度也在持续上升，我们会遇到玩具爬虫遇不到的很多问题，接下来我分享一下我的处理经验。

抑制暴增的数据库连接数

在协程这个大杀器的协助之下，我们可以轻易写出超高并行的代码，把 CPU 全部吃完，但是，并行的协程多了以后，数据库的连接数压力也开始暴增。MySQL 默认的最大连接数只有 151，根据我的实际体验，哪怕是一个协程一个连接，我们这个爬虫也可以轻易把连接数干到数万，这个数字太大了，即便是最新的 CPU 加上 DDR5 内存，受制于 MySQL 算法的限制，在连接数达到这个级别以后，处理海量连接数所需要的时间也越来越多。这个情况和《高并发的哲学原理（二）-- Apache 的性能瓶颈与 Nginx 的性能优势》一文中描述的 Apache 的 prefork 模式比较像。好消息是，最近版本的 MySQL 8 针对连接数匹配算法做了优化，大幅提升了大量连接数下的性能。

除了协程之外，分库分表对连接数的的暴增也负有不可推卸的责任。为了提升单条 SQL 的性能，我们给单台数据库服务器分了 256 张表，这种情况下，以前的一个连接+一条 SQL 的状态会突然增加到 256 个连接和 256 条 SQL，如果我们不加以限制的话，可以说协程+分表一启动，你就一定会收到海量的Too many connections报错。我的解决方法是，在 gorm 初始化的时候，给他设定一个“单线程最大连接数”：

dbdb0, _ := _db0.DB()dbdb0.SetMaxIdleConns(1)dbdb0.SetMaxOpenConns(100)dbdb0.SetConnMaxLifetime(time.Hour)

根据我的经验，100 个够用了，再大的话，你的 TCP 端口就要不够用了。

域名黑名单

我们都知道，内容农场是一种专门钻搜索引擎空子的垃圾内容生产者，爬虫很难判断哪些网站是内容农场，但是人一点进去就能判断出来。而这些域名的内部链接做的又特别好，这就导致我们需要手动给一些恶心的内容农场域名加黑名单。我们把爬到的每个域名下的 URL 数量统计一下，搞一个动态的排名，就能很容易发现头部的内容农场域名了。

复杂的失败处理策略

生产代码和教学代码最大的区别就是成吨的错误处理！—— John·Lui（作者自己）

如果你真的要搞一个涵盖数亿页面的可以用的搜索引擎，你会碰到各种各样的奇葩失败，这些失败都需要拿出特别的处理策略，下面我分享一下我遇到过的问题和我的处理策略。

单页面超时非常重要：如果你想尽可能地在一段时间内爬到尽量多的页面的话，缩短你 curl 的超时时间非常重要，经过摸索，我把这个时间设定到了 4 秒，既能爬到绝大多数网页，也不会浪费时间在一些根本就无法响应的 URL 上。
单个 URL 错误达到一定数量以后，需要直接拉黑，不然一段时间后，你的爬虫整天就只爬那些被无数次爬取失败的 URL 上啦，一个新页面也爬不到。这个次数我设定的是 3 次。
如果某个 URL 返回的 HTML 无法被解析，果断放弃，没必要花费额外资源重新爬。
由于我们的数据流已经是三级火箭形态，所以在各种地方加上“动态锁”就很必要，因为很多时候我们需要手动让其他级火箭发动机暂停运行，手动检修某一级发动机。我一般拿 MySQL 来做这件事，创建一个名为kvstores的表，只有 key value 两个字段，需要的时候我会手动修改特定 key 对应的 value 值，让某一级发动机暂停一下。
由于 curl 的结果具有不确定性，务必需要保证任何情况下，都要给 channel 返回信号量，不然你的整个应用会直接卡死。
一个页面内经常会有同一个超链接重复出现，在内存里保存已经见过的 URL 并跳过重复值可以显著节约时间。
我建了一个 MySQL 表来存储我手动插入的黑名单域名，这个非常好用，可以在爬虫持续运行的时候随时“止损”，停止对黑名单域名的新增爬取。

至此，我们的爬虫终于构建完成了。

爬虫运行架构图

现在我们的爬虫运行架构图应该是下面这样的：

爬虫搞完了，让我们进入第二大部分。

第二步，使用倒排索引生成字典

那个男人一听就很牛逼的词出现了：倒排索引。

对于没搞过倒排索引的人来说，这个词听起来和“生态化反”一样牛逼，其实它非常简单，简单程度堪比 HTTP 协议。

倒排索引到底是什么

下面这个例子可以解释倒排索引是个什么东西：

我们有一个表 titles，含有两个字段，ID 和 text，假设这个表有 100 行数据，其中第一行 text 为“爬虫工作流程”，第二行为“制造真正的生产级爬虫”
我们对这两行文本进行分词，第一行可以得到“爬虫”、“工作”、“流程”三个词，第二行可以得到“制造”、“真正的”、“生产级”、“爬虫”四个词
我们把顺序颠倒过来，以词为 key，以①titles.id ②, ③这个词在 text 中的位置 这三个元素拼接在一起为一个值，不同 text 生成的值之间以 - 作为间隔，对数据进行“反向索引”，可以得到：
1. 爬虫: 1,0-2,8
2. 工作：1,2
3. 流程：1,4
4. 制造：2,0
5. 真正的：2,2
6. 生产级：2,5

倒排索引完成了！就是这么简单。说白了，就是把所有内容都分词出来，再反向给每个词标记出“他出现在哪个文本的哪个位置”，没了，就是这么简单。下面是我生成的字典中，“辰玺”这个词的字典值：

110,85,1,195653,7101-66,111,1,195653,7101-

你问为什么我不找个常见的词？因为随便一个常见的词，它的字典长度都是以 MB 为单位的，根本没法放出来...

还有一个牛逼的词，最小完美哈希，可以用来排布字典数据，加快搜索速度，感兴趣的同学可以自行学习

生成倒排索引数据

理解了倒排索引是什么以后，我们就可以着手把我们爬到的 HTML 处理成倒排索引了。

我使用yanyiwu/gojieba这个库来调用结巴分词，按照以下步骤对我爬到的每一个 HTML 文本进行分词并归类：

分词，然后循环处理这些词：
统计词频：这个词在该 HTML 中出现的次数
记录下这个词在该 HTML 中每一次出现的位置，从 0 开始算
计算该 HTML 的总长度，搜索算法需要
按照一定格式，组装成倒排索引值，形式如下：
// 分表的顺序，例如 0f 转为十进制为 15 strconv.Itoa(i) + "," + // pages.id 该 URL 的主键 ID strconv.Itoa(int(pages.ID)) + "," + // 词频：这个词在该 HTML 中出现的次数 strconv.Itoa(v.count) + "," + // 该 HTML 的总长度，BM25 算法需要 strconv.Itoa(textLength) + "," + // 这个词出现的每一个位置，用逗号隔开，可能有多个 strings.Join(v.positions, ",") + // 不同 page 之间的间隔符 "-"

我们按照这个规则，把所有的 HTML 进行倒排索引，并且把生成的索引值拼接在一起，存入 MySQL 即可。

使用协程 + Redis 大幅提升词典生成速度

不知道大家感受到了没有，词典的生成是一个比爬虫高几个数量级的 CPU 消耗大户，一个 HTML 动辄几千个词，如果你要对数亿个 HTML 进行倒排索引，需要的计算量是非常惊人的。我爬到了 3600 万个页面，但是只处理了不到 800 万个页面的倒排索引，因为我的计算资源也有限...

并且，把词典的内容存到 MySQL 里难度也很大，因为一些常见词的倒排索引会巨长，例如“没有”这个词，真的是到处都有它。那该怎么做性能优化呢？还是我们的老朋友，协程和 Redis。

协程分词

两个 HTML 的分词工作之间完全没有交集，非常适合拿协程来跑。

但是，MySQL 举手了：我顶不住。所以协程的好朋友 Redis 也来了。

使用 Redis 做为词典数据的中转站

我们在 Redis 中针对每一个词生成一个 List，把倒排出来的索引插入到尾部：

db.Rdb10.RPush(db.Ctx, word, appendSrting)

使用协程从 Redis 搬运数据到 MySQL 中

你没看错，这个地方也需要使用协程，因为数据量实在是太大了，一个线程循环跑会非常慢。经过我的不断尝试，我发现每次转移 2000 个词，对 Redis 的负载比较能够接受，E5-V4 的 CPU 单核能够跑满，带宽大概 400Mbps。

从 Redis 到 MySQL 的高性能搬运方法如下：

随机获取一个 key
判断该 key 的长度，只有大于等于 2 的进入下一步
把最后一个索引值留下，前面的元素一个一个LPop（弹出头部）出来，拼接在一起
汇集一批 2000 个随机词的结果，append 到数据库该词现有索引值的后面

有了协程和 Redis 的协助，分词加倒排索引的速度快了起来，但是如果你选择一个词一个词地 append 值，你会发现 MySQL 又双叒叕变的超慢，又要优化 MySQL 了！

事务的妙用：MySQL 高速批量插入

由于需要往磁盘里写东西，所以只要是一个一个 update，怎么优化都会很慢，那有没有一次性 update 多行数据的方法呢？有！那就是事务：

tx.Exec(`START TRANSACTION`)// 需要批量执行的 update 语句for w, s := range needUpdate {  tx.Exec(`UPDATE word_dics SET positions = concat(ifnull(positions,''), ?) where name = ?`, s, w)}tx.Exec(`COMMIT`)

这么操作，字典写入速度一下子起来了。但是，每次执行 2000 条 update 语句对磁盘的要求非常高，我进行这个操作的时候，可以把磁盘写入速度瞬间提升到 1.5GB/S，如果你的数据库存储不够快，可以减少语句数量。

世界的参差：无意义的词

这个世界上的东西并不都是有用的，一个 HTML 中的字符也是如此。

首先，一般不建议索引整个 HTML，而是把他用 DOM 库处理一下，提取出文本内容，再进行索引。

其次，即便是你已经过滤掉了所有的 html 标签、css、js 代码等，还是有些词频繁地出现：它们出现的频率如此的高，以至于反而失去了作为搜索词的价值。这个时候，我们就需要把他们狠狠地拉黑，不处理他们的倒排索引。我使用的黑名单词如下，表名为word_black_list，只有两个字段 id、word，需要的自取：

INSERT INTO `word_black_list` (`id`, `word`)VALUES    (1, 'px'),    (2, '20'),    (3, '('),    (4, ')'),    (5, ','),    (6, '.'),    (7, '-'),    (8, '/'),    (9, ':'),    (10, 'var'),    (11, '的'),    (12, 'com'),    (13, ';'),    (14, '['),    (15, ']'),    (16, '{'),    (17, '}'),    (18, '\''),    (19, '\"'),    (20, '_'),    (21, '?'),    (22, 'function'),    (23, 'document'),    (24, '|'),    (25, '='),    (26, 'html'),    (27, '内容'),    (28, '0'),    (29, '1'),    (30, '3'),    (31, 'https'),    (32, 'http'),    (33, '2'),    (34, '!'),    (35, 'window'),    (36, 'if'),    (37, '“'),    (38, '”'),    (39, '。'),    (40, 'src'),    (41, '中'),    (42, '了'),    (43, '6'),    (44, '｡'),    (45, '<'),    (46, '>'),    (47, '联系'),    (48, '号'),    (49, 'getElementsByTagName'),    (50, '5'),    (51, '､'),    (52, 'script'),    (53, 'js');

至此，字典的处理告一段落，下面让我们一起 Just 搜 it!

第三步，使用 BM25 算法给出搜索结果

网上关于 BM25 算法的文章是不是看起来都有点懵？别担心，看完下面这段文字，我保证你能自己写出来这个算法的具体实现，这种有具体文档的工作是最好做的了，比前面的性能优化简单多了。

简单介绍一下 BM25 算法

BM25 算法是现代搜索引擎的基础，它可以很好地反映一个词和一堆文本的相关性。它拥有不少独特的设计思想，我们下面会详细解释。

这个算法第一次被生产系统使用是在 1980 年代的伦敦城市大学，在一个名为 Okapi 的信息检索系统中被实现出来，而原型算法来自 1970 年代 Stephen E. Robertson、Karen Spärck Jones 和他们的同伴开发的概率检索框架。所以这个算法也叫 Okapi BM25，这里的 BM 代表的是best matching（最佳匹配），非常实在，和比亚迪的“美梦成真”有的一拼（Build Your Dreams）

详细讲解 BM25 算法数学表达式的含义

我简单描述一下这个算法的含义。

首先，假设我们有 100 个页面，并且已经对他们分词，并全部生成了倒排索引。此时，我们需要搜索这句话“BM25 算法的数学描述”，我们就需要按照以下步骤来计算：

对“BM25 算法的数学描述”进行分词，得到“BM25”、“算法”、“的”、“数学”、“描述”五个词
拿出这五个词的全部字典信息，假设包含这五个词的页面一共有 50 个
逐个计算这五个词和这 50 个页面的相关性权重和相关性得分的乘积（当然，不是每个词都出现在了这 50 个网页中，有多少算多少）
把这 50 页面的分数分别求和，再倒序排列，即可以获得“BM25 算法的数学描述”这句话在这 100 个页面中的搜索结果

相关性权重和相关性得分名字相似，别搞混了，它们的具体定义如下：

某个词和包含它的某个页面的“相关性权重”

上图中的Wi指代的就是相关性权重，最常用的是TF-IDF算法中的IDF权重计算法：

这里的 N 指的是页面总数，就是你已经加入字典的页面数量，需要动态扫描 MySQL 字典，对我来说就是 784 万。而n(Qi)就是这个词的字典长度，就是含有这个词的页面有多少个，就是我们字典值中-出现的次数。

这个参数的现实意义是：如果一个词在很多页面里面都出现了，那说明这个词不重要，例如百分百空手接白刃的“的”字，哪个页面都有，说明这个词不准确，进而它就不重要。

词以稀为贵。

我的代码实现如下：

// 页面总数db.DbInstance0.Raw("select count(*) from pages_0f where dic_done = 1").Scan(&N)N *= 256// 字典的值中`-`出现的次数NQi := len(partsArr)// 得出相关性权重IDF := math.Log10((float64(N-NQi) + 0.5) / (float64(NQi) + 0.5))

某个词和包含它的某个页面的“相关性得分”

这个表达式看起来是不是很复杂，但是它的复杂度是为了处理查询语句里面某一个关键词出现了多次的情况，例如“八百标兵奔北坡，炮兵并排北边跑。炮兵怕把标兵碰，标兵怕碰炮兵炮。”，“炮兵”这个词出现了 3 次。为了能快速实现一个能用的搜索引擎，我们放弃支持这种情况，然后这个看起来就刺激的表达式就可以简化成下面这种形式：

需要注意的是，这里面的大写的 K 依然是上面那个略微复杂的样式。我们取 k1 为 2，b 为 0.75，页面（文档）平均长度我自己跑了一个，13214，你们可以用我这个数，也可以自己跑一个用。

我的代码实现如下：

// 使用 - 切分后的值，为此页面的字典值，形式为：// 110,85,1,195653,7101ints := strings.Split(p, ",")// 这个词在这个页面中出现总次数Fi, err := strconv.Atoi(ints[2])// 这个页面的长度Dj, _ := strconv.Atoi(ints[3])k1 := 2.0b := 0.75// 页面平均长度avgDocLength := 13214.0// 得到相关性得分RQiDj := (float64(Fi) * (k1 + 1)) / (float64(Fi) + k1*(1-b+b*(float64(Dj)/avgDocLength)))

怎么样，是不是比你想象的简单？

检验搜索结果

我在我搞的“翰哥搜索”页面上搜了一下“BM25 算法的数学描述”，结果如下：

我搜索“住范儿”，结果如下：

第一个就是我们官网，可以说相当精准了。

看起来效果还不错，要知道这只是在 784 万的网页中搜索的结果哦，如果你有足够的服务器资源，能搞定三亿个页面的爬取、索引和查询的话，效果肯定更加的好。

如何继续提升搜索准确性？

目前我们的简化版 BM25 算法的搜索结果已经达到能用的水平了，还能继续提升搜索准确性吗？还可以：

本文全部是基于分词做的字典，你可以再做一份基于单字的，然后把单字的搜索结果排序和分词的搜索结果进行结合，搜索结果可以更准。
相似的原理，打造更加合理、更加丰富的分词方式，构造不同倾向的词典，可以提升特定领域的搜索结果表现，例如医学领域、代码领域等。
打造你自己的 PageRank 技术，从 URL 之间关系的角度，给单个 URL 的价值进行打分，并将这个价值分数放进搜索结果的排序参数之中。
引入 proximity 相似性计算，不仅考虑精确匹配的关键词，还要考虑到含义相近的关键词的搜索结果。
特殊查询的处理：修正用户可能的输入错误，处理中文独特的“拼音匹配”需求等。

参考资料

【NLP】非监督文本匹配算法——BM25 https://zhuanlan.zhihu.com/p/499906089
《自制搜索引擎》—— [日]山田浩之、末永匡

【全文完】

相关日志：

JohnLui — Sat, 11 Feb 2023 07:35:57 +0000

《高并发的哲学原理 Philosophical Principles of High Concurrency》开源图书已经发布，简称 PPHC。地址：https://github.com/johnlui/PPHC

前面两篇文章每一篇都花了我五十个小时以上，写的我是欲仙欲死，本文我们来务点虚，上上价值。

我们将从微服务架构讲起，一步一步追根溯源，找寻“分布式数据库”在另一个维度的投影，探寻基建、应用、服务、组织之间的联系，通过观察自然规律和人类社会，引出本文的中心思想，并对“找出单点，进行拆分”做出最后的升华。

最后，我们将得到一个可行的 100 万 API QPS、500 万数据库 QPS 的系统设计方案，并顺便简单地讨论一下“高可用”背后的哲学悖论。

如何定义“一个系统”

前面第七篇文章我们说过：

如果两个系统的数据库不在一起，那他们就不是一个系统，就像拼多多有 7.5 亿月活用户，淘宝有 8.5 亿，你不能说“拼宝宝”电商系统有 16 亿月活用户一样。

如果两个 API 的数据落到同一张表上，那他们两个就属于同一个系统。

那，在一个电商系统内，用户 API 和商品 API 似乎没有多对多交集？是的，这就是微服务架构的拆分逻辑。

微服务架构

我们都知道，微服务的拆分方式，反映的是其背后技术团队的组织方式。（你不知道也没关系，你现在知道了(￣▽￣)" ）

那，技术团队的组织方式是什么决定的呢？

是由系统内各部分天然的内聚性决定的：用户相关的业务和商品相关的业务都有很强的内聚性，他们之间不会主动发生关联，但他们会分别和订单发生关联。

数据库调用推演

我们用商品下单处理流程来推演一个电商订单的生命周期内对用户、商品、订单三个部分数据库的读写情况。

搜索：商品数据库-读
点进详情：商品数据库-读，用户数据库-读（地址、会员）
立即购买：商品数据库-读，用户数据库-读，订单数据库-写
支付：订单数据库-读写，用户数据库-读
商家后台查看并处理订单：订单数据库-读写，用户数据库-读，商品数据库-读

我们可以看出，大部分情况下，每一步都只有一个主要的微服务被需要，其它微服务都处于辅助地位：只读，且大部分都是单点读取。这就为我们降低了数据库单点的负载——只要把这三个微服务部署到三个独立的数据库上，就可以通过 API 调用的形式降低单个数据库的极限 QPS。

微服务背后的哲学

既然我们不能把拼多多和淘宝的系统称作一个系统，那么，在拼多多和淘宝系统内，肯定还可以基于类似的逻辑继续拆分：

在大量调用的 API 中，一次携带了数据写入的请求一定只会对单个微服务进行写入，但会对多个微服务进行数据读取
如果某个头部 API 请求会对两个微服务系统进行写入，那说明微服务的划分出了问题，需要调整系统结构划分

把几乎不相互写入的数据拆到两个数据库上，这种组织形态在人类社会随处可见：两个国家的人分别在自己国家申请护照，他们有时也可以到对方国家内的本国领事馆申领本国护照；两个村的人各自在本村的井里打水，有时也可以不怕麻烦地去隔壁村的水井里打水；你每天早上都用滴滴打车上班，万一滴滴打不到车你还可以用高德来补救...

微服务照进现实

微服务的拆分思想相信大家都理解了，下面我们来解决现实问题。

如果你真的成为了“设计百万 QPS 系统”的架构师，相信我，你第一个想到的，一定是“削峰”。

削峰

顾名思义，将突发的流量高峰削平。大促的时候，系统顶不住，其实就是那么一会儿顶不住，只要初期的高热度下去了，系统的整体负载会迅速下降到没那么危险的水平。所以，对付突发流量，削峰是第一要务。

1. 缓存——饮鸩止渴

请原谅我用饮鸩止渴这个词形容 95% 的 web 系统的真正性能顶梁柱，实际上缓存的贡献远不止于此。

缓存以降低数据更新频率为代价，极大地提升了读取 API 的 QPS 极限
缓存可以设计成多级，形成一个逻辑上的“存储器山”
缓存可以像事务隔离级别一样划分成好几种性能+数据一致性级别

但是，使用缓存确实是在饮鸩止渴：缓存在带来性能的同时，大幅削弱了数据库提供的“单点性”，为系统失效埋下了一堆地雷。

缓存的毒性无法消除，一旦系统的某些部分失效，这杯毒酒就会发作，但是会不会把自己毒死还要看架构水平和基建能力：你的机房别随便断电，你的服务器别随便宕机，你在喝下缓存毒酒之后，就能活的够长。

终极缓存方案

我们上一篇文章讨论的 OceanBase 就采用了一种终极缓存方案：

内存不是快吗，那我就把所有热数据全部放到内存里
那对热数据的修改怎么办？redo log 落盘啊
你说数据库重启怎么办？上冗余，一个节点一时半会儿起不来也没问题
整个集群重启呢？都天灾了，集群重启后，停止服务一个小时还是可以接受的吧

12306 每天夜里都要维护一个小时，我有理由怀疑，它在将 redo log 落盘¹ :-D

2. 队列——欢迎来到地球

缓存可以削读的峰，队列就是拿来削写的峰的。

队列的思想其实早就贯穿在人类社会的每一个角落了：超市结账需要排队，做核酸需要排队，火车站打车需要排队，网上抢购商品也需要排队。排队的本质是将一拥而上购买变成了“异步”购买：你想买东西？先排队，过段时间轮到你了，看看商品有没有卖完，没卖完你就能买到。

排队的思维特别好理解，而现实中防止超售功能也确实是基于排队功能做的。传统数据库的事务隔离属于强迫用户等待，而现在大多使用队列系统来处理排队，排队这件事情才真正异步起来了。

3. 奇技淫巧

电商下单在普通压力下，一个队列就能解决问题，但是当你面临每秒几十万单的时候，如何让这些订单真正地下单成功，才是最需要解决的问题，这个数字就是“系统容量”。队列是无法提升系统的绝对容量的，那该怎么办呢？

继续找东西和信息之神交换：过去的时间换现在的时间。

在大促之前，先把订单生成好，然后用户下单时直接写入用户信息：不需要执行“检查库存”这个单点操作了，负载低了很多。

骚，实在是骚。

现实世界中的削峰

现实世界中，一个一百万 QPS 的电商系统，真正需要触达到数据的 QPS 其实是没有 500 万那么多的，在削峰的操作下，200 万 QPS 的 PolarDB 集群在 Redis 集群的配合下，是可以顶住 100 万 API QPS 的。史上流量最大的那一年双 11，每秒订单创建最大值仅为 58.3 万笔，这已经是这个地球上的最高记录了。

但是，现实世界中，一切都要讲 ROI（收益成本之比），搞一个顶配的 PolarDB 集群确实可以顶住巅峰时期一百万 API QPS，但是你老板看着账单肯定会肉痛，那，该如何省钱呢？

答：站在地球表面。

站在地球表面

一望无际的华北平原

北京位于美丽的华北平原北端，生活着两千多万人，在巅峰的 2020 年双 11，天猫平台北京地区销售额为 216 亿，全国总额为 4982 亿，占比为 4.33%，略高于北京占全国 3.44% 的 GDP 比例。那我们就可以计算得出，北京的两千多万人，给天猫贡献了583000 * 0.0433 = 25243.9笔/秒的并发。

虽然全国订单数看起来十分惊人，但是北京这一个地方的压力却只有 2.5 万单每秒，这个哪怕不用奇技淫巧硬抗，十万数据库 QPS 只用主从架构可能都能抗住。但是，系统能基于地理位置划分吗？系统不是必须全国一盘棋吗？不是的，可以划分。

下面我们讨论一下怎么划分。

基于地理位置对应用和数据库分区

为什么非要全国的用户访问同一个数据库呢？我们可以利用微服务思想对业务系统和数据进行拆分：北京的用户和上海的用户，理论上讲可以只访问“本地天猫”。

接下来我们分析一下，在一个标准的电商业务中，哪些地方会让一个北京的用户和一个上海的用户发生联系。

用户表自增 ID
商品库存检查
商家订单聚合
离线数据分析

实际上，地理上被隔开的两个人，在系统内还真没什么机会需要相互查询对方的数据，这就是我们能基于地理位置对应用和数据库进行分区的逻辑原因。下面我们一一拆除上面的单点：

可以预分配 ID 段，也可以用算法保证，例如一奇一偶
预分配库存，再异步刷新缓存：这个部分能玩出花，甚至有在客户端上提前下发抢购结果的骚操作，大家可以自己探索
简单地从两个地方各拉一次即可
更不用说了，都离线了，本身也是要做很多数据同步和聚合的，不差这一点

基于地理位置对应用和数据库进行划分，产生出两个“本地天猫”后，就需要我们老朋友 DNS 出来表演了。

进击的 DNS

域名当初可能是为了方便记忆而发明的，但是域名背后的 DNS 服务却几乎是最重要的互联网高并发基础设施：不同地区的人，对同一个域名进行访问，可以获得两个公网 ip，这样“本地天猫”就实现了。

类 DNS 哲学思想：Consul 和 Kong

DNS 几乎完全放弃了一致性，但却实现了极高的可用性和分区容错性。其实，gossip 协议也是这个思想：让消息像病毒一样传播，能够实现最终一致性就行了，要啥自行车。

异曲同工的 Kong 集群思想也让我震惊：所有节点每 5 秒从数据库读取最新的配置文件，然后，这些节点就成了一个行为完全一致的集群啦。“想那么多干什么，短时间内多个节点的行为不一致，就让他们不一致好了，5 秒之后不就一致了。”

高性能计算第一原则：数据离 CPU 越近，性能越高，容量越小

在我们熟悉的存储器山中，这是一个大家都理解的基本特性，而这个特性引申到分布式系统中，就是：一定不能让应用和数据库分离。

和 InnoDB 一样，很多时候其实是“局部性”这个我们宇宙的基本属性在帮助我们提升系统的性能，让应用和数据库分布在同一个地域，也是在利用局部性获得性能增益。

所以，让应用去隔壁区域的数据库读数据是要极力避免的——我们应该用 API 网关直接把请求发给隔壁区域的应用服务器，这显然是在今天这个异地网络传输速度接近光速的时代最佳的选择。

跟 Clickhouse 学习如何打造高并发系统

Clickhouse 在亿级数据量面前丝毫不怵：MySQL、MongoDB、Hadoop，谁也没有老子快。为什么 Clickhouse 这么快呢？

列存储还压缩

首先，它将数据以列为单位组织起来，压缩后存入磁盘上一个又一个的 block，这些 block 就像 InnoDB 的 16KB 页一样，只是它更大（64KB~1MB）。这样，当我们 select 某个 column 的时候，Clickhouse 就能顺序读出磁盘上这个 column 下面所有行的数据。

Clickhouse 对多 CPU 的利用能力非常惊人

除了列存储之外，每个 block 内，Clickhouse 还用“稀疏索引”的方式，将每一列的数据划分为了多个 granularity(颗粒度)，然后给每个 granularity 分配一个 CPU 核心进行并行计算，并且它还利用 SSE4.2 指令集，利用 CPU 的 SIMD(Single Instruction Multiple Data) 指令，在 CPU 寄存器层面进行并行操作。

放弃内存缓存

这是 Clickhouse 整个架构中我最喜欢的部分。我们通过上一篇文章可以看出，所有的分布式数据库，其本质都是在搞“内存缓存的数据同步”，Clickhouse 直接掀桌子：老子不要内存缓存了。由于所有数据都在磁盘上，而节点的 CPU 又直接和磁盘数据打交道，所以 Clickhouse 实现了真正的并行：增加 CPU 核心数就能提升系统容量，无论在不在同一台机器上都行，反正 CPU 相互之前完全不需要通信。这样，Clickhouse 通过堆核心数就能够实现系统容量的“近线性扩展”。

太暴力了，我喜欢。

我们可以学习这种思想，打造一个可以线性扩展的系统架构：只要不同地区的本地系统之间完全没有“数据实时同步”需求，那其实他们就是两个系统，就可以实现性能的线性扩展。

理论无限容量

我们说过，关系型数据库的关系，指的就是两行数据之间的关系。现实世界中，位于异地甚至是异国的两个人之间，几乎是不会发生实时相互数据读取的。

站在地球表面来思考，你会发现人类社会和自然规律都是契合高并发“找出单点，进行拆分”哲学原理的：每一个人类居所，本质上都是散落在整个地球上的一个又一个点。因为这些点的存在，我们发明了国省市县乡村逐级政府，同级政府之间几乎没有相互通信。

将一个大系统拆成不需要实时相互通信的多个小系统，可以获得线性的性能提升。

当你的系统顶不住的时候，按照这个原理来拆就行了，绝对顶得住。别说区区一百万 QPS 了，服务全人类也做得到。

价值上完了，我们最后再讨论五毛钱的高可用。

番外篇：高可用

我相信，很多人都像我一样做过思想实验，希望设计一个“完全高可用”的系统，但是最终可能都败下阵来，为什么？因为高可用和其它常见的分布式系统需求是互斥的。

数据重要如银行，也只是要求在天灾面前要尽量不丢数据、少丢数据，凭什么你就要求自己的系统永远可用呢？其实，想从架构层面实现高可用是非常困难的，终极高可用就是将数据完整地复制到世界各地的所有节点上，并用超长的时间来达到完全一致，这是什么，这是区块链呀。

高可用和性能、一致性都是冲突的，只能采用策略尽量压制问题。

熔断

这个词在技术圈的流行应该有微博一半功劳，压力一大就熔断：主动停止不重要的服务，断尾自救，争取让核心业务不挂。

限流

限制一部分地区、一部分用户的访问，以保护整个集群不崩，一般用于限制单个用户对系统造成的压力过大，对面很可能是机器人。

Facebook 2021年 10 月 4 号宕机²

Facebook 的用户不可谓不多，对高可用的投入不可谓不足，为什么还是会整个公司完全宕机 7 小时呢？

事故的起因是一个错误的命令意外断开了 Facebook 的 DNS 服务，结果问题大了：

所有客户端 API 失效，用户无法获得任何信息
数据中心 VPN 服务失效，无法远程登录到数据中心内的设备上
亲自去机房，发现门禁卡刷不开门，破拆后才接触到物理设备，插上显示器和键盘才能解决问题
邮件、Google 文档、Zoom 都登不上
办公大楼的门禁卡系统也失效了，无法刷开会议室的门，甚至无法离开办公楼

结合阿里云香港一个数据中心因为空调故障导致整个数据中心宕机超过 24 小时³，认命吧，商业机构做不了真正的高可用的：资源使用率就是钱呐。

系列收尾

本系列文章一共十篇，超过八万字，对我自己来说也是一次很有价值的总结，不知道各位读者感觉如何呢？欢迎到下列位置留下你的评论：

Github：https://github.com/johnlui/PPHC/issues
微博：https://weibo.com/balishengmuyuan
博客：https://lvwenhan.com/tech-epic/508.html

参考资料

《12306互联网售票系统的架构优化及演进》 http://tljsjyy.xml-journal.net/article/id/3756
2021 年 Facebook 宕机事件 https://zh.wikipedia.org/wiki/2021%E5%B9%B4Facebook%E7%95%B6%E6%A9%9F%E4%BA%8B%E4%BB%B6
关于阿里云香港Region可用区C服务中断事件的说明 https://help.aliyun.com/noticelist/articleid/1061819219.html

【全书完】

相关日志：

高并发的哲学原理（九）-- 细数四代分布式数据库并拆解 TiDB 和 OceanBase（主从、中间件、KV、计算与存储分离、列存储、CAP定理）

JohnLui — Sat, 04 Feb 2023 18:32:01 +0000

《高并发的哲学原理 Philosophical Principles of High Concurrency》开源图书已经发布，简称 PPHC。地址：https://github.com/johnlui/PPHC

上一篇文章啃硬骨头差点把我牙给崩了，本文我们还是回到舒适区来，继续挥舞架构大棒，欺负可怜的小数据库。本文虽然不太硬，但是量还是很大的，管饱。

说到后端系统对于数据库的要求，基本上和你老板一样：既要又要还要。数据库扮演的那个单点角色，在单机上已经如此的困难了，换到分布式环境下只会更困难。而分布式数据库的出现也是被迫的：应用规模越来越大，对性能和可用性的要求越来越高，不得不搞分布式数据库了。

接下来请大家坐稳扶好，我们正式开始分布式数据库历史变迁之旅。

单机数据库的不可能三角

正如经济政策的不可能三角“不可能同时实现资本流动自由，货币政策的独立性和汇率的稳定”那样，单机数据库也有一个不可能三角，那就是：①持久化 ②事务隔离 ③高性能。

为什么不可能

持久化需要每一次写数据都要落到磁盘上，宕机再启动以后，数据库可以自修复。如果只要求这一条，很好实现。
事务隔离需要每一次会话(session)的事务都拥有自己的数据库版本：既要多个并行的事务相互之间不会写到对方的虚拟数据库上(读提交)，又要不能读到对方的虚拟数据库上(可重复读)，还要在一个事务内不能读到别的事务已经提交的新增的数据(幻读)，终极需求则是完全串行化：我的读 session 不结束，你就不能读。这个需求和持久化需求结合以后，会大幅增加日志管理的复杂度，但，还是可以管理的。
读写都要尽量地快：单独实现也很快，Redis 嘛，但是加上持久化和事务隔离，就很难做了：需要对前两项进行妥协。

MySQL 选择了哪两个？

MySQL 首先选择了持久化：失去人性，失去很多，失去持久化，失去一切。没有持久化能力，那还当个毛的核心数据库，所以这一条是所有磁盘数据库的刚需，完全无法舍弃。

然后 MySQL 选择了一部分高性能：MyISAM 就是为了快速读写而创造的，早期 MySQL 在低配 PC 机上就有不错的性能。后来更高级的 InnoDB 出现了，小数据量时它的读取性能不如 MyISAM，写性能更是彻底拉胯，但是在面对大数据量场景时，读性能爆棚，还能提供很多后端程序员梦寐以求的高级功能（例如丰富的索引），承担了大部分互联网核心数据库的角色。

最后，MySQL 将事务隔离拆成了几个级别，任君挑选：你要强事务隔离，性能就差；你能接受弱事务隔离，性能就强。你说无事务隔离？那你用 MySQL 干什么，Redis 它不香吗。

所以 MySQL 其实选择了持久化_1 + 高性能_0.8 + 事务隔离*0.5，算下来，还赚了 0.3 (￣▽￣)"

不过，从 MySQL 也可以看出，“数据库的不可能三角”并不是完全互斥的，是可以相互妥协的。

在开始细数分布式数据库之前，我们先看一个非分布式的提升数据库性能的方案，读写分离，主从同步。

读写分离

由于 web 系统中读写需求拥有明显的二八分特征——读取流量占 80%，写入流量占 20%，所以如果我们能把读性能拆分到多台机器上，在同样的硬件水平下，数据库总 QPS 也是能提高五倍的。

各种主从架构

无论是远古时代谷歌的 MMM(Multi-Master Replication Manager for MySQL) 还是中古时代的 MySQL 官方的 MGR(MySQL Group Replication)，还是最近刚刚完成开发且收费的官方 InnoDB Cluster，这些主从架构的实现方式都是一致的：基于行同步或者语句同步，近实时地从主节点向从节点同步新增和修改的数据。

由于这种方法必然会让主从之间存在有一段时间的延迟(数百毫秒到数秒)，所以一般在主从前面还要加一个网关进行语句分发：

select等读语句默认发送到从节点，以尽量降低主节点负载
一旦出现update、insert等些语句，立刻发送到主节点
并且，本次会话(session)内的所有后续语句，必须全部发送给主节点，不然就会出现数据写入了但是读不到的情况

一主四从架构图

搭建一个一主四从的 MySQL 集群，总 QPS 就能从单节点的 1 万提升到 5 万，顺便还能拥有主节点故障后高可用的能力。主从架构比较简单，也没有什么数据冲突问题，就是有一个很大的弱点：

写入性能无法提升：由于数据库承载的单点功能实在是太多了(自增、时间先后、事务)，导致哪怕架构玩出了花，能写入数据的节点还是只能有一个，所有这些架构都只能提升读性能。

那怎么提升写性能呢？这个时候就要掏出分布式数据库了。

分布式数据库

由于数据库的单点性非常强，所以在谷歌搞出 GFS、MapReduce、Bigtable 三驾马车之前，业界对于高性能数据库的主要解决方案是买 IOE 套件：IBM 小型机 + Oracle + EMC 商业存储。而当时的需求也确实更加适合商用解决方案。

后来搜索引擎成为了第一代全民网站，而搜索引擎的数据库却“不那么关系型”，所以谷歌搞出了自己的分布式 KV 数据库。后来谷歌发现 SQL 和事务隔离在很多情况下还是刚需，于是在 KV 层之上改了一个强一致支持事务隔离的 Spanner 分布式数据库。而随着云计算的兴起，分布式数据库已经成了云上的“刚需”：业务系统全部上云，总不能还用 Oracle 物理服务器吧？于是云上数据库又开始大踏步发展起来。

下面我们按照时间顺序，逐一梳理分布式数据库的发展史。

第一代分布式数据库：中间件

在 MySQL 体系内演进

关系型数据库为了解决不可能三角需求，其基本架构 40 年没有变过。

MySQL 自己其实已经是一个非常优秀的满足互联网业务场景的单体数据库了，所以基于 MySQL 的基本逻辑进行架构改进，是最稳妥的方案。

在没有分布式关系型数据库技术出现的时代，后端开发者们往往只能选择唯一的刀耕火种的路：在应用代码里调用多个数据库，以应对单个数据库性能不足的困境。后来，有人把这些调用多个数据的代码抽出来作为单独的一层，称作数据库中间件。

数据库中间件

首先，对数据表进行纵向分表：按照一定规则，将一张超多行数的表分散到多个数据库中。

ShardingSphere 中的 Sharding-Proxy 工作方式

然后，无论是插入、更新还是查询，都通过一个 proxy 将 SQL 进行重定向和拆分，发送给多个数据库，再将结果聚合，返回。

大名鼎鼎的数据库中间件，其基本原理一句话就能描述：使用一个常驻内存的进程，假装自己是个独立数据库，再提供全局唯一主键、跨分片查询、分布式事务等功能，将背后的多个数据库“包装”成一个数据库。

虽然“中间件”这个名字听起来像一个独立组件，但实际上它依然是强业务亲和性的：没有几家公司会自己研发数据库，但每家公司都会研发自己的所谓中间件，因为中间件基本上就代表了其背后的一整套“多数据库分库分表开发规范”。所以，中间件也不属于“通用数据库”范畴，在宏观架构层面，它依然属于应用的一部分。我称这个时代为刀耕火种时代。

那该怎么脱离刀耕火种呢？人类的大脑是相似的：既然应用代码做数据规划和逻辑判断很容易失控，那我们在数据库层面把这件事接管了行不行呢？当然可以，但是需要拿东西找信息之神交换。

历史上，第一个被放弃的是事务隔离，而它带来的就是第二代分布式数据库：KV 数据库。

第二代分布式数据库：KV

分布式时代的“新·不可能三角”

在分布式数据库时代，持久化已经不是分布式数据库“真正的持久化”了，取而代之的是“数据一致性”：由于数据存在了多台机器上，那机器之间数据的一致性就成了新时代的“持久化”。于是新不可能三角出现了：①一致性 ②事务隔离 ③高性能。

你是不是在期待 CAP 理论呀？别着急，我们后面会说。

分布式 KV 数据库放弃了事务隔离

数据库技术一共获得过四次图灵奖，后面三次都在关系型数据库领域。事务隔离模型是关系型数据库的核心，非常地简洁、优美、逻辑自恰。

Google 是第一个全民搜索引擎，系统规模也达到了史上最大。但是，搜索引擎技术本身却不需要使用关系型数据库来存储：搜索结果中的网页链接之间是离散的。这块我要挖个坑，本系列完结以后，我会写一篇如何自己开发搜索引擎的文章。

由于搜索不需要关系型数据库，自然谷歌搞的分布式数据库就是 KV 模型。谷歌的三驾马车论文发布以后，业界迅速发展出了一个新的数据库门类 NoSQL(Not Only SQL)，专门针对非结构化和半结构化的海量数据。

目前，缓存（Redis）和文档/日志（MongoDB）大家一般都会用 NoSQL 来承载。在这个领域，最成功的莫过于基于 Hadoop 生态中 HDFS 构建的 HBase 了：它主要提供的是行级数据一致性，即 CAP 理论中的 CP，放弃了事务，可以高性能地存储海量数据。

KV 数据库结构简单，性能优异，扩展性无敌，但是它只能作为核心数据库的高性能补充，绝大多数场景下，核心数据库还是得用关系型。

第三代分布式数据库：以 Spanner 为代表的 NewSQL

从 2005 年开始，Google Adwords 开始基于 MySQL 搭建系统，这也推动了 MySQL 在 Google 内部的大规模使用。随着业务的发展，MySQL 集群越来越庞大，其中最痛苦的就是“数据再分片”，据说有一次谷歌对数据库的重新分片持续了 2 年才完成。于是谷歌痛定思痛，搞出了一个支持分布式事务和数据强一致性的分布式关系型数据库：Google Spanner。

2012 年，谷歌发布了 Spanner 论文¹，拉开了分布式强一致性关系型数据库的大幕。这个数据库是真的牛逼，当我第一次看到它机柜照片的时候直接震惊了：

这套系统采用了 GPS 授时 + 2 台原子钟 + 4 台时间服务器，让分布在全球多个数据中心的 Spanner 集群进行相当精确的时间同步：基于 TrueTime 服务，时间差可以控制在 10ms 之内。这种真正的全球数据库可以做到即使单个数据中心完全失效，应用也完全无感知。

当然，如此规模的全球数据库全世界也没有几家公司有需求，如果我们只在一个数据中心内署数据库集群，时间同步可以很容易地做到 1ms 之内，原子钟这种高端货还用不到。

还记得上篇文章中数据持久性的关键步骤——redo log 吗？

为什么上篇文章要写一万多字，就是为本文打基础的，现在就用到了。

上文中我们说过，写入型 SQL 会在写入缓存页 + 写入磁盘 redo log 之后返回成功，此时，真正的 ibd 磁盘文件并未更新。所以，Spanner 使用 Paxos 协议在多个副本之间同步 redo log，只要 redo log 没问题，多副本数据的最终一致性就没有问题。

事务的两阶段提交

由于分布式场景下写请求需要所有节点都完成才算完成，所以两阶段提交是必须存在的。单机架构下的事务，也是某一旦一条 SQL 执行出错，整个事务都是要回滚的嘛。多机架构下这个需求所需要的成本又大幅增加了，两阶段提交的流程是这样的：

告诉所有节点更新数据
收集所有节点的执行结果，如果有一台返回了失败，则再通知所有节点，取消执行该事务

这个简单模型拥有非常恐怖的理论故障概率：一旦在第一步执行成功后某台机器宕机，则集群直接卡死：大量节点会被锁住。

Spanner 使用 Paxos 化解了这个问题：只要 leader 节点的事务执行成功了，即向客户端返回成功，而后续数据的一致性则会基于prepare timestamp和commit timestamp加上 Paxos 算法来保证。

多版本并发控制（MVCC）

Spanner 使用时间戳来进行事务之间的 MVCC：为每一次数据的变化分配一个全球统一的时间戳。这么做的本质依然是“空间+时间”换时间，而且是拿过去的时间换现在的时间，特别像支持事后对焦的光场相机。

传统的单机 MVCC 是基于单机的原子性实现的事务顺序，再实现的事务隔离，属于即时判断。
Spanner 基于 TrueTime 记录下了每行数据的更新时间，增加了每次写入的时间成本，同时也增加了存储空间。
在进行多节点事务同步时，就不需要再和拥有此行数据的所有节点进行网络通信，只依靠 TrueTime 就可以用 Paxos 算法直接进行数据合并：基于时间戳判断谁前谁后，属于事后判断。

Spanner 放弃了什么

Spanner 是一个强一致的全球数据库，那他放弃了什么呢？这个时候就需要 CAP 理论登场了。

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

Google Spanner 数据库首先要保证的其实是分区容错性，这是“全球数据库”的基本要求，也最影响他们赚钱；然后是一致性，“强一致”是核心设计目标，也是 Spanner 的核心价值；谷歌放弃的是可用性(A)，只有 majority available。

除此之外，为了“外部一致性”，即客户端看到的全局强一致性，谷歌为每一个事务增加了 2 倍的时钟延迟，换句话说就是增加了写操作的返回时间，这就是分布式系统的代价：目前平均 TrueTime 的延迟为 3.5ms，所以对 Spanner 的每一次写操作都需要增加 7ms 的等待时间。

Spanner 一致性的根本来源

大家应该都发现了，其实 Spanner 是通过给 Paxos 分布式共识算法加了一个“本地外挂” TrueTime 实现的海量数据的分布式管理，它实现全局强一致性的根本来源是Paxos和TrueTime。而在普通单机房部署的分布式系统中，不需要 GPS 授时和原子钟，直接搞一个时间同步服务就行。

NewSQL 时代

Google Spanner 的推出代表着一个新时代到来了：基于分布式技术的 SQL 兼容数据库（NewSQL），而兼容到什么地步就看各家的水平了。

NewSQL 最大的特点就是使用非 B 树磁盘存储结构（一般为 LSM-Tree），在上面构筑一个兼容 SQL 常用语句和事务的兼容层，这样既可以享受大规模 LSM-Tree 集群带来的扩展性和高性能，也可以尽量少改动现有应用代码和开发习惯，把悲伤留给自己了属于是。

目前比较常见的 NewSQL 有 ClustrixDB、NuoDB、VoltDB，国内的 TiDB 和 OceanBase 也属于 NewSQL，但他们俩有本质区别，我们下面会详细讨论。

在 NewSQL 时代之后，随着云计算的兴起，云上数据库突然成为了市场的宠儿，市场占有率迅速上涨。它们其实都是对 MySQL 的改造，并不属于 NewSQL 范畴，下面我们认识一下他们。

第四代分布式数据库：云上数据库

我实在是不想用“云原生”这个风口浪尖上的词来形容美丽的云上数据库们，它们就像 TCP/IP，简洁但有用。市场从来不会说谎，它们一定是有过人之处的。

亚马逊 Aurora 开天辟地

2014 年 10 月，亚马逊发布了 Aurora 云上数据库，开创性地在云环境中将计算节点和存储节点分离：基于云上资源的特点，将计算节点 scale up（增配），将存储节点 scale out（增加节点），实现了极佳的性能/成本平衡。Aurora 将云上关系型数据库产品推向了一个新的高度。

计算与存储分离

Aurora 提出的计算与存储分离可以说是目前数据库领域最火的方向，但是它火的原因我相信大多数人都认识的不对：不是因为性能强，而是因为便宜。

挖掘云计算的价值点

十年前我在 SAE 实习的时候，中午大家一起吃饭，组长说云计算就是云安全，这句话当然说的很对。从这句话推开，我们很容易就能找到云计算真正的商业价值在哪里：传统托管式部署，哪些资源浪费的最多，哪里就是云计算的商业价值所在。

为了满足业务波动而多采购的 CPU 和内存，可能浪费了 50%；网络安全设备，可以说 95% 以上的资源都是浪费；高端存储，这个已经不能用资源浪费来形容了，而是被云计算颠覆了：云厂商用海量的多地域多机房内廉价的 x86 服务器里面的廉价磁盘，基于软件，构建出了超级便宜、多副本、高可用的存储，唯一的问题是性能不是太好。亚马逊 S3 和阿里云 OSS 就是最佳代表，可以说这类对象存储服务，其单价已经低于本地机房的 2.5 寸 SAS 机械磁盘了，更不要说本地机房还需要另外采购昂贵的存储控制器和 SAN 交换机了。

云计算与特斯拉

云数据库可以算是云服务厂商最重要的产品：受众足够广，成本足够低，性能足够高。这一点很像特斯拉汽车，时至今日，特斯拉依然在疯狂地想各种办法压低生产成本，虽然在降价，但是单车毛利依然维持在 30% 以上，是 BBA 的 2-3 倍。

Aurora 和 PolarDB 的核心价值是用一种低成本的方式，制造了一个 Oracle 要高成本才能做出来的软件和服务，这才是真的“创造价值”。

计算与存储分离是一种“低成本”技术

计算与存储分离并不是什么“高性能”技术，而是一种“低成本”技术：关系型数据的存储引擎 InnoDB 本身就是面向低性能的磁盘而设计的，而 CPU 和内存却是越快越好、越大越好，如果还把磁盘和 MySQL 进程部署在同一台物理机内，一定会造成磁盘性能的浪费。计算与存储分离的真正价值在于大幅降低了存储的成本。

计算与存储分离的技术优势

虽然说这个架构的主要价值在于便宜，但是在技术上，它也是有优势的：

它显著降低了传统 MySQL 主从同步的延迟。传统架构下，无论是语句同步还是行同步，都要等到事务提交后，才能开始同步，这就必然带来很长时间的延迟，影响应用代码的编写。而计算和存储分离之后，基于 redo log 传递的主从同步就要快得多了，从 1-2s 降低到了 100ms 以下。由于主从延迟降低，集群中从节点的个数可以提升，总体性能可以达到更高。

Aurora 的主从同步机制

看了上篇文章的人应该都知道，在更新数据时，主节点在完成了 redo log 写入，并对内存缓存 Buffer Pool 中相应的数据页进行修改之后，就会返回成功。这个内存缓存给 Aurora 从节点的数据更新造成了不小的影响：

主从节点之间只有 redo log 传递
从节点在拿到 redo log 之后，会刷新自己 Buffer Pool 中存在的数据页，其它不存在的页的信息会丢弃
这带来了两个问题：
1. 从节点的客户端在主从不同步的一段时间内，读到的是旧数据，这个需要网关或者应用代码来处理
2. 从节点的 Buffer Pool 有效性变差，命中率下降，引发性能下降

Aurora 的架构局限

Aurora 的出现确实独具慧眼，但是也会被时代所局限。

在 Aurora 论文²中，开篇就提到Instead, the bottleneck moves to the network between the database tier requesting I/Os and the storage tier that performs these I/Os。Aurora 认为网络速度会成为云数据库的瓶颈，而在它研发的 2012-2013 年也确实如此，当时万兆网卡刚刚普及，CPU 单核性能也不足，软件也没有跟上，可以说速度比千兆网卡也快不了多少，所以亚马逊又搞了神奇的技术：存储节点具有自己将 redo log 写入 ibd 文件的能力。

由于这个神奇能力的存在，Aurora 的多机之间采用传输 redo log 的方式来同步数据，并用一种今天看起来不太靠谱的协议来保证最终一致性：consul 使用的那个 gossip 协议。由于 Aurora 采用六副本技术，所以每次写入都需要发起六次不怎么快的网络 IO，并且在其中 4 个成功以后才给客户端返回成功。Aurora 确实便宜，但是单节点的性能也确实捉鸡，这代表的就是写入性能差，进而限制了整个集群的性能上限。而且，经过比较长的时间(100ms)才能保证从从节点上读到的数据是最新的，这会让主节点压力增大影响集群性能上限，或者让应用代码做长时间的等待，严重的会引起应用代码的执行逻辑变更，引入持久的技术债务。

那该怎么提升计算存储分离情况下的集群性能呢？我们看阿里云是怎么做的。

阿里云 PolarDB 后来居上

阿里云 RDS 集群的成本已经够低了，不需要再用计算存储分离技术降低成本了，而中国市场的用户，普遍需要高性能的 MySQL 数据库：ECS 价格太低了，如果不是运维方便和性能压力过大，谁愿意用你昂贵的数据库服务啊。

2015 年，PolarDB 开始研发，当时 25Gb RDMA 网络已经逐渐普及，所以阿里云将视角放在了网络速度之外：在 IO 速度没有瓶颈以后，基于内核提供的 syscall 所编写的旧代码将会成为新的性能瓶颈。

站在 2023 年初回头看，阿里云的判断是非常准确的。

计算存储分离架构下的整体性能极限

由于所有节点都使用了同一块“逻辑磁盘”，所以双主可写想都不要想，一个计算存储分离的数据库集群的性能上限就是主节点的写入性能上限。（Aurora 有多主可写数据库，对 ID 进行自动切分，使用时有一堆限制；PolarDB 也有多主可写数据库，但是更绝：每个库/表只支持绑定到一个可写节点，感情就是对多个数据库做了个逻辑聚合，还不如中间件呢。）

在主节点不接受读的情况下，主节点只承接写入操作，以及和写入操作在同一个会话 session 中的后续的读请求。

那 PolarDB 是如何提升主节点性能的呢？

1. 共享的不是 redo log，而是 ibd 文件

主从之间并不是依靠纯属 redo log 来同步数据的，而是直接共享同一个 ibd 文件，即真正的共享磁盘。而且，基于块设备的 Raft 算法也比基于文件的 gossip 协议要快很多。

2. 绕过内核和网路栈：大幅提升存储性能，降低延迟，减少 CPU 消耗

虽然对 redo log 的解析这一步在 Aurora 那边是存储做的，PolarDB 这边是主节点做的，看似增加了 CPU 消耗，但是这并不是真正的性能瓶颈所在，真正的瓶颈是网络栈和 UNIX 进程模型。看过我《性能之殇》系列文章的人应该都比较熟悉了，这是老生常谈了。那 PolarDB 是怎么优化的呢？

跳过 TCP/IP 网络栈，直接使用 RDMA 网络从存储节点读取数据，延迟暴降
跳过 kernel 的线程调度，自行开发绑定 CPU 核心的状态机，采用非阻塞 IO，在 CPU 占用下降的情况下，延迟进一步降低

3. 提出 ParallelRaft 协议，允许部分乱序提交

ParallelRaft 协议让 Aurora 那边需要执行六次的网络 IO 变成了一次：只需要向 leader 节点写入成功，剩下的数据同步由 Raft 算法来执行，这和 Google Spanner 的两阶段提交优化是一个思路。

原始的 Raft 协议确实逻辑完备，实现简单，就是一个一个地协商太慢了。ParallelRaft 让收敛协商能够并行起来，加速 redo log 落入 ibd 文件的过程。

4. 主从之间基于低延迟的共享存储同步 redo log 数据以刷新 Buffer Pool

基于共享存储的低延迟优势，PolarDB 主从之间使用共享存储来同步 redo log 以刷新缓存，这一点逻辑上和 Aurora 一致，但是实际表现比较好，我实测主从同步时间在 20~70ms 范围内。

5. 单机性能比标准 MySQL 更强

RDMA 存储比本地存储更快，因为减少了计算和存储争抢中断的问题：IO 这个 CPU 不擅长的东西完全卸载给了 RDMA 网卡。同配置下 PolarDB 比标准 MySQL 的性能要高几倍。

PolarDB 有这么多的优势，那它付出了什么代价呢？

在各种实测里面，PolarDB 在相同规格下对其他的云上数据库都拥有 2 倍的性能优势，但是它基于 RDMA 存储的特点也让它付出了两个代价：1. 硬件成本高昂 2. 扩展性有上限。

是不是感觉很熟悉？Shared-Disk 的代表 Oracle RAC 也有这两个缺点。不知道大家有没有发现，PolarDB 就是云时代的 RAC 数据库：看起来是 Shared-Disk，其实是共享缓存让他们的性能变的超强。

各代分布式数据库的兼容性/扩展性对比

一句话概括 PolarDB：利用了高性能云存储并且做了性能优化的一主多从 MySQL 集群。

简单讨论一下 CAP 理论

一个分布式系统中，不可能完全满足①一致性、②可用性、③分区容错性。我们以一个两地三中心的数据库为例：

一致性：同一个时刻发送到三个机房的同一个读请求返回的数据必须一致（强一致读），而且磁盘上的数据也必须在一段时间后变的完全逻辑一致（最终一致）
可用性：一定比例的机器宕机，其它未宕机服务器必须能够响应客户端的请求（必须是正确格式的成功或失败），这个比例的大小就是可用性级别
分区容错性：一个集群由于通信故障分裂成两个集群后，不能变成两个数据不一致的集群（脑裂），对外必须依然表现为一个逻辑集群

在一个分布式数据库系统中，到底什么是可以放弃的呢？我觉得可以从分布式系统带来了什么优势这个问题开始思考。

相比于单体系统，一个分布式的数据库，在一致性上进步了吗？完全没有。在可用性上进步了吗？进步了很多。在分区容错性上呢？单体系统没有分区，不需要容错。所以，结论已经一目了然了：

①和③都是分布式系统带来的新问题，只有②是进步，那就取长补短，选择牺牲可用性来解决自己引发的一致性和分区容错性两个新问题。这也正是目前常见分布式数据库系统的标准做法。

TiDB 和 OceanBase 该怎么选？

TiDB 和 OceanBase 是目前中国 NewSQL 数据库的绝代双骄，争论一直不绝于耳。

TiDB 是承袭 Spanner 思想的 NewSQL，对 MySQL 的兼容性一般，基于key+版本号的事务控制也比较弱，据说性能比较好，特别是写入性能。

OceanBase 是基于 Shared-Nothing 思想原生开发的分区存储数据库，其每个节点都支持完整的 SQL 查询，相互之间无需频繁通信。OceanBase 还支持多租户隔离，这明显就是为了云服务准备的(无论是公有云还是私有云)，和绝大多数企业无关。另外，OceanBase 对于 MySQL 的兼容性也几乎是 NewSQL 里面最高的，毕竟它需要支持支付宝的真实业务，兼容性是硬性要求，业务屎山可没人移得动 (づ｡◕‿‿◕｡)づ

下面我们详细对比一下两者的设计思路。

TiDB 的设计思路

我画的架构图如下：

上图中的“SQL 层”就是解析 SQL 语句并将其转化为 KV 命令的一层，是无状态的，下面的存储层才是核心，它叫 TiKV。

TiKV 如何存储数据

TiKV 官方原理图如下：

TiKV 是 TiDB 的核心组件，一致性和事务隔离都是基于它的能力得以实现的。每个 TiKV 拥有两个独立的 RocksDB 实例，一个用于存储 Raft Log，另一个用于存储用户数据和多版本隔离数据（基于key+版本号实现），从这里可以看出，TiDB 的存储存在大量冗余，所以 TiDB 的测试性能才会如此的高，符合空间换时间的基本原理。

和 TiKV 并列的还有一个 TiFlash 列存储引擎，是为了 OLAP 在线数据分析用的，我们在此不做详细讨论。

TiKV 数据分片

除此之外，TiKV 还发明了一层虚拟的“分片”(Region)，将数据切分成 96MB~144MB 的多个分片，并且用 Raft 算法将其分散到多个节点上存储。注意，在 TiKV 内部存储用户数据的那个 RocksDB 内部，多个分片是致密存储的，分片之间并没有逻辑关系。

TiDB 的实现风格比较狂野，所以不兼容的部分比较多：

TiDB 和 MySQL 不兼容的部分

TiDB 对 CAP 和不可能三角的抉择

TiDB 放弃了新不可能三角中的事务隔离，和 Spanner 一样放弃了 CAP 理论中的“完全可用性”：一旦出现脑裂，就会出现意外的返回结果（如超时），因为 TiDB 选择了保证一致性：如果无法达到数据强一致，就要停止服务。

一句话概括 TiDB：①搭建在 KV 数据库集群之上的②兼容部分 MySQL 语法的③有一些事务处理能力的高性能数据库。

OceanBase 设计思路

我们以最新的 OceanBase 4.0 版本的架构为目标进行讨论。

TiDB 底层数据叫分片，那 OceanBase 为什么叫分区呢？因为分片的意思只是数据被分开了（本身 KV 数据之间也没关系），但分区表示的是分区内部的数据之间是有联系的：OceanBase 的每个节点本身，依然是一个关系型数据库，拥有自己的 SQL 引擎、存储引擎和事务引擎。

简单的分区

OceanBase 在建表时就需要设定数据分区规则，之后每一行数据都属于且仅属于某个分区。在数据插入和查询的时候，需要找到这一行数据所在的区，进行针对性地路由。这和第一代分布式——中间件的思想一致。这么做相当于简单地并行执行多条 SQL，以数据切分和数据聚合为代价，让数据库并行起来。而这个数据切分和数据聚合的代价，可以很小，也可以很大，需要 OceanBase 进行精细的性能优化，我们下面还会说到。

分区之间，通过 Multi-Paxos 协议来同步数据：每一个逻辑分区都会有多个副本分布在多台机器上，只有其中一个副本会成为 leader，并接受写请求。这里的架构和 PolarDB 一样了，此时，客户端的一致性读需要网关(OBProxy)来判断，主从之间的同步是有可感知的延迟的。

节点存储架构

官方存储架构图

OceanBase 数据库的存储引擎基于 LSM Tree 架构，将数据分为静态基线数据（放在 SSTable 中）和动态增量数据（放在 MemTable 中）两部分，其中 SSTable 是只读的，一旦生成就不再被修改，存储于磁盘；MemTable 支持读写，存储于内存。数据库 DML 操作插入、更新、删除等首先写入 MemTable，等到 MemTable 达到一定大小时转储到磁盘成为 SSTable。在进行查询时，需要分别对 SSTable 和 MemTable 进行查询，并将查询结果进行归并，返回给 SQL 层归并后的查询结果。同时在内存实现了 Block Cache 和 Row cache，来避免对基线数据的随机读。
当内存的增量数据达到一定规模的时候，会触发增量数据和基线数据的合并，把增量数据落盘。同时每天晚上的空闲时刻，系统也会自动每日合并。
OceanBase 数据库本质上是一个基线加增量的存储引擎，在保持 LSM-Tree 架构优点的同时也借鉴了部分传统关系数据库存储引擎的优点。

以上是官方描述，我本来想简化一下，读了一遍觉得还是放原文吧，原文描述的就非常的清晰精炼了：OceanBase 用内存 B+ 树和磁盘 LSM-Tree 共同构成了数据读写体系，和上一篇文章中的 InnoDB 是多么像啊！只是 OceanBase 做的更细：跟 TiDB 相比，就像是在 TiKV 上面加了一层 Buffer Pool 一样。

还有一个细节：OceanBase 除了记录日志(Redo Log)并修改内存缓存(MemTable)之外，只要内存充足，白天 OceanBase 不会主动将内存缓存中的数据刷洗到 SSTable 里的，官方更推荐每天凌晨定时刷洗。这是什么思想？可以说是空间(内存)换时间，也可以说是拿未来的时间换现在的时间。

OceanBase 性能来源之一——充分的内存缓存

从基础电气属性上讲，磁盘一定是慢的，内存一定是快的，所以在数据量大于机器的内存容量时，各种数据库的性能差别可以聚焦到一个点上：内存利用效率，即热数据命中内存缓存的概率。

为了提升缓存命中率，OceanBase 设计了很多层内存缓存，尽全力避免了对磁盘的随机读取，只让 LSM-Tree 的磁盘承担它擅长的连续读任务，包子有肉不在褶上，商用环境中捶打过的软件就是不一样，功夫都在细节里：

BloomFilter Cache：布隆过滤器缓存
MemTable：同时使用 B+ 树和 HashTable 作为内存引擎，分别处理不同的场景
Row Cache：存储 Get/MultiGet 查询的结果
Block Index Cache：当需要访问某个宏块的微块时，提前装载这个宏块的微块索引
Block Cache：像 Buffer Pool 一样缓存数据块(InnoDB 页)
Fuse Row Cache：在 LSM-Tree 架构中, 同一行的修改可能存在于不同的 SSTable 中，在查询时需要对各个 SSTable 查询的结果进行熔合，对于熔合结果缓存可以更大幅度地支持热点行查询
Partition Location Cache：用于缓存 Partition 的位置信息，帮助对一个查询进行路由
Schema Cache：缓存数据表的元信息，用于执行计划的生成以及后续的查询
Clog Cache：缓存 clog 数据，用于加速某些情况下 Paxos 日志的拉取

OceanBase 性能来源之二——直接变身内存数据库

为了极致的性能，OceanBase 直接取消了 MySQL 中“后台进程每秒将 redo log 刷写到 ibd 文件”这一步，等于放大了集群宕机重启后恢复数据的时间（重启后需要大量的时间和磁盘 IO 将 redo log 刷写入磁盘），然后把这件事放到半夜去做：

当内存的增量数据达到一定规模的时候，会触发增量数据和基线数据的合并，把增量数据落盘。同时每天晚上的空闲时刻，系统也会自动每日合并。

把一整天的新增和修改的数据全部放到内存里，相当于直接变身成了内存数据库（还会用 B 树和 Hashtable 存两份），确实是一种终极的性能优化手段，OceanBase 真有你的。

填坑：OceanBase 如何提升并行查询和数据聚合的性能

传统的中间件 Sharding 技术中，也会做一些并行查询，但是他们做的都是纯客户端的查询：proxy 作为标准客户端，分别从多台机器拿到数据之后，用自己的内存进行数据处理，这个逻辑非常清晰，但有两个问题：1. 只能做简单的并行和聚合，复杂的做不了 2. 后端数据库相互之间无通信，没有很好地利用资源，总响应时间很长。

OceanBase 让一切尽可能地并行起来了：在某台机器上的 proxy(OBServer) 接到请求以后，它会担任协调者的角色，将任务并行地分发到多个其他的 OBServer 上执行；同时，将多个子计划划分到各个节点上以后，会在各节点之间建立 M*N 个网络通信 channel，并行地传输信息；此外，OceanBase 还对传统数据库的执行计划优化做了详细的拆分，对特定的关键词一个一个地做分布式优化，才最终达成了地表最强的成就。

由于本身就是为了兼容 MySQL 而设计的一种新技术实现，所以它拥有非常优秀的兼容性：

OceanBase 和 MySQL 不兼容的部分

OceanBase 对 CAP 和不可能三角的抉择

由于数据是分区的，所以当脑裂时，两个大脑的数据肯定已经不完整了，相当于两万行的表只剩一万行数据可以进行查询和更新，此时，如果 OceanBase 梗着脖子非要追求数据强一致，也是可以让所有的 OBProxy 拒绝服务的，但是 OceanBase 选择了继续苟着：互联网公司嘛，能实现最终一致性就行了，要啥自行车。

OceanBase 放弃了 CAP 和新不可能三角中的一致性，只能做到最终一致性：为了事务隔离和性能，哥忍了。

其实，不追求强一致和我们下一篇《站在地球表面》中的终极高并发架构在思想上是一致的，我想这就是经历过大规模生产应用的数据库，被现实世界毒打过后的痕迹吧。

一句话概括 OceanBase：①世界第一性能的②高度兼容 MySQL 的③经历过生产系统考验的高性能分布式关系型数据库。

分布式数据库，应该怎么选？

其实，分布式数据库根本就轮不到你来选：应用准备好了吗？有足够的研发资源吗？性能问题已经大到压倒其他需求了吗？

如果你有一个正在成长的业务，影响最小、成本最低的方案就是选择 Aurora/PolarDB 这种高兼容性数据库，等到这类云数据库的主节点达到性能上限了，再对应用做逐步改造，滚动式地替换每个部分的数据库依赖。

如果压力大到必须换分布式数据库技术方案了，再看看你能获得什么样的分布式数据库呢？无非是在哪个云平台就用哪家呗。

番外篇

Shared-Nothing、Shared-Memory 和 Shared-Disk

Shared-Nothing 只是一种思想，并不是一种明确的数据库架构，它非常笼统，只是描述了一种状态。在这里我们简单讨论一下 Shared-Nothing。

Shared-Nothing 描述的是一种分布式数据库的运行状态：两台物理机，除了网络通信之外，不进行任何资源共享，CPU、内存、磁盘都是独立的。这样，整个系统的理论性能就可以达到单机的二倍。

怎么理解 Shared-Nothing 思想呢？把它和 Shared-Disk 放到一起就明白了：

Shared-Disk：多台机器通过共享 SAN 磁盘的方式协同工作，让系统整体性能突破单机的极限。Oracle RAC 是这个架构的佼佼者，不过它的成功并不在于磁盘，而在于它的分布式锁(CACHE FUSION)：RAC 利用时间戳和分布式锁实现了分布式事务和多台机器同时可写，大幅提升了集群的性能。注意，时间戳在这里又出现了。CACHE FUSION 其实已经可以被称作 Shared-Memory 了。感兴趣的可以自己了解，我们不再深入。

21 世纪初，Oracle 推出了 Shared-Disk 的 RAC，IBM 推出了 Shared-Nothing 的 DB2 ICE。十年后，Oracle RAC 发展的如火如荼，而 DB2 ICE 已经消失在了历史的长河中。

但是，2012 年 Google 发布了 Spanner 论文，在非常成熟的世界上最大规模的 KV 数据库之上，构建 SQL 层，实现持久化、事务和多版本并发控制，扛起了 Shared-Nothing 技术方向的大旗，直到今天。

MongoDB 小故事

十年前我在新浪云(SAE)实习的时候，听过一个关于 MongoDB 的技术小故事：当时，SAE 的 KV 服务是使用 MongoDB 实现的，在规模大到一定程度以后，性能会突然下降，SAE 自己解决不了这个问题，就给 MongoDB 开发组的各位大哥买机票请他们到北京理想国际大厦 17 层现场来帮忙，研究了几天，MongoDB 开发组的人说：你们换技术吧，MongoDB 解决不了你们这个规模的问题，然后 SAE 的 KV 就更换技术方案来实现了。

DBA 晕倒砸烂花盆

也是在 SAE，我坐在厕所附近临过道的工位（上厕所很方便），某天早上刚上班，我亲眼看到 SAE 的一名 MySQL DBA 从厕所里出来后，晕倒在我面前，砸烂了一个大花盆。数据库作为系统架构中最重要的那个单点的残酷，可见一斑。

列存储思想

与其将列存储认定为数据库的一种，我倒觉得它更应该被称作一种思想：观察数据到底是被如何读取，并加以针对性地优化。

列存储有点像第一性原理在数据库领域的应用：不被现实世界所束缚，没有屈服于 B 树和它亲戚们的淫威，勇敢地向更底层看去，思考着在我们大量读取数据时，数据怎样组织才能读的更快。

在读取一行数据时，显然 B+ 树的效率无人能及，但是当我们需要读取 100 万行数据中的某一列时，B+ 树就需要把这 100 万行数据全部载入内存：每次将一页 16KB 载入内存，循环这一页内的 14 行数据，把这个特定的字段复制出来；重复执行这个操作 71429 次，才能得到我们想要的结果。这显然是 B+ 树非常不擅长的需求。

而列存储将数据基于行的排布翻转过来了：所有数据基于列，致密地排列在磁盘上，这样对某一列的读取就变成了磁盘顺序读，即便是机械磁盘，顺序读也非常快。

列存储数据库 clickhouse 颇有毛子暴力美学的典范，和 Nginx 的气质很像

clickhouse 推荐使用尽量多的 CPU 核心，对单核性能无要求，我拿 E5-V2 旧服务器测过，速度确实非常惊人，8000 万行的表，查询起来不仅比 MySQL 快，比 Hadoop 也快特别多。

还记得我们的目标吗？五百万数据库 QPS

在中国，我们现在有下面两种方案可以选择：

OceanBase 已经蝉联 TPC-C 数年的全球冠军了，每分钟可以处理 7.07 亿个订单，每秒订单数都已经过千万了，更不要说 QPS 500 万了，所以，如果你用 OceanBase，你的百万 QPS 的高并发系统已经搭建完成了！ :-D
如果你用阿里云，那 1 主 4 从，88 vCore 710 GB * 5 个节点的 PolarDB 集群可以跑到大约 200 万 QPS³。那离 500 万还有不小的距离呢，不要着急，我们下篇文章解决这个问题。

接下来

接下来就是本系列最后一篇文章了：我们不仅要用架构顶住五百万数据库 QPS，还会找出一个哲学♂办法，打造能够服务全人类的系统。

参考资料

Google Spanner 论文（中文版） https://ying-zhang.github.io/time/2013-Spanner-cn.pdf
亚马逊 Aurora 论文 https://web.stanford.edu/class/cs245/readings/aurora.pdf
复盘：我在真实场景下对几款主流云原生数据库进行极限性能压测的一次总结 https://cloud.tencent.com/developer/article/2066823

相关日志：

高并发的哲学原理（八）-- 将 InnoDB 剥的一丝不挂：B+ 树与 Buffer Pool

JohnLui — Tue, 24 Jan 2023 13:22:39 +0000

《高并发的哲学原理 Philosophical Principles of High Concurrency》开源图书已经发布，简称 PPHC。地址：https://github.com/johnlui/PPHC

前面几篇文章，我们大多数时候都在挥舞着架构大棒，对性能问题进行降维打击，但是本文不一样，本文要啃硬骨头：吃透 MySQL 的 InnoDB 存储引擎，以便于我们能顺利地看懂下一篇文章。

同时，本文也是一篇比较完善的讲解 InnoDB 底层设计原理的文章，单独作为 InnoDB 的一篇详解文章我认为也是极好的，如果大家觉得对身边的人有帮助，可以单独分享此篇文章，相信能够让每一个读过的人都对 InnoDB 有新的理解、体会和感悟。

本文将是《高并发的哲学原理》系列中唯一一篇有点像面试八股文的文章，但是，我们还是要尽量走出个虎虎生风，走出个一日千里，再走出个恍如隔世...... 下面我们正式开始。

磁盘存储引擎的巅峰——InnoDB

发展历程和设计目标

2004 年，扎克伯格选择了 MySQL 来创建 Facebook，不承想，Facebook 迅速火遍了全世界。之后的十年，Google、亚马逊、阿里巴巴等互联网巨头纷纷选择了 MySQL 作为自己的核心数据库，随之而来的就是 MySQL 的高速发展：互联网巨头投入海量技术资源把 MySQL 打造成了一个十分优秀的开源数据库软件，而 InnoDB 就是承接资源最多的那个部分。

这些公司的数据库需求基本都是一个类型的：表字段很少，但是行数很多；对于单个查询的时间要求很高；很少存储长字符串和二进制文件。这个类型的需求恰恰不是传统数据库(如 Oracle)的强项。而且，互联网公司的发展一日千里，无论是授权费还是实施速度，买 Oracle 都不如自己魔改 MySQL。之后的十几年，MySQL 特别是 InnoDB 的发展真的可以说是虎虎生风、一日千里，如果你站在 2014 往回看 2004，也确实称得上恍如隔世。

但 InnoDB 也不是银弹，它的性能也是靠取舍得来的。

InnoDB 拿什么找信息之神换了什么？

InnoDB 和之前的 MyISAM 比，最大的变化就是将磁盘上面数据的基本存储结构从索引+数据这样的分体式，变成了所有数据都挂在索引上的整体式：从“B+ 树索引”加“磁盘连续存储数据”(中间用指针链接)变成了“B+ 树存储全部索引和数据”。

这个操作给 MySQL 带来了翻天覆地的变化。那么，InnoDB 到底做了哪些取舍呢？

代价

插入性能显著下降，更新性能显著下降（100~1000倍，但是绝对耗时依然在毫秒级别）
一次性读取连续多行的复杂度大幅提升（大约提升了行数/10那么多倍）
因为事务隔离导致大表 count(*) 的返回时间令人崩溃（多少倍已经无法衡量，一千倍到一千亿倍吧）
放弃了数据完全压缩能力（磁盘占用 2-5 倍）
写入放大显著增加，对磁盘特别是固态磁盘(SSD)形成了额外的压力

收益

支持了事务：事务是极其核心的功能进步，使 MySQL 摆脱了玩具定位，真正实现了ACID，成为了一个合格的 OLTP 数据库
大表的单行读取性能暴增：数据挂在 B+ 树索引上带来的优势，还可以依靠内存缓存进行加速和局部性优化
DML(表结构变更)操作的安全性大幅提升，数据损坏的概率大幅降低
联表查询性能大幅提升，让 MySQL 在 OLAP 方向也有很大进步
支持全文检索：类似于 ES 的倒排索引
其它小收益：支持了行锁、内存缓存、外键约束等

这些代价和收益，基本都是两个东西带来的：B+ 树和 Buffer Pool，下面我们分别认识一下这两个技术。

B+ 树

B+ 树是 1970 年 Rudolf Bayer 教授在《Organization and Maintenance of Large Ordered Indices》一文中提出的，此后，该技术迅速成为了海量数据存储与检索的大宝贝：以查询为主要场景的关系型数据库，无一例外地选择了它。

B+ 树基本思想

B+ 树是一种平衡多路查找树，它的思想其实是承袭自平衡二叉树和 B 树的，但是它是为速度非常慢的所谓“外存”设计的一种数据结构，所以它拥有独特的设计方向：

尽量减少数据不停增长时的磁盘 IO 数量：包含插入新数据场景和查询场景

它将经典平衡二叉树的“再平衡”过程颠倒过来了：最底层的叶子结点致密排列，新增数据时不断新增新的叶子节点，需要进行“再平衡”操作的不是叶子节点，而是上面的索引页，索引页具有以下特点：

索引页的数量很少
再平衡时 B+ 树算法调整的索引节点数量也很少
索引容量足够大：3 层索引可以承载 2000 万行数据，4 层索引可以承载 200 多亿行
索引页少，就可以将所有索引全部载入内存，读取索引的磁盘 IO 无限趋近于 0

InnoDB 是如何组织数据的

下面我们来具体认识一下 InnoDB 中索引和数据在磁盘上是怎么利用 B+ 树思想进行组织的：

1. 页

页是 MySQL 中数据存储的基本单元，整颗 B+ 树就是一个又一个相互使用指针连接在一起的页组成的。由于 InnoDB 出现的时候，SSD 还没有出现，所以它是为了机械磁盘及其 512 字节的扇区而设计的，所以页块的默认大小被设置为了 16KB（32 个连续扇区）。

三层索引下的页结构图（35 行数据）

这张图基本展示出了页之间的指针关系：

上层页对下层页拥有单向指针
同一层内相邻的页之间拥有双向指针，无论是上面的索引页层还是底层的数据页层
最底层数据页层中，每一页可以存储多行数据，每一行数据拥有指向下一行的单向指针

而在物理层面，每一页的内部结构都如下图所示：

2. 索引页里面有什么

二层索引下的页结构图（15 行数据）

我们用更清晰的二层索引簇结构来展示索引页包含的关键信息，顶部那个彩色的就是索引页。

除了头部和尾部的基础信息字段之外，索引页的“用户存储数据”紧密排列着指向下一层页的指针，结构为：id|页号。

这里的 id 就是这张表默认主键的那个 id，一般为int(4 字节)或者bigint(8 字节)。该数字的含义是：

该页号对应的页，以及下挂的所有页，所拥有的全部数据行中，id 最小的那行数据的 id

InnoDB 使用这个数字可以快速定位某一行数据所处的页的位置。

页号就是页的编号，在不同版本的 MySQL 上这个页编号的长度是不一样的，下面我们会通过测试来确定 MySQL 8.0 中页编号的长度。

3. 数据页里面有什么

B+ 树上层的所有页只存储索引，只用最底层的页存储数据。这是 B+ 比 B 树优秀的地方：以一丢丢写入速度为代价，让较少的索引层数内存下了更多的索引指针，可以支撑海量的数据行数。

数据页内部是分槽的，相当于自己又加了一层索引。数据页内部拥有最小记录指针和最大纪录指针，有没有觉得一花一世界，数据页内部结构和 B+ 树颇有几分神似呢？

执行 `select * from users where id=6`

有了前面的铺垫，真正的 SQL 查询过程就呼之欲出了：我们要找出id=6的一行数据时，只需要一层一层地比大小：

将顶部页(16KB)的数据读入内存，将 6 和每一个id|页号进行大小对比，找到 6 落在哪一页：大于等于当前 id 并小于右侧邻居的 id
将上面找出的那一页数据读入内存，重复上面的比对操作，直到找到最底层的那个数据页
将数据页读入内存，找出id=6索引下下挂的全部数据，就是这一行数据

InnoDB 数据插入测试

下面我们针对 InnoDB 搞一次数据插入测试，希望能够窥探到 InnoDB 索引页“再平衡”的具体操作，追踪索引扩层的具体动作，确定id|页号中页号的数据长度，并顺便解决一下“2000w 行分表”问题的历史悬案。

神奇的“2000W 行分表”历史悬案

相信大家都听说过“单表到了 2000 万行就需要分表了”，甚至有人还看过“京东云开发者”的那篇著名的文章¹，但是那篇文章为了硬凑 2000 万搞出了很多不合理的猜想。

下面我们实际测试一下 MySQL 8.0.28 运行在 CentOS Stream release 9 上（文件系统为 ext4），索引层数和数据行数之间的关系，相信测试完以后，你会对这个问题有深刻的理解。

测试准备

测试表结构如下：

CREATE TABLE `index_tree` (  `id` int unsigned NOT NULL AUTO_INCREMENT,  `s1` char(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT 's1',  `s2` char(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT 's2',  `s3` char(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT 's3',  `s4` char(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT 's4',  PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

我们采用不可变长度的 char 来进行测试，根据 MySQL 8.0 关于 CHAR 和 VARCHAR 类型的官方文档²，当我们只保存s1这种 ASCII 字符时，一行数据的长度很容易就可以计算出来：4 + 255 + 255 + 255 + 255 = 1024 字节

ibd 结构探测工具

我们采用阿里巴巴开源的MySQL InnoDB Java Reader³来窥探 ibd 内部所有页的情况，主要是看他们的层级。

开始插入数据

在只插入了一行数据时，窥探结果如下：

=====page number, page type, other info=====0,FILE_SPACE_HEADER,space=1289,numPagesUsed=5,size=7,xdes.size=11,IBUF_BITMAP2,INODE,inode.size=43,SDI4,INDEX,root.page=true,index.id=4605,level=0,numOfRecs=1,num.dir.slot=2,garbage.space=05,ALLOCATED6,ALLOCATED

一层索引下的页结构图（1 行数据）

此时index_tree.ibd文件的尺寸为 112KB。

1. 首次索引分级

我们继续插入数据，在插入了第 15 行后，这个 idb 文件从 1 页分裂成了 3 页：

=====page number, page type, other info=====0,FILE_SPACE_HEADER,space=1289,numPagesUsed=7,size=8,xdes.size=11,IBUF_BITMAP2,INODE,inode.size=43,SDI4,INDEX,root.page=true,index.id=4605,level=1,numOfRecs=2,num.dir.slot=2,garbage.space=05,INDEX,index.id=4605,level=0,numOfRecs=7,num.dir.slot=3,garbage.space=73506,INDEX,index.id=4605,level=0,numOfRecs=8,num.dir.slot=3,garbage.space=07,ALLOCATED

二层索引下的页结构图（15 行数据）

我们能够看出，本来这 14 条数据都是在初始的那个 4 号页内部储存的，即数据部分至少有1024*14=14KB的容量，在插入第 15 条数据迈向 15KB 的时候，innodb 发了页的分级：B+ 树分出了两级，顶部为一个索引页 4，底部为两个数据页 5 和 6，5 号页拥有 7 行数据，6 号页拥有 8 行数据。这说明每一页可用的数据容量为14kB - 15KB之间。

而且，从garbage.space可以看出，5 号页是之前那个唯一的 4 号页，而新的 4 号页和 6 号页则是本次分级的时候新建的。

下面让我们继续插入数据，看它什么时候能从二层增长为三层。

2. 二层转换为三层

我以 500 为步长批量插入数据，在 16500 行的时候，还是二层：

=====page number, page type, other info=====0,FILE_SPACE_HEADER,space=1292,numPagesUsed=37,size=1664,xdes.size=221,IBUF_BITMAP2,INODE,inode.size=43,SDI4,INDEX,root.page=true,index.id=4608,level=1,numOfRecs=1180,num.dir.slot=296,garbage.space=05,INDEX,index.id=4608,level=0,numOfRecs=7,num.dir.slot=3,garbage.space=73506,INDEX,index.id=4608,level=0,numOfRecs=14,num.dir.slot=4,garbage.space=07,INDEX,index.id=4608,level=0,numOfRecs=14,num.dir.slot=4,garbage.space=08,INDEX,index.id=4608,level=0,numOfRecs=14,num.dir.slot=4,garbage.space=09,INDEX,index.id=4608,level=0,numOfRecs=14,num.dir.slot=4,garbage.space=0

但是当表长度来到 17000 的时候，已经是三层了：

=====page number, page type, other info=====0,FILE_SPACE_HEADER,space=1292,numPagesUsed=39,size=1728,xdes.size=221,IBUF_BITMAP2,INODE,inode.size=43,SDI4,INDEX,root.page=true,index.id=4608,level=2,numOfRecs=2,num.dir.slot=2,garbage.space=05,INDEX,index.id=4608,level=0,numOfRecs=7,num.dir.slot=3,garbage.space=73506,INDEX,index.id=4608,level=0,numOfRecs=14,num.dir.slot=4,garbage.space=07,INDEX,index.id=4608,level=0,numOfRecs=14,num.dir.slot=4,garbage.space=0... ...36,INDEX,index.id=4608,level=0,numOfRecs=14,num.dir.slot=4,garbage.space=037,INDEX,index.id=4608,level=1,numOfRecs=601,num.dir.slot=152,garbage.space=782638,INDEX,index.id=4608,level=1,numOfRecs=614,num.dir.slot=154,garbage.space=039,ALLOCATED40,ALLOCATED... ...

三层索引下的页结构图（17000 行数据）

此时，index_tree.ibd文件的尺寸为 27MB。

在整颗 B+ 树从二层转换为三层的过程中，只修改了三个页：

将目前唯一的索引页 4 号的数据复制到 37 号页中，level 保持不变（此时 37-63 号已经被提前ALLOCATED出来用作备用页了）
将 38 号页初始化成一个新的 level=1 的索引页，并将左侧 37 号页右边一半的页指针转移给 38 号页，再删除 37 号页中的原指针
重新初始化 4 号页，设置为顶层(level=2)索引页，创建两个页指针：第一个指向 37，第二个指向 38

为什么是 17000 行呢？我们来计算一下二层索引的极限容量：

已知一个最底层(level=0)的数据节点可以存储 14 条数据
假设索引页内部的一个页指针的长度是4+8=12字节，那 2 层索引的极限就是：
(14 1024 / 12) 14 = 16725.33

和实测值完美契合！

此时计算可知，一个索引页至少可以存储14 * 1024 / 12=1194.66666666个页指针。

3. 三层转换为四层

继续向 index_tree 表中批量插入数据，在数据继续分层之前，整棵树的结构保持不变，只是会不断增加 level=0 和 level=1 的页的数量。

但当行数来到了 21427000 行时，索引就从 3 层转换为了 4 层了，此时磁盘 ibd 文件为 24GB，探测结果如下：

=====page number, page type, other info=====0,FILE_SPACE_HEADER,space=1292,numPagesUsed=4,size=1548032,xdes.size=2561,IBUF_BITMAP2,INODE,inode.size=43,SDI4,INDEX,root.page=true,index.id=4608,level=3,numOfRecs=2,num.dir.slot=2,garbage.space=05,INDEX,index.id=4608,level=0,numOfRecs=7,num.dir.slot=3,garbage.space=73506,INDEX,index.id=4608,level=0,numOfRecs=14,num.dir.slot=4,garbage.space=0... ...1424021,INDEX,index.id=4608,level=2,numOfRecs=601,num.dir.slot=152,garbage.space=78261424022,INDEX,index.id=4608,level=2,numOfRecs=672,num.dir.slot=169,garbage.space=0... ...

由此可知，索引结构是这样的：

1 个 4 层(level=3)索引页，含有 2 个 3 层索引页的指针
2 个 3 层(level=2)索引页，其中左侧的 1424021 号页有 601 个底层数据页的指针，右侧的 1424022 号页有 672 个底层数据页的指针
601+672=1273个 2 层索引页，每页含有 1194+ 个底层数据页的指针
21427000/14=1530500个底层数据页，每页含有 14 条数据

转换的过程中，哪些页需要更新数据呢？还是只需要修改三个页：

需要将 4 号页(旧顶层页)的数据拷贝到 1424021 号页(新 level=2 左)中
新生成 1424022 号页(新 level=2 右)，将 1424021 号页(新 level=2 左)内部右侧的 672 个页指针(id|页号)复制到 1424022 号页中，并删除 1424021 号页中的原指针
重新初始化 4 号页，创建两个页指针：第一个指向 1424021，第二个指向 1424022

再增加一层需要再插入 1200 倍的数据，我们就不测试了，28TB 的磁盘阵列我也没有╮(╯▽╰)╭

计算页指针`id|页号`的大小

无论是中文技术文章还是英文技术文章，我甚至还查了 MySQL 8.0 InnoDB 的官方文档，并没有说“页号”的大小，甚至对于id的大小都没有一个统一的说法。下面我们尝试自己算出来：

在 14-15 之间一层索引转换成了二层索引，所以页可用容量最大值1024 * 15 = 15360
最小值1024 * 14 = 14336
在 16500-17000 之间二层索引转换成了三层索引，对应的索引数最大值为17000 / 14 = 1214.28
索引数最小值为16500 / 14 = 1178.57

我们拿最大值除以最小值，得到 15360 / 1178.57 = 13.03字节，拿最小值除以最大值，得到 14336 / 1214.28 = 11.81字节，所以我们可以得出结论:

单个id|页号的大小应该为 12 字节或者 13 字节

接下来怎么确定呢？再拿 bigint 做一遍测试就行了。

使用 bigint 确定页号的大小

我们建立一个名叫index_tree_bigint的表：

CREATE TABLE `index_tree_bigint` (  `id` bigint unsigned NOT NULL AUTO_INCREMENT,  `s1` char(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT 's1',  `s2` char(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT 's2',  `s3` char(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT 's3',  `s4` char(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT 's4',  PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

单行数据的容量从 1024 上升到了 1028。

按照同样的流程进行测试，可以发现还是 14 到 15 条的时候发生的一层转换到两层，从 12500 到 13000 条时从二层转换到了三层，我们使用同样的方法进行计算：

1028 * 15 / ( 12500 / 14 ) = 17.27
1028 * 14 / ( 13000 / 14 ) = 15.50

主键采用 bigint 类型时，单个id|页号的大小应该为 16 字节或者 17 字节。

得出结论：“页号”为 8 字节

由于页号采用奇数长度的概率非常低，我们可以得出一个十分可信的结论：在 MySQL 8 中，id 的长度和类型有关：int为 4 字节，bigint为 8 字节，“页号”的长度为 8 字节。则单个id|页号的大小应该为 12 字节或者 16 字节。

解答“2000W 行分表”问题

真实世界数据长度以及它的 4 层极限

看了一眼我司生产数据库，电商业务的常用大表“订单商品表”，实际单行数据长度为0.9KB，和我们做测试的 1KB 差别不大，所以上面的测试结果还是很符合现实世界的真实情况的。

我们取如下几个值来计算 3 层到 4 层的理论极限：

单页可用数据容量 14KB
单行数据 0.9KB，所以每页最多可以存储14/0.9=15.5555，取整为 15 行数据
主键类型采用int，页指针长度为 12 字节，所以每页最多可以存储14*1024/12=1194.6666，取整为 1194 个页指针

则三层 B+ 树的理论极限为：1194^2 * 15 = 21384540，大约 2100 万行，还是蛮符合 2000W 行分表的传说的。

四层到五层呢？

而如果需要五层，则行数需要达到 1194^3 * 15 = 25533140760，即 255 亿行，这个数字已经超过了 unsigned int 的上限 42 亿多，需要用 bigint 来做主键了，感兴趣的可以自行计算 bigint 下五层索引甚至是六层七层八层的行数极限，我在此不再赘述。

2100w 行以后，真的会发生性能极速劣化吗？并不会!

三层索引和四层索引的性能并没有什么不同，2000W 行分表已经过时了！

其实，每一次 B+ 树增高，都只会增加两个索引页，修改一个索引页，加起来只修改了三个 16KB 的数据页，无论是磁盘 IO 还是 Buffer Pool 缓存失效，对性能的影响都微乎其微：

索引从三层转换到四层，只增加了一次 IO，绝对性能降低幅度的理论极限只有1/3，而且在有 Buffer Pool 存在的情况下，性能差异微乎其微，只增加了1~2次比大小的计算成本。

那是否意味着不需要再分表了呢？

虽然三层索引和四层索引看起来性能差异不大，但是如果你的单行数据比较大，例如达到了 5KB，还是建议做一下横向分表的，这才是效果最立竿见影的减少磁盘 IO 次数的优化方法：

单行数据为 0.9KB 时，三层树的极限行数是 2100 万，但是如果单行数据来到 5KB，那这个极限会变成 285 万行，这可能就不太够了
数据页拥有局部性：每次从磁盘读取都是一整页的数据，所以读取某一行数据以后，它 id 附近的数据行也已经在内存缓存里了，读取性能十分优异
在连续读取多行时（例如全表条件查询），巨大的单行数据将在让“局部性”优势迅速丧失的同时，会引发磁盘 IO 次数出现数量级规模的上升，这就是单行数据比较大的表读取起来感觉格外慢的原因

到底该何时分表？

2017 年发布的阿里巴巴 Java 开发手册中写道“单表行数超过 500 万行或者单表容量超过 2 GB ，才推荐进行分库分表”，被很多技术博文写成了：阿里巴巴推荐超过 500 万行的表进行分表，这种理解是错误的。

虽然经过我的实测，在每行数据定长 1024 字节，Buffer Pool 配置为 22GB，在单表体积 24GB 的情况下，四层索引和三层索引并没有任何性能差异，但是现实世界中的数据表可不是这么严丝合缝：

为了节约空间和保持扩展性，绝大多数短字符串类型采用的是 varchar 而非定长的 char，这就让 level=0 的每一页包含的数据行数不一致，这会让这颗“平衡多路查找树”不怎么平衡
生产表经常面临数据删除和更新：同层的页之间的双向链表和不同层页之间的单向指针都需要经常变化，同样会让这棵树变的不平衡
一张表使用的越久，ibd 文件中的碎片就越多，极端情况下（例如新增 10 行删除 9 行）会让数据页的缓存几乎失效
磁盘上单文件体积过大，不仅在读取 IOPS 上不如多文件，还会引发文件系统的高负载：单个文件描述符也是一种单点，大文件的读写性能都不太行，还容易浪费大量内存

那么，该如何回答“到底该何时分表”这个问题呢？很遗憾并没有一个放之四海皆准的答案，这和每个表的读取、新增、更新的具体情况是分不开的。

虽然在数据库技术层面我们无法给出何时分表的答案，但是从软件工程层面我们可以得出一个结论：

能不分就不分，不到万不得已不搞分表，如果能靠加索引或者加内存来解决就不要考虑分表，分表会对业务代码造成根本性的影响，会产生长久的技术债务。

B+ 树和分表的问题我们就讨论到这里，下面我们简单分析一下 Buffer Pool 的设计思想和运行规律。

内存缓存 Buffer Pool

Buffer Pool 是在 MySQL 启动的时候，向操作系统申请的一片连续的内存空间，默认为 128MB，强烈建议任何一台 MySQL 服务器都根据自己的机器资源情况，增大配置的内存值，这玩意儿能把 MySQL 的性能提升多个数量级。

缓存池的大小

缓存池的大小由innodb_buffer_pool_size参数来管理，一般建议大家设置成系统可用内存的 75%，但是根据我的经验，对于普通的“冷热均衡”的数据库这样是合理的，因为热数据较少，但是如果你需要在短时间内（如几天）普遍地读写几乎所有表的所有数据，那这个比例最好设置在 50% 附近，否则在运行一段时间后将会爆内存（OOM 错误），MySQL 进程会被杀掉。

缓存池的基本结构

缓存池和磁盘数据一样，分为一个又一个 16KB 的页来进行管理。除了缓存“索引页”和“数据页”，缓存池里面还有 undo 页，插入缓存、自适应哈希索引、锁信息等。

虽然缓存池已经在内存中了，但是既然缓存池是一组 16KB 的页，那它就需要一个额外的内存索引来保存每一页的表空间、页号、缓存页地址、链表节点信息，这个结构叫控制块。N 个控制块和 N 个 16KB 数据页连在一起就是 Buffer Pool 占据那一段连续内存。

引入缓存池后，数据如何读写

缓存池中的 16KB 页是和磁盘上的页一一对应的，这就带来了读写两个方向的改变：

读数据时，如果该页已经在内存中了，则无需再浪费一次磁盘 IO。
写数据时，会直接将数据写入缓存中的页（不影响之后的读取），并在成功写入 redo log 之后返回成功。同时会将该页设置为脏页，等待后台进程将数据真正写入磁盘。

缓存池 LRU 算法

除了控制块和数据页，Buffer Pool 中还存在着管理空闲页的free 链表和管理脏页的flush 链表，我们不再深入了解。

但是，管理缓存生命周期的 LRU 算法我们不能放过，必须狠狠地了解它一下：

LRU 链表

传统的 LRU 算法只用一个链表就实现了“移动至头部”和“淘汰尾部”两个操作，什么 InnoDB 非要搞一个变体呢？还是因为 B+ 树：由于底层数据的非连续性，导致 Buffer Pool 会遇到两个比较严重的问题：预读失效和缓冲池污染。

预读失效

预读失效很容易理解，因为预读本质上是基于局部性对需求的一种预估，正常的 SQL 并不能保证每一条取出的数据都是大概集中的，例如取性别为女的用户，就需要跳着走完全表，预读失效非常正常。

LRU 链表将数据分为新生代和老生代两个区域，分别占据5/8和3/8的内存空间，预读时只插入老生代的头部，同时老生代尾部元素会被淘汰。当数据真的被读取时，这一页会被立刻转移到新生代的头部，并且会挤出去一个新生代尾部的元素进入老生代的头部，数据还在缓存中。

不知道大家发现了没有，这的操作的本质是给 LRU 算法加了一层 LRU 算法，减小了缓存粒度。

缓冲池污染

这个问题是非常符合本文主旨的一个问题：由于磁盘数据库拥有极大的体量，相比之下内存容量却十分捉襟见肘，所以在用内存来做磁盘缓存时，一旦需求不满足局部性，缓存会被迅速劣化：当一条 SQL 需要扫描海量的数据页时，其它表用得好好的热数据嘎的一下就被清出内存了，结果就是磁盘 IO 数量突然增加，系统崩溃。

于是 InnoDB 给“数据被读取时，这一页会从老生代转移到新生代的头部”这个操作加了个条件：在老生代里面待的时间要足够久。

这里面有两个点非常巧妙：

改变的是“转移页操作”所需要的条件，而且这个条件(即留存时间)的判断非常简单，只需要在加入老生代的时候增加一个时间戳就行，4 个字节，除此之外无需任何维护
采用时间而不是次数来做限制，更加符合数据库的最终用户——人的真实需求。读取次数可能因为技术原因而增加，时间不会。没有无缘无故的爱，更没有无缘无故的读取。

Buffer Pool 应该怎么优化

内存配置的越大越好：多一倍的内存，比多一倍的 CPU 更能提高数据库性能
减少对冷数据的随机调用：优化定时任务和队列的业务代码，避免这种情况
在大批量执行小修改的时候、尽量自己控制事务：由于 InnoDB 底层的数据隔离机制，让它的每一个写动作都是一个事务，所以如果你要在一次会话中写多行数据，最好自己控制事务，可以显著减少对缓冲池的影响以及磁盘 IO 数量
避免修改主键：修改主键的值会带来大量的数据移动，磁盘会不堪重负，缓存会疯狂失效

接下来

一万多字的 InnoDB 详解文章终于完成了，下一篇文章我们将在本文的基础上，细数四代分布式数据库的变迁：NewSQL、计算存储分离、Paxos、Shared-Nothing、列存储，并且详细分析国产数据库双雄 TiDB 和 OceanBase 的技术架构，看看市面上可用的这些分布式数据库，到底能不能支撑得住 500 万 QPS。

参考资料

mysql 最大建议行数 2000w, 靠谱吗？ https://my.oschina.net/u/4090830/blog/5559454
The CHAR and VARCHAR Types https://dev.mysql.com/doc/refman/8.0/en/char.html
MySQL InnoDB Java Reader https://github.com/alibaba/innodb-java-reader

相关日志：

高并发的哲学原理（七）-- 最难以解决的单点：数据库以及它背后的存储

JohnLui — Sat, 14 Jan 2023 16:37:44 +0000

《高并发的哲学原理 Philosophical Principles of High Concurrency》开源图书已经发布，简称 PPHC。地址：https://github.com/johnlui/PPHC

前面六篇文章，我们解决了 web 服务的百万 QPS 问题，从本文开始，我们将用三篇文章，尝试构建出百万 QPS 后端系统所需要的数据库。首先要明确，这里的数据库指的是关系型数据库，即满足 ACID 原则并用 SQL 语言进行操作的持久性（掉电数据不丢）数据库。当然，在追求高并发的过程中，我们将不可避免地接触到内存数据库，但我们一定要知道，内存数据库只是架构设计的一部分，而且不是最重要的部分。

数据库是个大单点

所有 web 系统都会经常面临这种需求：用户要一个一个注册，ID 不能一样；订单要一个一个下，两个订单的信息不能错乱。这其实就是最原始的需求——排队。逻辑上，无论数据库如何拆分，微服务如何设计，一定有一个资源是必须排队的，哪怕我们可以用“现在的时间换未来的时间”这种方式来进行性能优化（后面的文章还会提到），排队是必须存在的。

在常见的 web 系统架构中，关系型数据库就是那个最大的无法拆分的单点：在一个系统内，多个 API 调用所产生的多种行为，最终都要作用到同一张表上，这个系统的运行才能符合逻辑。这也是数据库最核心的价值：API 可以并发，数据库必须排队一个一个来。就像 Redis 之于 golang 协程，就像 Node.js 的单线程排队执行，数据库才是 web 服务的根，是保证最终计算结果符合预期的那个“队列”。

无论进程/线程/协程如何并发，数据库的自增、事务和锁都是原子化的。这种原子化能力恰好是前面的业务服务器能够多台并发的基础，也是多台服务器能够被称为“一个系统”的逻辑基础：如果两个系统的数据库不在一起，那他们就不是一个系统，就像拼多多有 7.5 亿月活用户，淘宝有 8.5 亿，你不能说“拼宝宝”电商系统有 16 亿月活用户一样。

这种哲学思想我们在最后一篇文章的终极高可用架构中还会用到。

数据库为什么是单点

数据库成为数据单点并不是自己决定的，而是系统架构“需要”一个数据单点，而数据库就是为了满足“数据单点”这个需求而被设计出来的。对于大部分需要记录到数据库里的信息来说，基于先来后到进行排队入库都是一个不可妥协的硬需求，否则在逻辑上数据就会出错。对于所谓的 NoSQL 数据库来说，连一个简单的 ID 自增都需要扫描全表才能做到，它是不能承担数据单点角色的。由于它不是为了承担数据单点而设计的，NoSQL 注定只能是关系型数据库用来提升性能的的副手。

关系型数据库的“关系”二字，指的是一个表内部的这些数据之间，拥有行和列两个方向的关系，这其实是另一种形式的“时间换空间”、“空间换时间”思想：提前约束这些数据，让他们以一定的规则存储在一起，写入的时候会慢一点，但是这样调用起来就简单又高效：例如无需全表扫描瞬间找出最大 ID、例如即便将海量数据存储在磁盘上，依然能够以很快的速度检索到满足某个条件的某一行、例如在快速定位到某一行后便可以快速取出连续多行的数据等等。

数据库是一个非常复杂的软件

关系型数据库就像空气一样充斥在后端技术里，但是可能很少有人想过一个惊人的事实：99.9% 使用 MySQL 的系统，其业务代码的复杂度都没有 MySQL 本身的复杂度高。

MySQL 为了实现关系型数据库四大原则，几乎把计算机的每一种资源都用到了极致：进程、线程、多核、网络、寄存器、内存、机械磁盘、固态磁盘。

写到这里，如果我们开始分析 ACID 实现的细节，岂不是落入了俗套，我们要不走寻常路，不背面试八股文，直接分析 MySQL 的底层原理。

数据库这个单点，单在哪里？

一般的技术文章一说到持久性原子性，就是什么 undo log、redo log、多版本并发、锁。我不这么看，下面我们从 MySQL 的基础功能开始思考。

MySQL 是整个 web 系统中唯一一个在意外掉电重启以后，还能保持数据不丢的组件，那它是怎么做到的呢？很简单，基于计算机上唯一一个断电不丢数据的磁盘实现的。所以，不用看什么*do log了，把它们全部当做磁盘文件就行了。

掉电不丢数据是磁盘的重要特性

事实上 MySQL 确实是完全依靠磁盘不丢数据的特性来实现的：如果你执行了update语句，那无论 MySQL 有多少级的缓存，多少种的日志，都得等到它成功将此次数据修改写入到磁盘上以后，才会给客户端返回成功状态。而文件的修改是有队列的，可以保证每一次写操作的可靠性。

当然，这里的写入磁盘，不一定指的是真的存到了那张表对应的数据文件里，也可以是*do log。如果此时服务器意外重启，那在 MySQL 启动以后，它还是会把自己刚才记录的这些*do log里的信息再默默地写入到磁盘上真正的表数据文件里。

“数据库单点单在哪里”的答案已经呼之欲出了：数据库的单点就单在了磁盘上。

存储技术简史

既然数据库的单点就是磁盘，那接下来我们就看看存储技术的发展简史。

集中式存储

集中式存储是一种采用独立的控制器（即计算机）控制大量的硬盘，再通过控制器对外提供多种不同层级的接口（硬件层面的 SAS/FC，软件层面的 SCSI/iSCSI/InfiniBand 等），以同时满足多个客户端、多种不同存储需求的产品。

集中式存储的兴起让IOE中的E大放异彩：就像前面提到的那台价值百万的负载均衡设备一样，EMC 的集中式存储通过双控制器开机热备 + 全冗余网络连接，再配合 SAN 交换机和双 HBA 卡，可以实现全冗余的存储网络架构，它性能很好，可以支持多台服务器连接使用，还非常稳定，只有一个缺点：贵。光是一个普通的 16 口 16G SAN 交换机，价格就已经超过了 40G 以太网交换机（交换容量甚至可以达到50Tbps以上）。更不要说一年也卖不出去几片的 HBA 卡了。而且，集中式存储设备本身更贵，非常贵，比两台标准 x86 服务器还要贵。

为什么集中式存储这么贵呢？因为它用非常高的硬件成本和服务成本，真的解决了大多数企业面临的存储问题：厂家负责上门部署，定期维护，你负责出高价，然后用就行了。集中式存储的本质是用高水平的硬件 + 硬件级全冗余 + 保姆式的技术服务，彻底搞定了存储这件难事。

分布式存储

进入云计算时代，分布式存储大放异彩：反正海量的 x86 服务器已经在机柜里运行着了，为什么不拿出一点点计算资源构建出一个省钱的分布式存储呢？而且从需求的角度来看，云计算的规模是在快速增长的，集中式存储很难满足这种速度的规模扩张。这个时候就需要分布式存储登场了。

分布式存储选择通过海量普通可靠性的硬件 + 软件的方式，将一群 x86 服务器通过以太网或者 InfiniBand 相互连接，将分散在每一台服务器上的机械磁盘和固态磁盘组织到一起，形成一个巨大的硬盘资源池。这个软件定义的存储集群可以做到和集中式存储一样的三高：高可靠性、高可用率、高性能。

高性能靠什么？

虽然我们说分布式存储也有高性能特性，但是，x86 架构下磁盘的性能其实不怎么样。近些年，随着分布式存储的市场占有率越来越高，单系统规模也越来越大，从云计算厂商到服务器厂商，都在想办法提升分布式存储各个部分的性能。除了“网络性能”和“缓存”在快速进步之外，x86 IO 系统的“绝对性能”也在快速进步，现在（2023 年 1 月），我们就站在 x86 IO 性能爆炸的前夜。

小型机的优势，x86 的劣势：IO 性能

《性能之殇》里面提到过 x86 的 IO 性能被架构锁死了¹。而小型机那边，IO 性能的上限非常高，甚至可以为存储子系统配置专门的 CPU。

今天，海量廉价的 x86 服务器集群在越来越快的网卡速率的协助下，在系统总容量和可用性方面已经超过了小型机，让小型机只能在它比较有优势的特定规模、特定行业的业务背后生存。但是，IO 性能不足是 x86 从娘胎里面带出来的弱点，而这个弱点直到最近两年才有了一些改善。

突飞猛进的 PCIe

最近几年，已经沿用了十年的 PCIe 3.0 突然开始大踏步换代，以两年一代的速度疯狂推进，每一次带宽都能翻倍，看起来进步很大。但是，当我们的目光从那惊人的 128GB/s（PCIe 5.0 x32）的数字上移开后，再仔细地端详一块主板上同时存在的 5.0、4.0 和 3.0 的插槽，就会发现一个更惊人的事实：4.0 和 5.0，是在基础电气属性不变，金手指的数量都完全保持不变的情况下，通过重定时器和重驱动器组件，“强上陆地神仙”的结果。而且，5.0 的插槽它就是 5.0 的，并不能拆成两个 4.0 来用，如果想插 4.0 的设备，也可以，但只能插一个：因为并不是水管变粗了，而是水管支持的流速提高了，这对接收端设备的容错能力也提出了更高的要求。

为什么英特尔一屁股坐到 PCIe 牙膏上了呢？为了下一代超级 IO 架构：CXL。

全村的希望 CXL

虽然第一颗支持 CXL 的服务器 CPU 刚刚上市两个月(AMD EPYC 9004 系列)，但不影响 CXL 技术成为“全村的希望”。虽然直到 2019 年英特尔才推出了 CXL 标准，但它不仅推动业界在三年之内火速推出了兼容 CXL 技术的 CPU（而且还是友商开发的），还吸纳了同样技术方向的两个竞争对手：OpenCAPI 联盟和 Gen-Z 联盟，成为了唯一的“新一代通用 IO 标准”。

凭什么呢？就凭 CXL 是英特尔向业界投入的一颗重磅炸弹：一次性放开了从 CPU 直接驱动的 DDR 内存到 NVME SSD 之间广阔的“无人地带”——基于 PCIe 5.0 技术，将 IO 技术推入了一个新时代。别忘了，PCIe 协议也是英特尔定义的。

内存、磁盘正在双向奔赴

最近几年，随着 NVME SSD 在服务器端的普及，内存和磁盘的性能边界正在逐渐模糊：十年前 SATA SSD 刚刚普及的时代，内存带宽和延迟大概为 100GB/S 60ns，而 SATA SSD 为 500MB/S 200μs，速度和延迟分别为1/200和3000倍；而今天内存和 PCIe 4.0 NVME 磁盘的对比为 150GB/S 100ns 和 7GB/S 18μs，这个差距已经缩小到了1/21和180倍。

CXL 补上了“存储器山”上 DDR 内存和 NVME SSD 之间的巨大空隙

神书《CS:APP》在第六章中提出了著名的“存储器山”理论²：离 CPU 越远的存储器容量更大延迟更高。

两个月前刚刚发布的 AMD 9004 系列处理器引入了 12 通道的 DRAM 内存，这对电路板的设计能力和制造成本提出了非常高的要求，同时对 CPU 内部的内存控制器的驱动能力也提出了很大的挑战，基本可以确定 DRAM 这个将一大块 DRAM 芯片在 Z 轴进行折叠而增加容量的技术已经走到了尽头，以后就是 CXL 的天下了。

CXL 提供了 IO（设备发现、初始化、中断等基础功能）、缓存（低延迟数据复制）、内存（统一地址编码）三个模块，一次性解决了海量内存扩展和多个级别缓存的需求。目前，支持 CXL 1.1 协议的扩展内存已经上市。

未来，双向奔赴的内存和磁盘将在 CXL 技术里胜利会师：容量和延迟的分布将会更加均匀，系统的宏观性能将进一步提升。

奋三世之余烈的终极目标

CXL 1 时代主要解决的是基本功能，2.0 要实现类似于 SAN 交换机技术的多对多内存池化，3.0 要构建 CXL 互联网络：实现软件定义内存集群，简单来说，就像上面说的那个分布式存储一样，用软件把内存给集群化。

内存被软件给集群化之后，还会给数据库架构带来巨大的变化：现在基于独立的 RDMA 网卡技术的计算与存储分离架构已经涌现出了 Snowflake、Amazon Aurora、阿里云 PolarDB 等优秀的商用数据库产品，如果内存都能被集群化，那“计算与存储分离”中的“计算”也会被颠覆，届时，“主从同步”四个字将会拥有全新的意义。

超高速网卡也需要 CXL 来解决

当下，x86 服务器界的各路厂商，都在绞尽脑汁地想办法将 400G 网卡塞进机箱。如果说，在不进行任何优化的情况下，利用 Linux 网络栈跑 TCP 只能跑到 5G 是因为软件架构的话，那 400G 网卡用不了就是纯纯的硬件限制了：400G 已经比八路内存的理论带宽都要高了，只要网卡数据还需要经过 CPU，只要还在用 DDR4/DDR5 内存，那 400G 网卡就是非常难以实现的。

CXL 技术给出了 400G 网卡的解决方案：将网卡和 CPU 分离，让他们各自拥有自己的内存空间，并且让 CPU 可以无障碍读写网卡芯片的内存空间。本质上，相当于重新定义了“网卡接到数据后存入内存”这句话里面“内存”二字的含义。

这个思想其实我们早就见识过了：浮点运算能力数百倍于 CPU 的 GPU，就是单独设计内存架构（称为显存），在自己体系内实现了超高性能的，然后直接使用 DP 协议输出 8K 画面，不需要让大量数据经过 CPU 和内存，就不会有性能瓶颈。

x86 内存技术演进番外篇

1. 最近十年内存其实一直在变慢

我们都知道，最近 10 年服务器 CPU 的核数开始爆炸，内存通道也从最开始的双通道一步一步发展到了今天的 12 通道，但是，和内存带宽比，还是 CPU 核数增长的更快一些：这些年，每个 CPU 核心能够分到的内存带宽一直在持续下降，这相当于每台虚拟机能使用的内存读写速度反而在变慢。

2. 英特尔对于 x86 内存体系的限制

前几年，微软统计了自己的服务器各项部件的总成本，惊讶地发现超过 50% 的服务器费用都拿来买内存条了³。内存不仅硬件成本高，现有的内存架构还让内存在虚拟机内部存在巨大的浪费：几乎每台物理服务器都浪费了大约 50% 的内存。而这其实是英特尔故意的。

x86 的内存子系统一直保持着封闭，直到这几年机器学习的崛起让人类社会对于服务器内存的需求又上了一个台阶，在英伟达的股价一次次冲高以后，英特尔才被迫开放了 CXL 标准，基于 PCIe 5.0 的高带宽，才让内存能够像硬盘一样自由扩充。

还记得我们的目标吗？一百万 QPS

一百万 QPS 的 API，在经过性能优化的电商业务中，我们假设每次 API 调用平均执行五条 SQL，那数据库 QPS 就是 500 万。稍微接触过一些高并发系统的人都能一眼看出，这是一个多么惊人的数字，对于开源 MySQL 来说，单机一万的 QPS 就已经非常惊人，500 万，简直就像开玩笑。别急，慢慢往后看，这真的有可能实现。

接下来

下一篇文章，我们将开始探寻数据库性能优化技术：我们会讨论 innodb 三级索引、内存缓存等传统性能优化技术，还会讨论 KV、列存储等从底层引擎入手的新技术，结合“找出单点，进行拆分”思想，尽可能地提升单台数据库的极限性能。

参考资料

x86 的 IO 性能被架构锁死了 https://lvwenhan.com/tech-epic/498.html
CS:APP 的存储器山理论 http://csappbook.blogspot.com/2017/05/a-gallery-of-memory-mountains.html
微软超过 50% 的服务器费用都拿来买内存条了 https://www.semianalysis.com/p/cxl-enables-microsoft-azure-to-cut

相关日志：

高并发的哲学原理（六）-- 拆分网络单点(下)：SDN 如何替代百万人民币的负载均衡硬件(网关、LVS、交换机)

JohnLui — Mon, 09 Jan 2023 16:12:40 +0000

《高并发的哲学原理 Philosophical Principles of High Concurrency》开源图书已经发布，简称 PPHC。地址：https://github.com/johnlui/PPHC

上一篇文章的末尾，我们利用负载均衡器打造了一个五万 QPS 的系统，本篇文章我们就来了解一下负载均衡技术的发展历程，并一起用 SDN（软件定义网络）技术打造出一个能够抗住 200Gbps 的负载均衡集群。

负载均衡发展史

F5 创业史

1996 年，华盛顿大学的几个学生共同创建了一家生产负载均衡设备的公司，并用美国人民的老朋友——飓风的最高等级 F5 作为品牌名，以表示他们的设备可以抗住最狂暴的网络流量。彼时，互联网的规模每 100 天增长一倍，这也让 F5 在成立三年后火速上市。2001 年，F5 公司在经历了互联网泡沫后，顺利地把设备卖进了银行等大型机构，因为 F5 比微软和甲骨文都更有前瞻性：他们的 iControl 系统可以提供 API，让大型机构自己开发软件来控制通过负载均衡设备的所有流量。

早在 2001 年，软件的威力就已经开始展现。

TMOS 软件平台

2003 年非典暴发，电子商务，网络点餐甚至是网络新闻都迎来了爆发式的增长。2004 年，F5 上市了新一代产品：包含 TMOS 软件平台的全套硬件设备，一次性解决了网络访问、数据中心同步访问、远程办公、应用防火墙等多种需求。此后，市场上 F5 公司的产品越来越具有统治力。

迈向应用交付

2006 年以后，传统的 IP 层负载均衡技术开始向应用层发展，F5 等相关设备厂商也紧跟潮流开始推广“应用交付”的概念，开发了很多结合了负载均衡和应用网关的产品，这之后的十年，是传统负载均衡硬件厂商的最后荣光。

2019 年，F5 Networks 以 6.7 亿美金的价格收购了 Nginx，硬件厂商和软件厂商实现了一次梦幻联动，也侧面说明了我们确实已经迎来了软件定义网络的大时代。

顺便提一句防火墙

实际上，在今天的企业网络架构中，专业的网关设备都已经消失，取而代之的是一个看起来不是网络设备的网络设备：防火墙。特别是具备应用识别能力的“下一代防火墙”（没错，就是这个中二的名字），更是将防火墙设备的价值推上了巅峰，并一次性让企业级路由器和中低端负载均衡全部退场，这又是一个软件战胜硬件的故事。

一个小八卦，下一代防火墙行业的个中翘楚 Fortinet 公司，由两名出生于北京的清华大学老师的孩子 2000 年在美国创办。

负载均衡一代目：硬件负载均衡

2002 年 2 月，戴尔为 PowerEdge 1650 服务器第一次配上了千兆以太网。当时，负载均衡的主流实现还是基于硬件的，或者说是基于“软硬件一体化解决方案”的。在当时，服务器 CPU 的单核性能还很低，甚至核心数都很少，网卡芯片技术也没有今天这般牛皮（相比于下面讲的 NPU），所以当时想用运行在标准操作系统(Windows/Linux)内的软件来实现千兆软网关还是一个“前沿探索项目”。更不要说万兆负载均衡了：PowerEdge 1650 发布的四个月后，万兆以太网的标准“IEEE 802.3ae 10 Gb/s 光纤以太网”才首次发布，距离万兆网卡在服务器端普及更是还有十多年的光景。

不为人知的是，千兆以太网的光纤标准 1998 年才发布，千兆以太网的双绞线标准 1999 年才发布，而到了 2002 年，万兆以太网光纤标准就已经发布了。实际上，千兆以太网在消费端开始普及，也已经是 2010 年的事情了。

21 世纪的头十年，最优秀的超千兆解决方案是：利用二层网络的链路聚合协议，使用多个千兆口同时负载均衡，实现超千兆的速度。而且当时能做到数 G 带宽的负载均衡设备动辄上百万，价格惊人，有需求的终端客户简直就是大冤种，不过在那个移动通信基站都要完全进口的年代，哪个中国人不是大冤种呢。

这些网络硬件厂商，其实都是软件厂商，只不过他们选择将自己的软件装在这些黑色的铁盒子里面卖，这样的产品质量更稳定，更重要的是：这样更贵。相比于买一个看起来可以随意拷贝盗版又虚无缥缈的软件，人类社会落后的官僚体系也更容易接受购买昂贵的实物。具体的技术分析请往下看。

负载均衡二代目：软件负载均衡

最近十年，随着云计算的兴起，从硬件设备到 IT 基础设施都发生了翻天覆地的变化，现在，硬件负载均衡已经开始逐步退场：云服务商们使用软件定义网络（SDN）技术，构建出了一个低成本高性能的新世界。

今天，一台总价 3 万元的通用 X86 服务器搭配 100G 以太网卡，使用基于 DPDK 开发的用户态应用程序在 Linux 上发小包，很容易就可以跑满 100Gbps 的网卡带宽¹。

这个 tweet 也许有些夸张，但是这就是我们当下的世界：软件正在定义网络的一切。

价值百万的硬件设备

这是一台 F5 生产的售价百万的硬件负载均衡设备，它只用了一颗 4 核 8 线程的至强 x86 CPU，就实现了 40G 的四层负载均衡能力和 18G 的七层负载均衡（应用网关）能力。

这台设备内部有两个控制器和四个接口插槽，可以实现“全双活”，即控制流量的“CPU 内存主板”和“网络接口”都是双份，在任意一个资源意外宕机后，另一个备用资源可以无缝顶上，可以实现无丢包的硬件级高可用。同时，这台设备背后的电源适配器应该至少有四个，可以实现运行时热替换，甚至连风扇模组都是冗余的，可热替换的。

下面我们正式开始利用软件的力量，一步一步在标准 x86 服务器上面跑的标准 Linux 系统内，构建出一个和这台硬件负载均衡设备高可用性一致，且带宽可以达到 200G 的负载均衡集群。

让我们先从交换机技术开始讲起。

交换机

大家还记得上一篇文章中的负载均衡架构图吗：

这张图里就暗藏了一个交换机。

左侧，客户端和负载均衡器之间是使用公网 ip 通信的，他们俩是在全球互联网内的两台对等设备，只是数据包经过了很多个真·路由器的“路由”操作，双方才能收到对方发送的数据包。

右侧，负载均衡器和上游服务器通信的时候采用的是内网 ip：10.0.0.100 和 10.0.0.1，他们俩是怎么通信的呢？通过交换机。

路由器和交换机巨大的价格落差

一台能够跑满千兆 NAT 的路由器，最低价格大概在 300 块，但是一个所有口都能同时跑满全双工千兆（上下行同时跑满千兆）的五口交换机，你知道多少钱吗？39 块钱，包邮。

为什么呢？因为交换机干的事情更为简单，可以用非常低端的芯片满足需求。

交换机的工作原理

网关是通过关联两个五元组，再对数据进行修改而发挥作用的。交换机则更简单：只维护一个 MAC 地址在哪个网口上的 HASH 表即可，无需对数据进行任何修改。该表的 key 为 48 位长，value 是个 tinyint：4 口交换机可用 2 bit 表示，8 口交换机可用 3 bit 表示，现在知道为什么家用交换机都是 8 口的了吧。

交换机的工作模式简单表述如下：

当交换机收到一个 MAC 包时，会查询目的 MAC 地址在哪个网口上
若查询不到，交换机会把这个 MAC 包发送到所有口上，包含发来数据包的那个口
等到这个 MAC 包被响应，这个 MAC 地址和口的关系就被交换机学习到了，下次就不需要发给所有口了
若查询到了，则单独发送到目标网口上
全程不会对数据包进行任何修改

除了不需要修改数据包之外，交换机也不需要和任何设备通信来建立和更新 MAC 表，只需要监听途径交换机的所有数据包的源 MAC 地址即可。

交换机技术的优缺点

优点

足够简单，所以硬件成本可以做到足够低
不需要和任何设备通信即可支持新设备接入，完全自学习
扩展性无敌，交换机可以随便级联，只要 MAC 表容量够，理论上可以插成一颗无限层级的树

缺点

有网络风暴的风险：数据包被无脑的发到所有口，可能会被别的交换机再发回来，到时候你来我往，跑满线速，造成正常数据包的拥堵
网络回环非常恐怖：如果把交换机的两个口用一根线插在一起，那这台交换机会瞬间断网，左右互搏之术对交换机这种低层级设备来说过于困难了

当然，现在主流的商用二层交换机已经拥有了很多的三层特性，这些缺点通过各种检测技术都已经解决了。

大家不要觉得交换机原理没什么用，SDN 是一种跨越了一二三层的技术，MAC 层也是我们构建 200G 负载均衡集群的重要技术战场

准备工作做完了，下面我们开始搭建负载均衡集群。先从这一切的基础—— LVS 开源软件说起。

LVS 登场

章文嵩创建 IPVS

1998 年，在章文嵩博士二年级的时候，他发现 Cisco 的硬件负载均衡器要卖几万美金，觉得这玩意儿不难写，于是利用两周的课余时间创建并开源了 LVS（当时叫 IPVS）。时至今日，LVS 技术创造的商业价值已经无法计算，互联网上的绝大部分数据包，都会被 LVS 或者承袭 LVS 思想的软件处理。

合并进 Linux kernel

2004 年，LVS（IPVS）被合并进了 kernel 2.4，从此开始，所有 Linux 都拥有了变身为负载均衡器的能力。

LVS 基本原理

其实一句话就能说清：通过修改 MAC 层、IP 层、TCP 层的数据包，即实现了一部分交换机和网关的功能，指挥流量到达真正的服务器上。

LVS 有三个常用模式：

NAT 模式：即网关模式，双向流量均经过网关转发，性能开销最大
TUN 模式：类似于单臂路由，性能高且可跨越机房
DR 模式：只能用在局域网，但是性能惊人，因为回程流量直接走局域网

我们以最能体现 LVS 思想的 DR 模式为例，展示 LVS 的基本原理。

DR 模式架构图

DR 模式数据包推演

DR 模式下，LVS 只负责篡改数据包，不负责充当网关，所以我们还是需要一个网关在公网 ip 和私网 ip 之间进行 NAT 转换。我们依然假设客户端 ip 为 123.123.123.123，它发起了一个针对 110.242.68.3 的 80 端口的 HTTP 请求。

当网关接收到一个发送给 110.242.68.3 的数据包时，发现协议为 TCP，目标端口为 80，查询自己的 NAT 表发现内部 ip 为 10.0.0.100（VIP，即虚拟ip），内部端口为 80，于是网关向局域网发出了一个 ip 包。由于端口都是 80 不变，协议都是 TCP 不变，所以本次网络请求中，有四个数据非常关键：源 ip 地址，目的 ip 地址，源 MAC 地址，目的 MAC 地址。

客户端发给网关的数据包情况为：
1. 源 ip：123.123.123.123
2. 目的 ip：110.242.68.3
3. 源 MAC：客户端 MAC
4. 目的 MAC：网关 MAC
网关向局域网发出的数据包情况为：
1. 源 ip：123.123.123.123
2. 目的 ip：10.0.0.100（变了）
3. 源 MAC：网关 MAC（变了）
4. 目的 MAC：LVS MAC（变了）
LVS 接到该数据包后，会选择一个后端服务器，假设它选中的是 10.0.0.1 来真正处理请求，则 LVS 会对数据包进行如下修改后，再发送给 10.0.0.1：
1. 源 ip：123.123.123.123
2. 目的 ip：10.0.0.100
3. 源 MAC：LVS MAC（变了）
4. 目的 MAC：10.0.0.1 的 MAC（变了）
10.0.0.1 在收到该数据包后，发现这个包的目的 MAC 地址确实是自己，而且目的 ip 10.0.0.100（VIP）也是自己，于是对该数据包进行正常的处理，然后将处理结果发送出去：
1. 源 ip：10.0.0.100
2. 目的 ip：123.123.123.123
3. 源 MAC：10.0.0.1 的 MAC
4. 目的 MAC：网关 MAC（因为目的 ip 不在“ip+子网掩码”所确定的局域网范围内，所以该数据包会被发送给网关）
网关收到返回的数据包后，通过查询“五元组关系表”，对端口和 ip 信息做出正常的 NAT 修改后，将数据包发送回 123.123.123.123，请求结束。

大家可以看出 DR 模式的特点：

LVS 只需要处理正向数据包，通常正向数据包（请求）要远小于反向数据包（响应），所以带宽占用较低
反向数据包走的是标准的二层以太网，每台上游服务器都可以跑满自己的线速
只能在同一个二层网络下工作（即同一个局域网），且安全性较差
需要在每一台上游服务器上都将该 VIP（10.0.0.100）配置为 lo（本地回环）接口的 ip
需要让每一台上游服务器都只响应真实 ip 如 10.0.0.1 的 ARP 查询请求，如果一不小心回复了针对 VIP 的 ARP 请求，将会立刻天下大乱：局域网内有多台机器同时声称自己拥有 10.0.0.100 这个 ip，交换机直接疯掉

在生产环境部署中，由于 LVS 集群是所有流量的入口，所以其可用性需要做到非常高，一般不会只部署在一个机房里，所以现实中最常用的是 NAT 模式：双向流量均经过 LVS 集群，这样便可以实现多地多中心的跨公网多活。

LVS 设计思想

通过上面的过程，你应该能看出来 LVS 的运行原理了：它通过在 LVS 和上游服务器上配置虚拟 ip，以对数据包进行篡改后再发送为手段，在标准以太网模型下构建出了一个可行的负载均衡系统。它不像交换机那样完全不修改数据包，也不像网关那样维持一个对应关系并修改很多东西，它篡改了数据包，但不多，所以可以实现非常高的性能。

内核态

LVS 的数据处理组件 IPVS 运行在内核态，避免了用户态的进程切换开销，再配合低负载的 DR 模式，可以进一步提升性能。

由于有内核态加持，LVS 比 HAProxy 和 Nginx 的单机性能都要强很多。

专业的负载均衡协议：OSPF/ECMP

OSPF：开放式最短路径优先协议，一种基于链路状态的内部网关协议。每个OSPF路由器都包含了整个网络的拓扑。并计算通过网络的最短路径。OSPF会通过多播的方式自动对外传播检测到的网络变化。

ECMP：等价多路径协议。即当存在多条不同的链路到达同一目的地址时，利用ECMP可以同时使用多条链路，不仅增加了传输带宽，还可以无时延、无丢包的备份失效链路的数据传输。如果利用传统的路由算法，只能利用其中的一条链路进行数据的传输。

LVS 是运行在标准以太网模型下的负载均衡软件，配合 Keepalived 可以实现高可用。而 ECMP 协议是专业的多链路路由协议，可以实现不丢包的多活，我们下面还会用到。

LVS 将网关这个单点拆成了“定向”和“转发”

LVS 就是网关型负载均衡继续拆单点的结果：LVS 自己只承担数据包重定向工作，将转发留给基础网以太网来解决，在单机上实现了非常高的系统容量。在最新的服务器硬件上，单个 LVS 即便在开销更大的 NAT 模式下也可以实现大约 20G 的 TCP 带宽²。

Keepalived 高可用

LVS 单机 20G 的带宽显然和我们 200G 的目标还相去甚远，但是我们接下来要做的第一件事并不是提升系统容量，而是先提升系统的稳定性：搭建高可用架构。

Keepalived 是一个非常优秀的搭建高可用集群的开源软件，它最开始就是为了和 LVS 配合而出现的，主要的作用是构建一个自选举集群。它支持 3 台控制器集群独立部署，也支持部署到应用机器上。它和 LVS 一样基于虚拟 ip 技术，可以在任意标准以太网内运行。

Keepalived 运行原理

Keepalived 运行原理说起来其实非常简单：

两台机器上都配置同一个虚拟 ip（VIP）：即两台机器的真实 ip 分别是 10.0.0.101 和 10.0.0.102，但是虚拟出一个 ip 10.0.0.100，这个 ip 不属于任何物理设备，可以在两台机器之间任意切换绑定
两台机器频繁通信，通过分数计算确定哪台机器的分数更高，由这台机器向局域网发送 VRRP 组播报文宣称 VIP 在我这里
当分数高的那台机器宕机，或者断网，或者检测到服务进程消失（例如 Nginx 挂掉），分数低的那台机器会在极短时间内立刻顶上，宣称 VIP 在自己这里
发送给 VIP 的数据包会在短时间失效之后由新机器承接（实测中断时间小于 1 秒），实现集群高可用

高可用 LVS 集群

LVS 和 Keepalived 配合，基于多台物理机，可以实现一个高可用的负载均衡集群，架构图如下：

如果 Master 因为任何原因失效（硬件故障，机房断电，人为误操作，光缆挖断，火灾地震），Standby 机器就会迅速顶上，接管流量，实现高可用的目的。

金融级项目可以在一个城市跨三个机房做三节点的 Keepalived 集群。为什么不做多城市集群？因为多城市已经属于“两地三中心”的高可用技术领域，一般不在二层网络上做，跨城市专用光纤的建设费用是非常高的，城市内拉光纤就便宜多了。我们最后一篇文章会讲终极高可用架构。

Keepalived 也可以用在其他组件上实现高可用

我司办公区自建机房内也部署了一些非关键业务，其性能要求并不高，所以我选择单独部署 Keepalived：和 Kong 网关配合提供高可用网关；和 MySQL 配合做双主双活集群；和 Apache 配合做一个跨越 4 台物理机的虚拟机集群，提供高可用 HTTP 服务；等等其它案例不再赘述。

从 20G 到 200G

有了 Keepalived，我们就有了集群高可用的基础，下面我们开始啃硬骨头：从 20G 到 200G。

LVS 单机性能为何会卡在 20G

最新的 AMD EPYC 9654 服务器 CPU 有 96 个物理核心，双路平台共有 384 个 vCore，但是 LVS 单机性能依旧徘徊在 20G 附近，为何性能无法继续提升呢？因为 Linux 网络栈已经达到性能极限了。

Linux 网络栈优化

由于 LVS 基于 kernel 里的 netfilter，依赖 Linux 网络栈，导致进程切换需要读写内存，数据包的发送和接收也要读写内存，在极高的带宽需求之下，相对耗时的内存读写就成了阻碍性能进一步提升的最大障碍。DPDK 和 NPU 硬件卸载就是这个问题的两个解决方案。

DPDK

DPDK 是 Intel 开源的高性能网络数据处理框架，运行在用户态的进程通过申请大页内存和轮询代替中断两个关键特性，给高速率网卡提供了一个高性能解决方案。它的 CPU 亲和性、多核调度架构、内存 NUMA 优化等基础架构又进一步推高了性能，最终让它成功脱颖而出成为用户态网络界面框架的首选。

爱奇艺开源的 DPVS https://github.com/iqiyi/dpvs 就是 DPDK 技术在负载均衡领域的成功运用。在 10G 网络下发送 64 字节的小包进行测试，DPVS 可以做到标准 LVS 的五倍性能。在这里我们保守一点，对折一下 2.5 倍，那 DPVS 的单网卡性能极限就是 50G。

网卡芯片硬件卸载

最新的 NPU 已经可以支持很多的硬件卸载特性：IP 分片、TCP 分段、小包重组、checksum 校验、硬件 QOS，以及最重要的 VXLAN 的剥离和插入：此功能是 DPVS 的重要组成部分，可以减少数据流互相干扰，大幅提升系统总容量。

此外，RDMA 技术也是网卡芯片的一大进步方向，我们将会在后面讲数据库的计算和存储分离的时候详细了解。

全局锁优化

除了 Linux 网络栈的限制，LVS 本身架构上的全局锁也是一个突破口，全局锁导致了海量的 CPU 核心无法被利用，我们可以借鉴阿里云的处理思路：

数据包亲和性优化

阿里云通过 RSS 技术把同一个五源组报文扔到同一个 CPU 上处理，保证入方向的所有相同连接上的报文都能交给相同的 CPU 处理。同时在每个核在转发出去时都用当前 CPU 上的 Local 地址，通过设置一些 fdir 规则，报文回来时后端服务器访问的目的地址就是对应 CPU 上的 local 地址。这样就能实现这一条连接上面左右方向的报文都被同一个 CPU 处理，将存储“五元组对应关系”的内存数据库在不同的 CPU 核心上隔离开，这样就可以利用多个 VIP 来实现整体系统容量的线性提升³。

性能问题还是要靠架构解决

当单网卡性能极限来到了 50G，该怎么将集群性能提升到 200G 呢？插四块网卡行不行呢？理论上可行，但是现实中这么大的流量的系统一定要使用架构来提升系统容量，因为还需要解决高可用问题。

200G 负载均衡集群架构图

下面我们从左到右对这个架构进行解析。

1. 拆除 ip 单点：朴素的 DNS

基于 DNS 技术做单域名多 ip 扩容曾是第一代负载均衡技术：朴素的 DNS 协议可以将用户的终端流量直接导向全国多个机房，实现真·性能倍增，这种技术特别适合 web 1.0 时代的静态网页，也适合搜索引擎等没有数据同步需求的服务。

在当年电信、网通、铁通、教育网之间只有 40G 小水管的年代，DNS 技术极大地提升了普通用户获取网络资源的速度，提升了用户体验：引导每个运营商的用户访问放在该运营商机房的服务器，可以实现“手搓 CDN 架构”。最后一篇文章我们还会谈到 DNS 技术在终极高可用架构中的价值。

经过 DNS 拆分，每个路由拥有一个公网 ip，承载 100G 带宽，注意，此处的路由真的是路由，并不是网关，它只需要告诉每一个数据包该到哪儿去即可。这个架构中的网关其实是后面的 LVS 充当的。而硬件路由设备承受住 200G 带宽甚至都不需要上高端的数据中心核心设备。

2. 拆除交换机单点：OSPF/ECMP 路由技术

上图中的路由_1和路由_2采用支持 ECMP 的硬件设备或者软件路由来充当，他们会把流量平均分给两个交换机。每台交换机承载 100G 带宽，对交换机来说简直就是洒洒水，2 万块人民币的硬件交换机就能接近 24 x 100G 全线速交换（二手的甚至只要六千块）。

3. 拆除服务器单点：LVS 单机双网卡四网口

每台 LVS 服务器都安装双口 100G 网卡 2 张，共有四个网口，这样单机可以实现 50G x 2 的极限性能。每个网卡上面的两个网口，分别连接两台交换机，可以在实现了高可用的同时保证协议速度(线速)不会成为瓶颈。

4. 天下无单点：全冗余架构

大家可以看到，从左至右，整个架构的每一层的每一个节点，都和左边一层的所有节点进行连接，这种全冗余架构可以满足在任意一台设备宕机的情况下，整个系统依然可用，甚至系统容量都能维持不变。

如果某台路由宕机，则另一台路由会将它的公网 ip 接过来，可以实现分钟级故障恢复（主要是公网路由表可能更新缓慢）。

如果某台交换机宕机，则左侧的路由通过 ECMP 及时调整路由配置，可以实现秒级切换。

如果某台 LVS 服务器宕机：Keepalived 机制会让 Standby 设备在 1 秒之内顶上。

系统容量计算

对于整个系统来说，四台安装了双网卡的 LVS 服务器，2 主 2 备，在两个公网 ip 入口的情况下，可以实现 50G x 2 x 2 = 200G 的总带宽，并且任意一台设备宕机不影响系统总容量。

200G 并不是这个系统的极限，如果我们让一组的两台 LVS 服务器使用两个 VIP 做互为主备的双活的话，可以把整个系统的容量提升到理论极限 400G。下面我们分析一下各种单项资源的性能极限：

单个公网 ip：最大带宽为系统最大容量 200G
单个 VIP：最大带宽为 100G
单个数据流：最大带宽为单网卡性能极限 50G

还记得上面那台 100 万的硬件负载均衡器吗，他的最大 L4 带宽只有 40G，而我们这一套 200/400G 的设备要多少钱呢？

1x2 + 2x2 + 3x4 = 18万

额外的优势

花 18 万搭建一套图中的设备，不仅可以搞出一套 200G 的集群，而且图中的路由和交换机还有大量的容量可以用于其他业务。

更重要的是：LVS 集群相比于硬件负载均衡设备是可以轻松控制的，是可编程的，这对于右侧上游服务器的网络架构规划十分有利。对于云计算厂商来说，可以开发更丰富的功能来提供更复杂的服务（例如计算和存储分离的数据库），提升硬件资源的利用率，同时可以提供更复杂的功能给云平台用户使用：

软件带来的无限可能才是这套配置最核心的价值！

彩蛋

殊途共归：硬件厂商的软件设计

这是 H3C 集团 ComwareV7 通用操作系统的架构图，当下 H3C 正在销售的产品中，除了网络边界设备（如防火墙）外，其余几乎所有的交换机、AC、AP 等以局域网为主战场的设备已经全面采用了该系统。和上一代 V5 相比，最大的变化就是把系统内核切换到了 Linux kernel。

这张图中最重要的就是那根“细细的红线”：网络管理进程完全位于用户态。这其实就是 DPDK 思想：传统的 UNIX 网络模型已经无法应付单机 10G 的速度了，需要读写内存的进程切换太慢了，必须要从底层网络数据处理流程上革命：抛弃操作系统提供的网络栈，直接在用户态接管所有网络流量，实现更高性能。

为了提高软件稳定性，H3C 也在系统内开发了一些高可用技术，和我们负载均衡集群高可用的设计思想不谋而合，异曲同工：

支持单播、组播和热迁移的高可靠 IPC(进程间通信)技术：对应的是双机热备以及 OSPF/ECMP、VRRP 协议等
多进程主备选举：对应的是 Keepalived 集群选举
进程级内存备份(实时热备进程的内存，用于快速故障恢复和主从切换)：对应的是 OSPF/ECMP 不丢包多活技术、服务器的内存镜像技术

我对于设备故障的经验

在机房硬件设备中，最容易损坏的肯定是磁盘（硬盘），因为它是在不断磨损的，即便是 SSD 也会随着时间的流逝寿命逐渐丢失，哪怕装在盒子里不通电也一样。但是硬盘之后，容易宕机或者损坏的是什么大家应该就猜不到了。

首先是断电：数据中心因为各种问题断电是最常见的故障，这个故障的概率甚至要高于软件引发的故障和电源适配器的故障。

其次是内存失效：内存以及内存插槽，内存电路，似乎是今天服务器硬件之中除了磁盘之外最容易坏的东西，马上就要进入 DDR5 时代，内存功耗又上了一个台阶，恐怕故障率会进一步上升。

然后是网络线材和供电线材接口的问题，时间长了松了或者进灰了，就会丢包或者重启。2011 年震惊世界的中微子超光速事件，就是插头松了导致的。

最后是高温引发的宕机：特别是 GPU 服务器，一旦服务器或者机房的散热系统出现问题，服务器很容易就主动限制性能甚至关机。

其它的，硬件网络设备（路由器交换机）故障、彻底挖断光纤、CPU 损坏、电源转换器寿命耗尽、主板电池故障、地震火灾洪水等，可能在一台服务器的上架寿命之中都完全无法遇到。

还记得我们的目标吗？一百万 QPS

通过本文构建的这个 200/400G 负载均衡集群，配合多个应用网关，以及后面海量的物理服务器，我们终于成功实现了一百万 QPS 的目标。但是，这就是一百万 QPS 的全部了吗？当然不是，这只是 web 服务层面的百万 QPS，在真实世界中，数据库才是那个最难解决的单点。

接下来

下一篇文章，我们将直面最难以解决的单点：数据库以及它背后的存储，探寻IOE中最难去掉的那个E。

参考资料

Envoy 作者 Matt Klein 2017 年的一篇英文博客 Introduction to modern network load balancing and proxying https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236
用dperf测试LVS的性能数据 https://mp.weixin.qq.com/s?__biz=Mzg5MjcyNzY4Mg==&mid=2247483684&idx=1&sn=9a065f97f1a239efbb371fedde3b8d3e
高性能负载均衡设计与实现 https://zhuanlan.zhihu.com/p/29949340

相关日志：

高并发的哲学原理（五）-- 拆分网络单点(上)：应用网关、负载均衡和路由器(网关)

JohnLui — Fri, 06 Jan 2023 08:09:41 +0000

《高并发的哲学原理 Philosophical Principles of High Concurrency》开源图书已经发布，简称 PPHC。地址：https://github.com/johnlui/PPHC

上一篇文章的末尾，我们提到了一个假想出来的五万 QPS 的系统，以及这种规模的系统架构中必然存在的负载均衡器，那本篇文章我们就来一起利用负载均衡搭建一个能够支撑五万 QPS 的系统。

“监听 HTTPS 443 端口的进程”这个单点

之前，我们拆出了“监听 HTTPS 443 端口的进程”这个单点，并用 kong 网关来承载了这个单点。目前，在 2 vCore 的虚拟机上，2000 QPS 的压力对应的大约是 20% 的 CPU 占用率，经过换算我们可以知道：假如 kong 的性能可以随着核心数增加而线性提升的话，在维持最大 40% CPU 占用率的情况下，需要：

(50000 / 2000) 2 (20% / 40%) = 25 核

在这里我们先假设我们搞了一个 25 核的虚拟机，接住了这五万 QPS（实际上接不住，我们后面会说），那这个 Kong 网关到底是什么玩意儿呢？它就是标题中的“应用网关”。

应用网关

应用网关，又称 API 网关，顾名思义，它就是所有 API 请求的大门：自己接下所有的 HTTP/HTTPS/TCP 请求，再将请求转发给真正的上游服务器。而这些上游服务器可能是一堆虚拟机，也可能是一堆容器，甚至可以是多个数据中心各自的应用网关。由于应用网关做的事情非常少，所以它能支撑很高 QPS 的系统。

常见的应用网关软件有 HAProxy、Nginx、Envoy 等，而 Cisco、Juniper、F5 等一体化设备厂商也有相关的硬件产品。

应用网关除了提升系统容量外，还有很多别的优势。

1. 解放后端架构

经过对应用网关两年的使用，我现在认为所有系统都应该放在应用网关的背后，包括开发环境。

应用网关对后端架构的解放作用实在是太大了，可以让你在后端玩出花来：各种语言、各种技术、各种部署形式、甚至全国各地的机房都可以成为某条 URL 的最终真实服务方，让你的后端架构彻底起飞。

2. TLS 卸载

终端用户访问应用网关的时候采用的是 HTTPS 协议，这个协议是需要对数据进行加密解密的，应用网关非常适合干这件事情，而背后的业务系统只提供标准 HTTP 协议即可，降低了业务系统的部署复杂度和资源消耗。

3. 身份验证和安全性提升

应用网关可以对后端异构系统进行统一的身份验证，无需一个一个单独实现。也可以统一防火墙白名单，后端系统防火墙只对网关 ip 开放，极大提升了后端系统的安全性，降低了海量服务器安全管理的难度。甚至可以针对某条 API 进行单独鉴权，让系统的安全管控能力大幅提升。

4. 指标和数据收集

由于所有流量都会经过网关，所以对指标进行收集也变的简单了，你甚至可以将双向流量的内容全部记录下来，用于数据统计和安全分析。

5. 数据压缩与转换

应用网关还可以统一对流量进行 gzip 压缩，可以将所有业务一次性升级到 HTTP/2 和 HTTP/3，可以对数据进行格式转换（XML 到 JSON）和修改（增加/修改/删除字段），总是就是能各种上下其手，翻云覆雨，随心所欲。

负载均衡

应用网关的另一个价值就是负载均衡了：可以将请求的流量按照各种比例分发给不同的后端服务器，提升系统容量；可以做红蓝发布和金丝雀发布；可以针对流量特点做灰度发布；可以主动调节各个后端服务器的压力；屏蔽失效的后端服务器等等。

低负载下应用网关和负载均衡可以是同一个软件

虽然应用网关和负载均衡是两个不同的概念，但在低负载系统里，他们两个往往由同一个软件来扮演，例如前面说到的 Kong 网关就同时具备这两个功能。

拆分应用网关

一个五万 QPS 的系统，是无法使用 25 核的单机安装 Kong 网关来承载的，因为此时单机 TCP 连接数已经达到了十万以上，在这个条件下强如 Nginx 也达到性能极限了，性能不再增长甚至会开始下降，用户体验也会迅速变差。此时，我们需要对应用网关进行拆分。

应用网关怎么拆

逻辑上，应用网关执行的是“反向代理+数据过滤”任务，并没有要求应用网关只能由一台服务器来承接，换句话说，应用网关不是单点，只要多个节点的行为一致，那就可以共同承接这五万 QPS 的真实用户流量。

我们只需要在多台机器上装上同样版本的应用网关软件，然后在他们之间同步配置文件即可。Kong 采用的策略是让多个实例连接同一个PostgreSQL数据库，每五秒从数据库获取一次最新的配置，如果数据库挂掉，那就保持内存中的现有配置继续运行。

Kong 集群追求的是“最终一致性”，不追求五秒的得失，反而让系统格外地容易扩展，格外的健壮，最后一篇文章我们还会见到使用类似思维的“DNS 分布式拆分”。这个朴素的分布式架构颇有毛子暴力美学的风范，后面我们讨论列存储 clickhouse 的时候还能见到。

如果单个应用网关扛不住五万 QPS，那我们搞一个负载均衡器放在应用网关的前面，架构图如下：

分层的网络

负载均衡器为何能抗住五万 QPS

看到这里有人可能会疑惑，既然单机的 Nginx 都顶不住五万 QPS 带来的 TCP 资源开销，那负载均衡器如何抗住呢？因为负载均衡器承载的是比 Nginx 所承载的 TCP 更下面一层的协议：IP 协议。

至此，我们正式进入了网络拆分之路，这条路很难走，但收益也会很大，最终我们将得到一个 200Gbps 带宽的软件定义负载均衡集群，让我们正式开始。

网络是分层的

经典 TCP/IP 四层网络协议的首部

上面这张图引用自我的另一个系列文章：软件工程师需要了解的网络知识：从铜线到HTTP（三）—— TCP/IP¹。

如果你查看过网页的源代码，你就能知道网页背后是一段 HTML 代码，这段代码是被层层包裹之后，再在网络中传输的，就像上图中一样。以太网之所以拥有如此之强的扩展性和兼容能力，就是因为它的“分层特性”：每一层都有专门的硬件设备来对网络进行扩展，最终组成了这个容纳全球数十亿台网络设备的“互联网”。最近，这些传统硬件设备的工作越来越多地被软件所定义，即软件定义网络(SDN)。

应用数据是什么

应用数据就是网页背后的 HTTP 协议所包含的全部数据。

我们使用 Charles 反向代理软件可以轻易地得到 HTTP 协议的细节。下面我们展示一个普通的 GET 例子。使用浏览器访问 http://httpbin.org （自己尝试的时候不要选择 HTTPS 网站）：

请求内容

GET / HTTP/1.1Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9Accept-Encoding: gzip, deflateAccept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6Cache-Control: max-age=0Connection: keep-aliveHost: httpbin.orgUpgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36 Edg/108.0.1462.54

数据解释：

第一行有三个元素：HTTP 方法、uri、HTTP 版本
之后的每一行均以冒号:作为间隔符，左边是 key，右边是 value
HTTP 协议中，换行采用的不是 Linux 系统的 \n，而是跟 Windows 一样的 \r\n

响应内容

HTTP/1.1 200 OKDate: Wed, 04 Jan 2023 12:07:36 GMTContent-Type: text/html; charset=utf-8Content-Length: 9593Connection: keep-aliveServer: gunicorn/19.9.0Access-Control-Allow-Origin: *Access-Control-Allow-Credentials: true        httpbin.org                        ... ... 此处省略一万个字

响应数据的基本规则和请求一样，第一行的三个元素分别是协议版本、状态码、状态码的简短解释。唯一的不同是，返回值里面还有 HTTP body。

HTTP header 和 HTTP body

两个换行即 \r\n\r\n 之前的内容为 HTTP header
两个换行之后的内容为 HTTP body
HTTP body 就是你在浏览器“查看源代码”所看到的内容

HTTP 下面是 TCP 层

TCP 首部图示

TCP 首部重要数据描述

TCP 首部中最重要的数据是源端口和目的端口
他们各由 16 位二进制数组成，2^16 = 65536，所以网络端口的范围是 0-65535
我们可以注意到，目的端口号这个重要数据是放在 TCP 首部的，和更下层的 IP 首部、以太网帧首部毫无关系

TCP 下面是 IP 层

全球所有公网 IPv4 组成了一个大型网络，这个 IP 网络其实就是互联网的本体。（IPv6 比较复杂，本文在此不做详细讨论，以下示例均基于 IPv4）

在 IP 层中，每台设备都有一个 ip 地址，形如123.123.123.123：

IPv4 地址范围为 0.0.0.0 - 255.255.255.255
255 为 2 的 8 次方减一，也就是说用八位二进制可以表示 0-255
四个八位即为 32 位，4 个字节

IP 首部有哪些信息

从上图可以看出，ip 首部有 20 字节的固定长度是用来存储这个 IP 数据包的基本信息的：

源地址 32 位（4 个字节）：123.123.123.123
目的地址 32 位（4 个字节）：110.242.68.3
协议 8 位（1 个字节）：内部数据包使用的协议，即 TCP、UDP 或 ICMP（就是 ping 命令使用的协议）
首部检验和 16 位（2 个字节）：此 IP 首部的数据校验和，用于验证 IP 首部的数据完整性

ip 首部最重要的数据是`源 ip 地址`和`目的 ip 地址`

IP 层下面是 MAC 层(物理层)

物理层中的二进制数据以上图中的格式进行组织，其基本单元被称为“MAC 帧”。

每一台网络设备的 MAC 帧的长度不一定一致，默认为 1500，即 IP 层的数据会按照这个长度进行分包。在局域网速度跑不到协商速率，需要做性能优化时（例如 iSCSI 网络磁盘），可以使用“巨型帧”技术，将这个数字增加到一万，可以提升网络传输性能。不过，根据我的实际优化经验，绝大多数场景下，巨型帧对网络性能的提升小于 5%，属于一种聊胜于无的优化手段。

目的地址和源地址均为 MAC 地址，形式如 AA:BB:CC:DD:EE:FF，共有六段，每一段是一个两位的 16 进制数，两位 16 进制数换算成二进制就是 8 位，所以 MAC 地址的长度为 8*6 = 48 位。

类型字段采用 16 位二进制表示更上一层（ip 层）的网络层数据包的类型：IPv4、IPv6、ARP、iSCSI、RoCE 等等。

MAC 层就是交换机工作的地方，我们下篇文章会讲。

Nginx 的性能极限

在真实世界中，QPS 一般比保持 TCP 连接的客户端的数量要少，在此我们假设为四分之一，即：有 20 万个客户端设备在这段时间内访问我们的系统，每个客户端设备平均每 4 秒发送一个 HTTPS 请求。

单台 Nginx 反向代理的性能极限

由于 Nginx 不仅需要建立 TCP 连接，还需要将 TCP 连接中发送过来的数据包和某个进程/线程进行匹配，还需要对 HTTP 协议的信息进行解析、识别、转换、添加，所以它也有 QPS 上限：

在 2015 年主流的服务器 CPU 上，Nginx 官方在进行了极限优化的情况下进行了反向代理性能测试，在“建立 TCP 连接-发送 HTTPS 请求-断开 TCP 连接”的极限拉扯下，最高性能为 6W QPS（SSL TPS RSA 2048bit）²。

假设我们使用最新的服务器硬件，当虚拟机 CPU 达到 32 vCore 的时候，未经优化的单机 Nginx 性能就已经达到极限，能承受大约 1 万 HTTPS QPS，对应的连接用户就是 4 万，这个数字其实已经很夸张了。

TCP 负载均衡器为何能抗住五万 QPS

我们假设单台 Kong 应用网关的极限为 1 万 QPS，于是我们就需要五台 Kong，那这五台 Kong 前面的 TCP 负载均衡为何能够抗住呢？因为 TCP 负载均衡器要干的事情比 Kong 少非常多：它只需要在 IP 层做少量的工作即可。

使用负载均衡器拆分 TCP 单点

TCP 协议是一种“可靠地传输信息”的方法，它不仅有三次握手四次挥手等复杂的控制流程，还会对每一个报文段进行排序、确认、重发等操作来保证最终数据的完整和正确，所以，TCP 本身就是一种需要很多资源处理的单点，接下来我们开始拆这个单点。

TCP 负载均衡器的工作过程

我们假设客户端 ip 为 123.123.123.123，负载均衡器的 ip 为 110.242.68.3（公网）和 10.0.0.100（私网），五台 Kong 服务器的 ip 为 10.0.0.1 ~ 10.0.0.5，架构图如下：

负载均衡器的工作过程如下：

1. 接收数据（左侧）

负载均衡器接收客户端数据包（报文）的过程如下：

负载均衡器收到了一个 ip 报文：源地址 123.123.123.123，目的地址 110.242.68.3
ip 报文内包裹着一个 TCP 报文，详情如下：源端口 52387，目的端口 443
注意，负载均衡器只是接收了一个 IP 报文，并没有和客户端进行三次握手，并没有和客户端建立“TCP 连接”

2. 发送数据给上游服务器（右侧）

在接收到客户端的 IP 报文以后，负载均衡器会找一台上游服务器，准备把数据发送过去：

内部 TCP 报文首部：源端口 45234，目的端口 443
TCP 报文外面包裹的 IP 首部：源地址 10.0.0.100，目的地址 10.0.0.1
负载均衡器将包裹着 TCP 数据包的 IP 报文发送了出去

3. 建立两个报文的映射关系并进行数据转发

负载均衡器会在内存里创建两个五元组：

左侧五元组

左侧源地址 123.123.123.123
左侧目的地址 110.242.68.3
左侧源端口 52387
左侧目的地址 443
协议 TCP

右侧五元组

右侧源地址 10.0.0.100
右侧目的地址 10.0.0.1
右侧源端口 45234
右侧目的地址 443
协议 TCP

然后，负载均衡器会关联这两个五元组：对两侧发来的数据包（报文）进行拆包和修改（两个地址+两个端口），并从另一侧发送出去。

这是什么？这就是你家的路由器（网关）呀

看过我《软件工程师需要了解的网络知识》系列文章的同学应该能一眼看出，这就是网关的工作模式，你家几百块的路由器主要干的就是这个工作。

为什么性能开销比 Kong 低

我们可以看出，负载均衡器/网关只需要做两件事：

建立两个五元组并关联
修改数据包的地址和端口，再将数据包发送出去

这个操作在网络领域内被称作 NAT（网络地址转换）。

由于这个工作非常简单，其中大部分的工作都可以用专用硬件来解决：例如开发专门的五元组存储和关联芯片，开发专门的 NPU（网络数据包处理器）来进行快速数据修改。所以，家用路由器可以做到在 300 块终端售价的情况下实现超过 1Gbit/S 的 NAT 性能。

Kong 网关需要建立“TCP 连接”

Kong 网关需要真的和客户端“建立 TCP 连接”：

三次握手建立连接
对数据包进行排序、校验，收到心跳包需要回复
需要将这个 TCP 连接和一个进程/线程进行绑定：
1. 在收到数据以后，找出这个进程/线程，把数据发送给它
2. 等进程/线程回复以后，再找到该进程/线程对应的那个 TCP 连接，把数据发送出去

四层负载均衡（L4）和七层负载均衡（L7）

在卖负载均衡的商业公司那里，应用网关也叫七层负载均衡，因为它工作在 OSI 七层网络模型的第七层，而我们讨论的工作在 IP 层的负载均衡叫四层负载均衡，工作在 OSI 七层网络模型的第四层。再看到 L4 L7 这两个词，你们就能一眼看穿它了，其实一点都不神秘。

还记得我们的目标吗？一百万 QPS

我们通过使用一个负载均衡器，可以完美抗下五万 QPS 的负载：一个 TCP 负载均衡器，下挂五个安装了 Kong 应用网关的虚拟机，再下挂 N 台虚拟机，无论是 PHP 语言还是 golang，都可以实现五万 QPS 的设计目标。

接下来

下一篇文章，我们将着手突破普通 Linux 系统网络性能的上限：使用软件定义网络（SDN）替代百万人民币的负载均衡硬件，并最终搭建出一个能够支撑 200 Gbps 带宽的负载均衡集群。

参考资料

软件工程师需要了解的网络知识：从铜线到HTTP（三）—— TCP/IP https://lvwenhan.com/tech-epic/487.html
6W QPS（SSL TPS RSA 2048bit） https://www.nginx.com/resources/datasheets/nginx-plus-sizing-guide/

相关日志：

高并发的哲学原理（四）-- 隐藏在语言背后的魔鬼：运行架构为何会成为性能瓶颈

JohnLui — Thu, 29 Dec 2022 07:40:28 +0000

《高并发的哲学原理 Philosophical Principles of High Concurrency》开源图书已经发布，简称 PPHC。地址：https://github.com/johnlui/PPHC

编程语言的性能差异是程序员社区经久不衰的话题，但当你对各种技术的了解越深入，就越能感受到各种语言的本质区别：不同语言的设计方向不同，就像时间换空间、空间换时间，他们只是选择了一种优势找信息之神换成了另一种优势罢了。

没有任何编程语言是单纯的“语法集合”，每一种语言都是它背后“运行架构”的体现，语言之间的差异本质上就运行架构设计方向的差异。

web 系统规模发展史

web 1.0 时代，各种静态、动态、解释型、编译型、虚拟机型语言百花齐放，因为当时系统规模和系统用户都比较少，而资源则大多以静态 HTML 页面的形式显示，技术上大家都熟悉哪个用哪个，这些后端技术也大多能满足需求。

web 2.0 时代，真正的高并发系统出现了，一分钟内需要写入数据的用户数超过了百万，这个时代，最终锤炼出了 Java 和 PHP 两种技术：PHP 擅长简单 CURD，而 Java 擅长事务处理（例如电商下单）。这个时代发展到顶峰，就是手机 APP 和大前端的时代：界面由前端完全掌控，后端团队提供稳定高性能的 API 即可。

在 web 生态发展的过程中，也催生出了如 Python、Ruby、Scala、Node.js 这样的后端技术之花，但他们在冲向顶峰后也迅速落幕，现在连 PHP 也在逐步退场，只有 Java 由于拥有完善的微服务基础设施，暂时看起来还安全。

web 2.0 后期，乔布斯将人类拉入了移动互联网时代。今天的互联网巨头们，同时在线用户量动辄上亿，对系统性能的需求发生了爆炸性的增长，也催生出了 PHP 的接班人：go 语言。十多年前我第一次写 go 的时候就认识到，它就是 C with net，自带网络库的万能底层语言，可以让普通开发者轻松写出超高性能的应用。

语言特性如何决定性能

PHP 语言是一种单线程全阻塞语言：在每个 HTTP/FastCGI 请求中，PHP 解释器会启动一个进程/线程来运行一段 PHP 代码，在运行的时候，无论是读写磁盘（磁盘 IO）还是读写数据库（网络 IO），PHP 线程都会停下来等待：此时并不消耗 CPU 资源，但是 TCP 和线程资源都还在持续等待，如果这个请求不结束，那该线程将会一直保持运行，持续消耗着 TCP 和内存资源。

由于语言本身的运行架构一致，所以 php-fpm 和 Apache 执行 PHP 的性能是一致的。在 2 vCore 4G 内存的情况下，PHP 200QPS 的性能极限是无法通过把 Apache 换成 php-fpm 来解决的。

那么阻塞式运行架构的性能瓶颈应该怎么突破呢？轮到 Node.js 登场了。

Node.js 的非阻塞 IO

在阻塞式语言中，所有的 IO 操作都是需要停下来等待的，例如磁盘 IO，数据库网络 IO 等，而真正用于计算的 CPU 资源反而大多数时候在浪费：绝大多数 API 不需要多少复杂的数据转换，更多的时间花在了和各种数据库的通信上。而世界上绝大多数语言都是阻塞式运行的，因为这样做虽然性能不高，但却最符合人类大脑的习惯，编码也更加容易。在当时，高性能大多是用多核+多进程/线程来实现的。

Ryan Dahl 敏锐地发现了 IO 浪费时间这个问题，并且挑选了一个为浏览器创造的单线程语言 JavaScript 来实现他的抱负：将所有 IO 操作全部异步化，并利用 js 的单线程排队特性，创造了一种高性能且稳定的后端技术：Node.js。

不过，计算机的世界没有银弹，Node.js 虽然性能强，但是代码编写起来更加困难，需要多付出一些异步编程的思考时间，debug 也更加地困难。

Node.js 是一种非常神奇的单线程异步非阻塞架构，以 Google v8 引擎作为 JavaScript 解释器，利用事件驱动技术，大幅提升了单机能够处理的 QPS 极限，而它“只是完整利用了单核 CPU”而已。

此外，Node.js 还具备一个 Nginx 的优势：可以单机处理海量用户的 TCP 连接。

你看，背后的哲学原理都连上了吧。

Node.js 可以完整利用单核 CPU 了，那现在的服务器 CPU 已经做到了单颗 96 核 192 线程，该如何利用这么多的 CPU 核心呢？该 golang 登场了。

go 语言的协程

为了更好地“直接利用全部 CPU”，Java 诞生了线程池技术，至今还在发光发热；而 golang 选择釜底抽薪：在语言层面打造一个完善的“超并发”工具：goroutine（协程）。

我之所以将 goroutine 称为“超并发”工具，是因为它是语言提供的一个线程池+协程的综合解决方案，并使用 channel 管道思想来传递数据，为使用者提供了一个无需手动管理的高性能并发控制 runtime，可以保证完全榨干每一个 CPU 时间片。

golang 的协程本质上来讲就是 在一个线程内不断地 goto，就像 DPDK 完全在用户态运行由于避免了上下文切换而大幅提升了网络性能一样，golang 在线程内主动 goto 也可以轻松将 CPU 利用率顶到 100%，实现硬件资源利用的最大化。

当然，不断地 goto只是一种形象的类比方法，实际上 golang 的协程技术经历了好几次迭代，具体实现大家可以看灯塔 draveness 的书：《Go 语言设计与实现》¹。

实际上“吃完多核服务器上的每一个 CPU 核心”也是各种新形态 MySQL 兼容数据库的主要价值，这个我们在倒数第二篇文章讨论数据库架构时会进行详细分析。

goroutine 的弱点

就像性能优化的核心是空间换时间、时间换空间一样，goroutine 也不是银弹，也是牺牲了一些东西的。根据我的实践，这个东西就是“极其昂贵的内存同步开销”，而且 goroutine 引发的这个问题比 Java 的线程池内存同步问题严重的多。

一旦你想在单个 golang 进程内部的海量协程之间做“数据同步”，那你面临的就不只是 CPU 资源浪费那么简单了，你会发现，CPU 依然吃完了，但是并发量还是好低：多线程的内存同步开销已经摧毁了无数根 Java 程序员的头发，goroutine 线程 * 协程 的内存同步性能堪称灾难:

sync.Map受害者请高举你们的双手！

那如果我们需要在海量协程之间做实时数据同步该怎么办呢？这个时候，高并发哲学思维又要出动了：找出单点，进行拆分！

等等，好像除了唯一的这个 golang 进程找不出单点啊？

没错，这个唯一进程申请的这段内存就是单点，想解决这个问题需要出大招：找外援。

Redis 是 golang 协程最亲密的伙伴，就像 MySQL 之于 PHP

网络栈是一种贯彻了 linux 一切皆文件思维的优秀工具，此时可以帮上大忙：找另一个单线程性能之王 Redis 打辅助，即可帮助海量协程排队：此时一旦某个协程进入网络 IO 状态，则会立即让出 CPU 时间片：goto 到下一个协程，不浪费 CPU 资源。

当然，你也可以选择自己用 golang 写一个类似 Redis 的单线程内存数据库，和你的业务进程进行网络通信，也可以解决这个问题。

一旦解决了协程之间内存同步的问题，golang 就开始胡吃海塞，大杀四方，榨干 CPU 的全部性能潜力。

Java 技术的优势

Java 是一整套基于运行时虚拟机技术的解决方案。总体来看，它选择了“空间换时间”：Java 应用对内存的需求量显著超过其它技术，而经过了这么多年的优化，Java 的“时间性能”在绝大多数场景下都已经做到了无限接近 C++ 的水平。

Java 虽然是虚拟机技术，但它是常驻内存的，并且这个技术非常的灵活。对，你没有看错，Java 技术确实非常灵活。spring 框架对写代码程序员的约束确实很强，但这是对使用者的繁琐，Java 本身是非常灵活的。

经过了这么多年的发展，Java 其实一直都能跟上时代：JDBC、RMI、反射、JIT、数字签名、JWS、断言、链式异常、泛型、注解、lambda、类型推断等等等等。我们知道，传统的 Java 大多采用线程做并行，但是在今年（2022）它甚至发展出了协程 Fiber！

21 世纪头十年，JVM 在很多公司内都变成了代替虚拟机技术的存在，成为了事实上的“标准服务端运行环境”，以至于诞生了 JPython、JRuby、JPHP 等颇具邪典气质的技术：把动态语言的解释器内置到 JVM 内，再把代码和解释器打包成一个 jar/war，让 JVM 可以直接运行 Python、Ruby、PHP 项目。

这是什么，这就是容器技术啊！

总结一下

PHP 的模型最原始，鲁棒性最强，对垃圾代码的兼容性更强，甚至可以看做一种“半微服务”技术（因为多文件），但是性能也最差。

Node.js 实现了非阻塞 IO，但是只能利用一个 CPU 核心，这导致它的高性能还需要依赖基础架构（进程管理器/虚拟机/k8s）才能够发挥出来。

而 golang 自带“线程+协程”的超并发解决方案，让只拥有一台笔记本的大学生也能随时对一个网站发起 5000QPS 的 DOS 攻击。让一个没有完善运维团队的小公司程序员，在不依赖并行基础架构的情况下，能够在裸金属服务器上用一个进程直接吃完全部的 CPU 资源，支撑起可观的用户量。

还记得我们的目标吗？一百万 QPS

通过使用 golang，我们依然使用前面那台双路 E5-2682 V4 64 vCore，在数据库性能足够的情况下，我们可以把单个系统的 QPS 从 5000 提升到 50000，并且可以在裸金属服务器上直接部署，不需要虚拟机/k8s 并发基础设施，甚至都不需要前置一个负载均衡器。

当然，现实中 50000 QPS 的系统几乎必然拥有负载均衡器，即便每个接口只返回 20KB，那网络带宽也已经达到了 976MB/S，即 7.8Gbit，单机带宽都快干到 10G 了，肯定是不会只用单台服务器硬抗的，即使单机性能能达到，那单机也无法保证这么大规模系统的稳定性。这个时候我们就需要负载均衡器的介入，接下来两篇文章我们会详细讨论。

接下来

下一篇文章，我们将着手拆分“监听 HTTPS 443 端口的进程”这个单点，探寻负载均衡技术的发展历程，普及应用网关、负载均衡、LVS、网关和交换机的性能特点，并在再后面一篇文章讨论 200 Gbps 带宽的负载均衡集群该怎么搭建。

参考资料

《Go 语言设计与实现》 https://draveness.me/golang/docs/part3-runtime/ch06-concurrency/golang-goroutine/#651-%e8%ae%be%e8%ae%a1%e5%8e%9f%e7%90%86

相关日志：

高并发的哲学原理（三）-- 基础设施并发：虚拟机与 Kubernetes（k8s）

JohnLui — Thu, 29 Dec 2022 04:16:53 +0000

《高并发的哲学原理 Philosophical Principles of High Concurrency》开源图书已经发布，简称 PPHC。地址：https://github.com/johnlui/PPHC

上篇文章说到，Apache 无法处理海量用户的 TCP 连接，那要是由于宇宙时空所限，你的系统就是无法离开 Apache，该怎么承接高并发呢？有办法：既然单机不行，那就把单机虚拟化成多个 linux 机器，就能顶得住高并发了。

Apache 成为了单点，那就把它拆了

基于虚拟化做多节点集群，可以相对线性地提升系统性能，你只要在前面搭建一个负载均衡即可。

一个负载均衡服务器 + 多个上游服务器的技术架构正是“找出单点，进行拆分”思想的具体体现。如果 Apache 顶不住，那我们就仔细思考一下，Apache 架构中，到底那个单点是不好拆的，哪些部分是可以并行的？

监听 443 端口的进程（root 用户）是单点

显然，监听 HTTPS 443 端口的进程就是肉眼可见的单点，而执行 PHP 的进程在一台服务器上本身就是并行的。

（其实监听单点也能拆，只是我们在这一步还不需要拆，后面会拆。）

跑 PHP 的进程（apache 用户）可以并行

在单机上，PHP 解释器进程本身就是并行的，那我们把它拆到多台机器上，就是顺理成章的事情。

百亿架构

下面是我为自研电商设计的可伸缩技术架构：

经过一年多的运行，我发现它撑到年 GMV 100 亿问题不大，以今年十多亿的 GMV 为例，目前 2 核 4G kong 网关虚拟机的 CPU 占用最大只到了 20%，那 8 核 kong 网关应该就能顶住 100 亿的冲击了。

这套架构的核心是两个东西：kong 网关和服务发现。

kong 网关

虚拟机技术无法单独提升系统容量，因为必须有东西来承接“监听 443 端口”这个单点，在这里我选择了 kong 网关作为 HTTP 反向代理服务器，将用户的海量 HTTPS 请求 handle 住，再以 http 协议发送到后端的多台 2 核 4G 虚拟机上。

Kong 是基于国产 OpenResty 技术的开源网关，OpenResty 将非常轻量的 lua 语言嵌入了 Nginx 生命周期，大幅扩展了 Nginx 的功能。Kong 除了拥有 HTTP 网关的一整套功能外，还有插件系统和基于数据库的水平扩展能力，理论上可以支撑超高并发的系统。这部分具体的内容我们会在后面《百万人民币的负载均衡硬件以及它的软件替代方案》里面做详细的讨论。

服务发现

在流量低谷期我们使用一台虚拟机跑 Apache 作为上游服务器，在开团前需要再开出来一台上游服务器的话，Kong 该怎么知道这台服务器开出来了，并且获取到他们的 ip 呢？使用服务发现技术。

像 Kong 一样，HashiCorp 开源的 consul 也可以独立于 k8s 环境运行，于是我选择了它来做服务发现。服务发现的原理说起来其实非常简单：构造一个共识集群，各个节点之间会使用固定的端口相互通信，当新的上游服务器开机后，它上面的 consul 服务会开机启动，之后就会和配置好的一个 master 的 ip 进行通信，加入这个集群，并广播本机可以提供的服务名称，假设名叫up。这时，同样在集群内的 Kong 网关服务器就可以通过它本机上安装的 consul 提供的 DNS 服务拿到新加入集群的这台机器的 ip 了。

Kong 向 consul DNS 发送一个查询：查找up.service.consul这个域名对应的 ip，之前，这个域名只会返回一个 ip，在新机器开机并成功加入集群后，这个域名对应的就是两个 ip 了，Kong 就可以把 HTTP 请求均匀地发送给新旧两台上游服务器了。

好了，基础架构准备就绪，下面我们深入一下本文的主题：基础设施并发。

何为基础设施并发

虚拟机是第一代基础设施并发技术：既然由于软件架构的限制导致单机性能有上限，那我就把多核服务器拆成多机。因为现在服务器核心数越做越多，除了 web 服务，周边的 MySQL、Redis、ElasticSearch 等也需要计算资源，将多核服务器虚拟化，除了可以提升系统性能，还能减少资源浪费，换个词就是：省钱。在今天整个行业都在降本增效的大背景下，省钱无疑是技术潮头。

而 k8s 容器编排技术是最新一代基础设施并发技术：可以把它看成一种更优秀且更容易进行自动化管理的虚拟机技术。

虚拟化技术的价值

不知道屏幕前的读者有没有想过，在一台裸金属服务器的操作系统内直接运行 Apache、MySQL、Redis、ElasticSearch，和开四台虚拟机分别运行他们，到底有什么区别。系统设计哲学不是“如无必要勿增实体”吗？虚拟机技术到底有什么价值来让我们新增四个实体呢？

1. 资源隔离

后端技术拥有很多成熟的开源软件，每个软件都拥有独特的发展路径，百花齐放，群魔乱舞。如果把所有服务都装在裸金属服务器上，理论上讲使用内存管道通信的效率比虚拟机之间通过虚拟以太网通信还要更高，但是资源隔离就难做了。

拥有自我资源限制能力的软件不多，大部分软件都是“有多大屁股穿多大裤衩”：根据请求压力任意获取计算资源，这就让计算资源的分配容易出现问题，导致木桶效应，最终导致系统整体性能反而更低。

虚拟化技术通过将虚拟机和物理核心进行强绑定，可以无限接近“将一台 64 核服务器拆成 32 台 2 核服务器”的目标，内存也可以进行完全预分配，虚拟机之间的相互干扰可以做到最低。

2. 降低运维复杂度

市面上成熟的监控软件都是基于操作系统的，进程也能监控，但是比较困难。控制虚拟机也比控制进程要更加容易。当然，控制 k8s 容器平台更加灵活高效，我们下面会讲到。

虚拟机显著降低了对每个重要服务进行资源监测的复杂度，大幅提升了运维效率，甚至实现了第一代的“自动运维”，时至今日，VMWare 在超融合领域也拥有统治地位：基于三台服务器的小集群，就可以提供高可用架构的全套基础设置：统一应用网关、共享存储、虚拟机热漂移、自动故障转移等。如果只用一台物理服务器直接安装 Linux，很显然这些高可用特性都做不到，一旦这台物理机的某个部件发生了故障导致宕机的话，全部服务都会挂掉。

3. 隐藏价值：性能氮泵

由于很多软件都拥有 Apache 一样的“单机性能极限”，所以虚拟化技术将单机拆成多机，就可以直接实现性能增益。如果你把 Apache、Redis、MySQL、ElasticSearch 都装在裸金属操作系统上的话，他们就会异口同声说：给我那么多核心有什么用，我真的用不上啊。

Apache 我们前文已经讲过，下面我们讨论一下其他几种技术的“单机性能极限”。

Redis 的单机性能极限

Redis 作为单线程内存数据库，两核就能做到十万 QPS，你给他 32 核，还是十万 QPS，对资源是一种浪费。

在前几天 Redis 回应新兴内存数据库 Dragonfly 挑战的文章中，Redis 维护团队建议大家搭建“单机集群”¹ 来实现对机器上所有 CPU 的完全利用，Redis 团队的内心 OS 一定是：宝宝心里苦但宝宝不说。

而且，基于虚拟化技术搭建多虚拟机上的 Redis 集群，是一种比单机集群更加稳妥的高性能 Redis 解决方案。

MySQL 的单机性能极限

在今天这个 NVME PCI-E 4.0 时代，单个闪存磁盘的读写速度已经站上了 7GB/S，MySQL 的单机 CPU 使用强度已经大大提高，但是，如果我拿最新的双路 AMD EPYC 9654 96 核服务器来跑单机 MySQL 呢？显然单节点 MySQL 无论如何是无法吃完 192 个物理核心，384 个线程的，而它的性能极限也会停在几万 QPS。

实际上，标准 MySQL 的性能瓶颈在内存容量和磁盘速度，对 CPU 资源的需求并不是很高，在两台虚拟机拥有独立固态硬盘的情况下，把 16 核虚拟机拆成两台 8 核虚拟机并打造成一个半同步一主一从的 MySQL 集群，便可以轻松将数据库的读性能提升一倍，只需要稍微牺牲一丢丢写性能。

web 系统的瓶颈在数据库，数据库的瓶颈在存储，这个话题很大，我们后面有三篇文章专门讨论数据库和存储。

ElasticSearch 的单机性能极限

ES 作为一个 Java 应用，显然拥有着明确的单机性能极限：线程切换需要读写内存，性能上限就在那里。ES 自己就采用了自选举集群架构来实现水平扩展：官方建议单节点不要超过 32GB 内存。

如果你的母鸡 CPU 和内存很多，就可以基于虚拟机技术做多节点 ES 集群，ES 集群的扩展能力是非常不错的：作为一个搜索引擎，大家竟然都拿他当数据库用，从这里就足以看出它优秀的水平扩展能力。

k8s 技术的本质

容器技术是谷歌给人类社会的又一个重大贡献，不仅开发了 Cgroups 并将其合并进了 linux kernel（2008 年），还开源了自己的容器编排工具 Kubernetes（简称 k8s，2014 年开源），而在这两件事之间，2013 年 Docker 为容器世界贡献了一个决定性的新思想：镜像技术。

镜像技术开天辟地

Docker 发明了镜像，并提出了 build、ship、run 的概念，通过将整个操作系统的文件系统打包进容器镜像，真正实现了一次构建、处处运行。而在这之前，只有拥有完整操作系统的虚拟机才能做到这一点，而 Java 则号称自己能做到。

git 一样的镜像

比容器思想更为重要的是，Docker 项目还在容器镜像的制作上引入了“层”的概念，这种基于“层”（也就是“commit” ) 进行 build，push，update 的思路，显然是借鉴了 Git 的思想。所以这个做法的好处也跟 Github 如出一辙：制作 Docker 镜像不再是一个枯燥而乏味的事情，因为通过 DockerHub 这样的镜像托管仓库，你和你的软件立刻就可以参与到全世界软件分发的流程当中了²。

Docker 的成功主要就是靠的 DockerHub，它将开源软件推进了一大步：开源软件可以直接分发“下载即可用”的标准化软件镜像，大家可以像在开源社区协作一样，在镜像社区协作，一层一层地搭建出适合自己的镜像，人类作为群居动物的本能嘎的一下就觉醒了。

软件架构本质上是软件维护团队的组织架构

稍微扯远一点，说说软件架构和运维架构。我认为，容器、镜像、容器编排的兴起，与其说是一种技术创新，不如说是一种生产关系的创新：在越来越大的服务器数量面前，以前那套基于虚拟机的管理技术不再适用了，Google 需要一种少数人管理数十万台服务器的新技术，于是 k8s 诞生了。

正如软件架构本质上是软件维护团队的组织架构，运维架构本质上也是运维团队的组织架构：规模大到必须自动化，于是容器编排便自然而然地出现了（唯物史观有木有）。

重要的不是电影拍摄(讲述)的年代，而是拍摄电影的年代。 —— 戴锦华（北京大学教授，电影评论家）

k8s 是一种更加优秀的基础设施并发技术

k8s 是人类面对暴增的物理服务器和上面数不清的虚拟机的管理难题时想出的一种解决方案，正如设计模式是面向对象编程思想对现实问题的一种妥协。

以 k8s 为代表的容器编排技术，就是一种更容易被软件自动化管理的“虚拟机”，它可以实现虚拟机一样的功能——资源隔离、降低运维复杂度和性能氮泵，而且，它还可以在裸金属环境下快速部署出一个数千台服务器的集群。虽然虚拟化技术研发出了很多像 SR-IOV 一样的硬件直通技术，但无论是物理网卡性能还是虚拟网卡性能，都不如容器技术：五年前我在一台非常老的服务器上做过超过一天的压测，docker 的内存网关又快又稳，可以实现超过万兆的带宽，并持续 24 小时一个包都不丢。

传统虚拟机镜像巨大、启动缓慢、多个操作系统同时运行带来了资源浪费、迁移缓慢、管理困难，而 k8s 镜像很小，启动迅速，资源损耗低，管理 API 丰富，更是可以轻易实现“单机多实例部署”和“目录共享”，是海量服务器新时代的优秀基础架构。

k8s 就是云时代的虚拟机 + 操作系统。

还记得我们的目标吗？一百万 QPS

通过使用负载均衡 + 虚拟机，或者负载均衡 + k8s，在依然使用前面那台双路 E5-2682 V4 64 vCore 的情况下，我们可以把单个系统的 QPS 从上篇文章的 1000 提升到 5000。

（实际上在这个 QPS 下，数据库早就成为瓶颈了，这个问题我们留到后面几篇文章再详细讨论。）

接下来

下一篇文章，我们将讨论隐藏在语言背后的魔鬼：运行架构为何会成为性能瓶颈。编程语言的性能差异是程序员社区经久不衰的话题，但当你对各种技术的了解越深入，就越能感受到各种语言的本质区别：不同语言的设计方向不同，就像时间换空间、空间换时间，他们只是选择了一种优势找信息之神换成了另一种优势罢了。

参考资料

Redis 维护团队建议大家搭建“单机集群” https://redis.com/blog/redis-architecture-13-years-later/
你和你的软件立刻就可以参与到全世界软件分发的流程当中了 http://liupzmin.com/2019/11/06/docker/container-chat/

相关日志：

高并发的哲学原理（二）-- Apache 的性能瓶颈与 Nginx 的性能优势

JohnLui — Wed, 28 Dec 2022 13:57:49 +0000

《高并发的哲学原理 Philosophical Principles of High Concurrency》开源图书已经发布，简称 PPHC。地址：https://github.com/johnlui/PPHC

每一名后端开发可能都知道 Nginx 比 Apache 性能强，但是为什么强，强在哪里，接下来我们动手实验解答这个问题。

Nginx 利用了新的 Linux kernel API

Nginx 利用了 Linux 内核引入的 epoll 事件驱动 API，大幅降低了海量 TCP 连接下的 CPU 负载，提升了单个系统的 TCP 响应容量，这是 Nginx 性能更好的本质原因：时代在进步。

每一篇技术文章都会说，Nginx 的 epoll 比 Apache 的 select 性能高，但为什么，却几乎没人解释。下面我来尝试解释。

epoll 简单解释

众所周知，epoll 是一种高性能事件驱动 IO 多路复用机制，那他和 select 这种原始 IO 多路复用机制比有什么优势呢？简单来说，就是：转守为攻。

epoll 化被动为主动，以前需要两次遍历才能实现的网络数据包和线程的匹配，现在通过事件驱动的方式主动献上指针，性能暴增。这就像云原生时代的 Prometheus 监控：化主动上传为被动查询，大幅提升单个采集节点的性能上限，成功解决了监控领域的高并发性能问题。

在 5K 个 TCP 连接的情况下，每收到一个数据包，Nginx 找到对应线程的速度比 Apache 高了两个数量级，即便是 event 模式下的 Apache，性能依然远低于 Nginx，因为 Nginx 就是专门为“反向代理”设计的，而 Apache 本质是个 web 应用容器，无法做到纯粹的事件驱动，性能自然无法和 Nginx 相比。

Apache 的原始并发模型

Apache 支持三种进程模型：prefork、worker 和 event，在此我们简单讨论一下这三种模式的优缺点。

prefork 是进程模式，需要消耗更多的内存，每次接到一段新的数据，需要使用 select 模型，遍历 TCP连接数 x 进程数 这么多次才能找到匹配的进程，在数千个 TCP 连接下，光是寻找线程就需要消耗掉一个 CPU 核心，单机性能达到极限，无法利用更多的 CPU 资源
worker 是线程模式，依旧使用 select 模型来遍历 TCP 请求和线程，性能上限和 prefork 一致，区别是内存消耗量有了一些降低，初始 TCP 承载能力稍好，请求数突然增加的场景下，开新线程的速度反而比 prefork 更慢，且基础延迟比 prefork 模式更高
event 模式采用和 Nginx 一致的 epoll 模型承载，理论上表现和 Nginx 一致，但由于 Apache 大概率和 mod_php（插件）模式的 PHP 一起部署，由于 PHP 阻塞运行的特性，性能和上面两兄弟并无明显区别。而且即便是 event 模式下的 Apache，性能依然远低于 Nginx。

接下来我们使用 jmeter 测试一下 prefork、worker、event 三种模式的性能。

压力测试

测试环境

客户端：
- i5-10400 6 核 12 线程
- 32GB 内存
- 千兆有线网络
- 软件环境
  - macOS
  - Java 19.0.1
服务端：
- 物理服务器 E5-2682V4 2.5GHz 16 核 32 线程 * 2 （阿里云 5 代 ECS 同款 CPU）256GB RAM
- 虚拟机 64 vCPU （赋予了虚拟机所有母鸡的 CPU 资源）
- 虚拟机内存 32GB
- 软件环境
  - CentOS Stream release 9
  - kernel 5.14.0-200.el9.x86_64
  - Apache/2.4.53
  - Nginx/1.20.1
  - PHP 8.0.26
- PHP 环境：
  - Laravel 9.19
  - 给默认路由增加 sleep 500ms 的代码，模拟数据库、Redis、RPC、cURL微服务等场景
  - 执行 php artisan optimize 后测试
测试代码
Route::get('/', function () { usleep(500000); return view('welcome'); });
Apache prefork 模式配置
StartServers 100 MinSpareServers 5 MaxSpareServers 100 MaxRequestWorkers 500 MaxRequestsPerChild 100000
php-fpm 配置
pm = static pm.max_children = 500

试验设计

我们将测试三种配置下的性能表现差异：

Apache 标准模式：prefork + mod_php 插件式运行 PHP
Nginx + php-fpm 专用解释器
Nginx 作为 HTTP 反向代理服务器后接 Apache（prefork 模式 + mod_php 插件式运行 PHP）

请求计划

客户端新线程开启后，每隔 5 秒发送一个请求
jmeter 用 50 秒开 5000 个线程，持续压测 100 秒，最大请求 QPS 为 1000

为什么这么设计？

单独对比 Nginx 和 Apache 性能的文章很多，数据结果也大同小异，无非是 Nginx 的 QPS 更高，但是为什么却没人回答，我本次的实验设计就是要回答这个问题。

Apache 标准模式：prefork + mod_php

nginx + php-fpm

nginx 反向代理 Apache 标准模式

结果分析

我们可以很明显地看出，Apache + prefork 的问题在于它对数千个 TCP 连接的处理能力不足。

Nginx + fpm 一共发出了 59146 个请求，成功了五万个
Nginx + Apache 一共发出了 56464 个请求，成功了五万两千个，比 fpm 还多一些
fpm 模式最大 QPS 为 800 但比较稳定，Nginx + Apache 最大 QPS 1000 但不够稳定
至于 Apache 标准模式，显然它的技术架构不足以处理 5000 个 TCP 连接下 1000 QPS 的状况，QPS 低且不稳定，错误率高达 43%

结论：

Nginx 处理海量用户的海量 TCP 连接的能力超群
提升 Apache 性能只需要在前面加一个 Nginx 作为 HTTP 反向代理即可，因为此时 Apache 只需要处理好和 Nginx 之间的少量 TCP 连接，性能损耗较小
php-fpm 和 mod_php 在执行 PHP 的时候没有任何性能差异

Nginx epoll 和 Apache prefork 模型相比，优势劣势如下：

优势

Nginx 每个 worker 进程可以 handle 上千个 TCP 连接，消耗很少的内存和 CPU 资源，可以让单台服务器承接比 Apache 多两个数量级的用户量，相比于 Apache 单机 5K 的 TCP 连接数上限（对应的是 2000 个在线用户），是一个巨大的进步
Nginx 对 TCP 的复用使它非常善于应对海量客户端的直接连接，根据我的实测，在 HTTP 高并发下 Nginx 的活跃 TCP 连接数可以做到 Apache 的五分之一，而且用户量越高，复用效果越好
在架构上，基于 FastCGI 网络协议进行架构扩展，也可以更轻易地利用多台物理服务器的并行计算能力，提升整个系统的性能上限

劣势

在低负载下，Nginx 事件驱动的特性使得每个请求的响应时长比 Apache prefork 模式略长一些（14ms vs 9ms）

我的真实经验

新冠时期的爱情机遇

疫情初期，我司的私域电商业务兴起于草莽之间，在 3 月中旬才上班的情况下，半个月的 GMV 超过了前面一年，4 月就完成了全年目标，电商系统性能压力陡增。

当时我们的电商系统是购买的一个 PHP 单体系统，天生不具有扩展性，外加业务模式是团购秒杀，可要了亲命了。客户端为微信小程序，服务端主要提供两种业务：开团瞬间的海量 HTTP API 请求，以及每一个页面都非常消耗资源的订单管理后台。

当时我面临的第一个问题是数据库顶不住，我找到请求数最高的接口：商品详情，为它增加了一层保持时长为一分钟的 Redis 缓存，开团瞬间数据库的压力降低了很多。

而且幸运的是当时阿里云刚刚将 PolarDB 商用几个月，我用它顶住了开团三分钟内涌入的大约 4000 名用户，但是当我把虚拟机升级到 16 核 32G 内存的时候出现了一个非常诡异的现象：

CPU 和内存占用率分别只有 8% 和 6%
但大量的新用户就是无法建立 TCP 连接，首次连接的客户端表现为长时间的等待
如果运气好在等待一段时间后成功进去了，那访问便会一直如丝般顺滑，每个接口的返回时间都非常短

这是为什么呢？这是因为新用户无法和服务器建立 TCP 连接！

默认情况下，CentOS 7.9 的最大文件打开数（ulimit）为 1024，一切皆文件，每个 TCP 连接也是一个文件，所以也被锁定在了 1024 个。一般大家都会把这个数字设置为 65535，但是我观察到，这台虚拟机此时的 TCP 连接数只能跑到 5-6K 之间，远远达不到用户的需求，无论是采用 prefork、worker 还是 event 都是这样。而原因就是我们上面实测过的：此时 Apache 花费了一颗核心的全部时间片来进行数据包和线程的匹配，已经忙不过来了。

后来，我在这台机器上安装了一个 Nginx，反向代理全部的用户请求再发送给 Apache：请求一下子舒畅了，而且 Nginx 使用的最大活跃 TCP 连接数量也只有 1K，就完全满足了三分钟 4000 用户的需求。

还记得我们的目标吗？一百万 QPS

在 2022 年的主流云服务器硬件上，经过 OPCache 性能优化的 PHP 应用，只需要 2 vCore 便可以达到 5K 的单机 Apache TCP 上限，此时 QPS 在 200 左右，单纯提升核心数量无法让这个数字大幅增加。而通过使用 Nginx，我们可以将单系统的 QPS 上限从 200 提升到 1000。

接下来

下一篇文章，我们将讨论基础设施层面的并发：虚拟机和 k8s 技术。同时我会继续现身说法，讲述我为自研团购秒杀系统设计的架构，我称它为百亿架构（年 GMV 百亿之前不用换架构）。

相关日志：

高并发的哲学原理（一）-- 找出单点，进行拆分

JohnLui — Wed, 28 Dec 2022 10:23:55 +0000

《高并发的哲学原理 Philosophical Principles of High Concurrency》完整版十三万多字的出版文稿已经写完，放到了独立网站上：https://pphc.lvwenhan.com

人列计算机

《三体》中，刘慈欣设计了一个用人进行二进制运算的计算机，使用了三千万名士兵(晶体管)：

计算机名：秦一号
CPU：秦始皇最精锐的五个军团
1. 挥舞旗帜进行二进制运算
2. 用三个士兵来组成与门、或门、与非门、或非门、异或门、同或门和三态门，又用两个士兵组成了非门
3. 将这些基本部件组合起来，构成了计算阵
内存：由文化程度较高的人组成，每个人挥舞多个颜色的旗帜，可以替代 20 个挥舞单色旗帜的人
硬盘：三百万文化程度较高的人（据说是上次坑儒留下来的）
显示阵列：至少配有红色和绿色像素单元（双色显示阵列）
维护部件：一组骑兵
1. 传输信号
2. 处理“故障”士兵
3. 由秦始皇最精锐的骑兵团构成
维护方式：更换出错部件

一提到高并发，很多人的第一反应都可以归纳为以下两种情况：

1. 进程间通信(IPC)、共享内存、管道、队列、事件：这是学院派

2. 内存缓存、消息队列、分库分表、NoSQL、ES 搜索：这是实战派

其实，高并发之路，无论是学院派还是实战派，甚至是刘慈欣设计的人列计算机，其背后的哲学原理都是一样的。如果你问人列计算机和高并发有什么关系？按照上面的设计，最多一万名士兵就够了，为什么需要三千万呢？还不是为了提高性能。

其实，高并发的哲学原理早就隐藏在了现代计算机的基础结构之中，感兴趣的欢迎去看我的《性能之殇（二）-- 分支预测、流水线与多核 CPU》¹。

本文目标

上面只是我的喃喃私语，下面我们进入正题。

本文的目标是在我有限的认知范围内，讨论一下高并发问题背后隐藏的一个哲学原理。我们将从动静分离讲起，一步步深入 Apache、Nginx、epoll、虚拟机、k8s、异步非阻塞、协程、应用网关、L4/L7 负载均衡器、路由器(网关)、交换机、LVS、软件定义网络(SDN)、Keepalived、DPDK、ECMP、全冗余架构、用户态网卡、集中式存储、分布式存储、PCI-E 5.0、全村的希望 CXL、InnoDB 三级索引、内存缓存、KV 数据库、列存储、内存数据库、Shared-Nothing、计算存储分离、Paxos、微服务架构、削峰、基于地理位置拆分、高可用等等等等。并最终基于地球和人类社会的基本属性，设计出可以服务地球全体人类的高并发架构。

先说结论，这个哲学原理就是：找出单点，进行拆分。

准备工作

性能问题要靠架构解决

在展开这个哲学原理前，我们需要先明确一下高并发问题的解决思路：性能问题要靠架构解决。

首先，在架构上动刀是最简单的，也是最容易获得收益的。其次，即便是真的去做单个资源的性能优化，例如 MySQL 单机性能优化(软件优化)、x86 CPU 多核性能提升(硬件优化)，拆到微观来看，也是在做架构优化：

没有银弹就是计算机世界的第一准则，你想获得收益，总得拿出一些东西，和信息之神交换。

我们讨论“哪个”高并发？

本文讨论的是“web 服务高并发”问题，典型场景为电商秒杀：同一个时刻，数万人抢同一个低价商品，会给系统的每一个层面都造成显著的性能瓶颈，这种场景的集大成者，就是每年的双 11。

一个小目标

找出单点，进行拆分，就是将每一个大单点都拆成一个小单点+多资源并行的形式。

在解决高并发问题的过程中，我们会不断地遇到新的单点：web server、单个操作系统、虚拟化/容器技术、编程语言运行架构、网络、UNIX 进程模型、数据库等。每遇到一个单点，我们都要见招拆招，使用架构工具拆掉它。计算机的虚拟化程度非常高，几乎每个单点都可以继续往下拆。

接下来大家就跟着我一起，一步一步将系统性能的上限从单机 100 QPS 提升到 1,000,000（一百万）QPS。

文章列表

找出单点，进行拆分（本文）
Apache 的性能瓶颈与 Nginx 的性能优势
基础设施并发：虚拟机与 Kubernetes（k8s）
隐藏在语言背后的魔鬼：运行架构为何会成为性能瓶颈
拆分网络单点(上)：应用网关、负载均衡和路由器(网关)
拆分网络单点(下)：SDN 如何替代百万人民币的负载均衡硬件(网关、LVS、交换机)
最难以解决的单点：数据库以及它背后的存储
将 InnoDB 剥的一丝不挂：B+ 树与 Buffer Pool
细数四代分布式数据库并拆解 TiDB 和 OceanBase（主从、中间件、KV、计算与存储分离、列存储、CAP定理）
理论无限容量：站在地球表面

找出第一个单点

大部分系统都是从单个虚拟机开始的，原始的资源可能只有 1 核 2G，你安装了一个 Apache，一个 MySQL，把代码部署上去，这个系统就开始对外服务了。如果系统用户数量增加了，你会发现，CPU 满了，这个时候，我们第一个应该拆的就是静态流量。

动静分离

大概是在 2013 年，我用从同学那里买的二手 MacBook Pro 跑过 Apache 和 Nginx 的性能测试，在本机访问同一张 jpg 图片的情况下，Apache 的 QPS 为 2 万出头，而 Nginx 则超过 8 万，四倍性能。

所以，如果你还在用 Apache 承载所有流量，在前面加一个 Nginx 就能显著降低 CPU 占用率，大幅提升系统性能。如果你再利用云服务商把这些静态资源用 CDN 来承载，你的静态资源压力还能再降低 90%。

动静分离以后，CPU 又满了，该怎么办呢？这个时候就需要把数据库拆出去了。

最适合独立部署的软件：数据库

如果应用代码和数据库跑在一个系统上，压力稍微大一点，很容易出现“债股双杀”的局面：MySQL 的响应变慢，应用代码就需要更长时间的等待，又要消耗更多的 CPU 资源，从而形成“内卷”和“踩踏”。只要你的系统不是用户极其少，或者你们公司极其扣，把数据库独立部署的收益都是要高于投入的：1 核 2G 的虚拟机就够 MySQL 跑到 200 QPS了，配合缓存支撑一个日 PV 100 万的小系统应该够了。

我的实际经验

进击的爬虫

2017 年，我维护的一个 SEO 网站突然遭遇大量爬虫的袭击：由于这个网站拥有数百万个内容页面，页面内也有着大量的“类似文章推荐”，在只依靠 MySQL like语句的情况下，单个页面的返回时间长达 300-500ms。一天两万的真实用户 UV 对系统的压力并不大，但这些爬虫不讲武德，上来就是 100 QPS，当时 1 核 2G 的虚拟机和 1 核 1G 的 MySQL 可遭了殃了，完全顶不住。

这些爬虫并不是正规大厂的爬虫，而是采集机器人，由于拥有海量代理 ip，对网站形成了 DDOS 态势，没法使用常规手段封禁，只能想办法抗住。

我首先做的，就是将静态资源全部 CDN 化，直接让 CPU 占用率降低了一半。然后就开始着手提升系统性能：

使用 ElasticSearch 提供“类似文章推荐”，将每个页面的响应时间压缩到了 200ms
提升数据库性能：增加索引，增加 Redis 缓存，使用定时任务刷新文章总数而不是实时计算，将响应时间压缩到了 120ms
访问 ES 的 HTTP 请求进行并行化：虽然 PHP 是一种阻塞语言，但是一次性发送多个 HTTP 请求的能力还是有的，平均每个页面有五次请求，每次 15ms，并行化以后从 15ms*5 减少到了 25ms，最终将平均响应时间压缩到了 70ms

同时，服务器和数据库也进行了计算资源的扩容，增加到了 2 核 4G 的虚拟机和 2 核 4G 的 MySQL，最终顶住了每天 200 万次页面访问的冲击，对比之下，真实用户 PV 每天只有十万左右。

这个时候可能有人会问了，既然是内容网站，为什么不静态化呢？因为数据量太大了，500 万个页面，一个页面 100KB，就是 476GB 的磁盘容量，这个量级太夸张了，不如做性能优化硬抗了，这么多静态资源的管理和刷新反而是个更大的问题。在百万量级下，数据库绝对是更好的数据存储解决方案，远比自己管理文件要更简单更稳定。

即便我做了那么多，还是不乏有一些爬虫愣头青在学习了 swoole 和 go 协程之后，对我的网站发动数千 QPS 的死亡冲锋，这个时候再怎么性能优化都是没用的，这时就需要使用倒数第二个工具：限流。

我做了三道限流关卡才最终顶住采集机器人 DDOS：

针对单个 ip 做请求频率限制
针对整个 /24 ip 段做请求频率限制（很多爬虫采用同一段内的多个 ip 绕过限流）
针对每个 UA 做请求频率限制

在这三板斧使出来以后，天下太平了，网站再也没有被突然发起的死亡冲锋搞挂过。

对了，既然限流是倒数第二个工具，肯定有人好奇最后一个工具是什么？那就是熔断，熔断属于系统鲁棒性工具，是善后用的，我们最后一篇文章还会再提一嘴。

接下来

下一篇文章，我们将看到真实的 Apache 性能瓶颈与 Nginx 的性能优势，同时我会继续现身说法，讲述团购秒杀业务的故事。

参考资料

性能之殇（二）-- 分支预测、流水线与多核 CPU https://lvwenhan.com/tech-epic/493.html

相关日志：

性能之殇（七）-- 分布式计算、超级计算机与神经网络共同的瓶颈

JohnLui — Thu, 22 Nov 2018 09:25:20 +0000

分布式计算是这些年的热门话题，各种大数据框架层出不穷，容器技术也奋起直追，各类数据库（Redis、ELasticsearch、MongoDB）也大搞分布式，可以说是好不热闹。分布式计算在大热的同时，也存在着两台机器也要硬上 Hadoop 的“面向简历编程”，接下来我就剖析一下分布式计算的本质，以及我的理解和体会。

分布式计算的本质

分布式计算来源于人们日益增长的性能需求与落后的 x86 基础架构之间的矛盾。恰似设计模式是面向对象对现实问题的一种妥协。

x86 服务器

x86 服务器，俗称 PC 服务器、微机服务器，近二十年以迅雷不及掩耳盗铃之势全面抢占了绝大部分的服务器市场，它和小型机比只有一个优势，其他的全是缺点，性能、可靠性、可扩展性、占地面积都不如小型机，但是一个优势就决定了每年 2000 多亿美元的 IDC 市场被 x86 服务器占领了 90%，这个优势就是价格。毕竟有钱能使磨推鬼嘛。

现有的分布式计算，无论是 Hadoop 之类的大数据平台，还是 HBase 这样的分布式数据库，无论是 Docker 这种容器排布，还是 Redis 这种朴素分布式数据库，其本质都是因为 x86 的扩展性不够好，导致大家只能自己想办法利用网络来自己构建一个宏观上更强性能更高负载能力的计算机。

x86 分布式计算，是一种新的计算机结构。

基于网络的 x86 服务器分布式计算，其本质是把网络当做总线，设计了一套新的计算机体系结构：

每一台机器就等于一个运算器加一个存储器
master 节点就是控制器加输入设备、输出设备

x86 分布式计算的弱点

上古时代，小型机的扩展能力是非常变态的，到今天，基于小型机的 Oracle 数据库系统依旧能做到惊人的性能和可靠性。实际上单颗 x86 CPU 的性能已经远超 IBM 小型机用的 PowerPC，但是当数量来到几百颗，x86 服务器集群就败下阵来，原因也非常简单：

小型机是专门设计的硬件和专门设计的软件，只面向这种规模（例如几百颗 CPU）的计算
小型机是完全闭源的，不需要考虑扩展性，特定的几种硬件在稳定性上前进了一大步
x86 的 IO 性能被架构锁死了，各种总线、PCI、PCIe、USB、SATA、以太网，为了个人计算机的便利性，牺牲了很多的性能和可靠性
小型机使用总线通信，可以实现极高的信息传递效率，极其有效的监控以及极高的故障隔离速度
x86 服务器基于网络的分布式具有天然的缺陷：
1. 操作系统决定了网络性能不足
2. 网络需要使用事件驱动处理，比总线电路的延迟高几个数量级
3. PC 机的硬件不够可靠，故障率高
4. 很难有效监控，隔离故障速度慢

x86 分布式计算的基本套路

Google 系大数据处理框架

2003 年到 2004 年间，Google 发表了 MapReduce、GFS（Google File System）和 BigTable 三篇技术论文，提出了一套全新的分布式计算理论。MapReduce 是分布式计算框架，GFS（Google File System）是分布式文件系统，BigTable 是基于 Google File System 的数据存储系统，这三大组件组成了 Google 的分布式计算模型。

MapReduce 的基本思想其实很容易理解：由于数据流实在是太大，所以需要基于磁盘，这样数据就被天然地分布到了多台机器上，然后“就地计算”即可，这被称作“计算向数据靠拢”。除此之外，MapReduce 还提供了全套的数据分片、信息交换、任务分发和聚合功能，使用者只需要使用自己的编程语言，分发任务即可，使用者甚至不需要知道具体的并发模型是怎么设计的，用就完了。

Hadoop、Spark、Storm 是目前最重要的三大分布式计算系统，他们都是承袭 Google 的思路实现并且一步一步发展到今天的。

Redis、MongoDB 的分布式

Redis 有两个不同的分布式方案。Redis Cluster 是官方提供的工具，它通过特殊的协议，实现了每台机器都拥有数据存储和分布式调节功能，性能没有损失。缺点就是缺乏统一管理，运维不友好。Codis 是一个非常火的 Redis 集群搭建方案，其基本原理可以简单地描述如下：通过一个 proxy 层，完全隔离掉了分布式调节功能，底层的多台机器可以任意水平扩展，运维十分友好。

MongoDB 官方提供了一套完整的分布式部署的方案，提供了 mongos 控制中心，config server 配置存储，以及众多的 shard（其底层一般依然有两台互为主从强数据一致性的 mongod）。这三个组件可以任意部署在任意的机器上，MongoDB 提供了 master 选举功能，在检测到 master 异常后会自动选举出新的 master 节点。

问题和瓶颈

人们费这么大的劲研究基于网络的 x86 服务器分布式计算，目的是什么？还不是为了省钱，想用一大票便宜的 PC 机替换掉昂贵的小型机、大型机。虽然人们已经想尽了办法，但还是有一些顽固问题无法彻底解决。

master 失效问题

无论怎样设计，master 失效必然会导致服务异常，因为网络本身不够可靠，所以监控系统的容错要做的比较高，所以基于网络的分布式系统的故障恢复时间一般在秒级。而小型机的单 CPU 故障对外是完全无感的。

现行的选举机制主要以节点上的数据以及节点数据之间的关系为依据，通过一顿猛如虎的数学操作，选举出一个新的 master。逻辑上，选举没有任何问题，如果 master 因为硬件故障而失效，新的 master 会自动顶替上，并在短时间内恢复工作。

而自然界总是狠狠地打人类的脸：

硬件故障概率极低，大部分 master 失效都不是因为硬件故障
如果是流量过大导致的 master 失效，那么选举出新的 master 也无济于事：提升集群规模才是解决之道
即使能够及时地在一分钟之内顶替上 master 的工作，那这一分钟的异常也可能导致雪崩式的 cache miss，从磁盘缓存到虚拟内存，从 TLB 到三级缓存，再到二级缓存和一级缓存，全部失效。如果每一层的失效会让系统响应时间增加五倍的话，那最终的总响应时长将是惊人的。

系统规模问题

无论是 Master-Slave 模式还是 Proxy 模式，整个系统的流量最终还是要落到一个特定的资源上。当然这个资源可能是多台机器，但是依旧无法解决一个严重的问题：系统规模越大，其本底性能损失就越大。

这其实是我们所在的这个宇宙空间的一个基本规律。我一直认为，这个宇宙里只有一个自然规律：熵增。既然我们这个宇宙是一个熵增宇宙，那么这个问题就无法解决。

超级计算机

超级计算机可以看成一个规模特别巨大的分布式计算系统，他的性能瓶颈从目前的眼光来看，是超多计算核心（数百万）的调节效率问题。其本质是通信速率不够快，信息传递的太慢，让数百万核心一起工作，传递命令和数据的工作占据了绝大多数的运行时间。

神经网络

深度学习这几年大火，其原因就是卷积神经网络（CNN）造就的 AlphaGo 打败了人类，计算机在这个无法穷举的游戏里彻底赢了。伴随着 Google 帝国的强大推力，深度学习，机器学习，乃至人工智能，这几个词在过去的两年大火，特别是在中美两国。现在拿手机拍张照背后都有机器学习你敢信？

机器学习的瓶颈，本质也是数据交换：机器学习需要极多的计算，而计算速度的瓶颈现在就在运算器和存储器的通信上，这也是显卡搞深度学习比 CPU 快数十倍的原因：显存和 GPU 信息交换的速度极快。

九九归一

分布式系统的性能问题，表现为多个方面，但是归根到底，其原因只是一个非常单纯的矛盾：人们日益增长的性能需求和数据一致性之间的矛盾。一旦需要强数据一致性，那就必然存在一个限制性能的瓶颈，这个瓶颈就是信息传递的速度。

同样，超级计算机和神经网络的瓶颈也都是信息传递的速度。

那么，信息传递速度的瓶颈在哪里呢？

我个人认为，信息传递的瓶颈最表层是人类的硬件制造水平决定的，再往底层去是冯·诺依曼架构决定的，再往底层去是图灵机的逻辑模型决定的。可是图灵机是计算机可行的理论基础呀，所以，还是怪这个熵增宇宙吧，为什么规模越大维护成本越高呢，你也是个成熟的宇宙了，该学会自己把自己变成熵减宇宙了。

【全系列完结】

相关日志：

性能之殇（六）-- 现代计算机最亲密的伙伴：局部性与乐观

JohnLui — Mon, 19 Nov 2018 10:34:17 +0000

冯·诺依曼架构中，指令和数据均存储在内存中，彻底打开了计算机“通用”的大门。这个结构中，“线性数组”内存天生携带了一个涡轮：局部性。

局部性分类

空间局部性

空间局部性是最容易理解的局部性：如果一段内存被使用，那么之后，离他最近的内存也最容易被使用，无论是数据还是指令都是这样。举一个浅显易懂的例子：

循环处理一个 Array，当处理完了 [2] 之后，下一个访问的就是 [3]，他们在内存里是相邻的。

时间局部性

如果一个变量所在的内存被访问过，那么接下来这一段内存很可能被再次访问，例子也非常简单：

$a = [];if ( !$b ) {    $a[] = $b;}

在一个 function 内，一个内存地址很可能被访问、修改多次。

乐观

“乐观”作为一种思考问题的方式广泛存在于计算机中，从硬件设计、内存管理、应用软件到数据库均广泛运用了这种思考方式，并给我们带来了十分可观的性能收益。

乐观的 CPU

第一篇文章中的 L1 L2 L3 三级缓存和第二篇文章中的分支预测与流水线，均是乐观思想的代表。

乐观的虚拟内存

虚拟内存依据计算机内存的局部性，将磁盘作为内存的本体，将内存作为磁盘的缓存，用很小的性能代价带来了数十倍并发进程数，是乐观思想的集大成者。

乐观的缓存

Java 经典面试题 LRU 缓存实现，也是乐观思想的一种表达。

同样，鸟哥的 yac 也是这一思想的强烈体现。

设计 Yac 的经验假设

对于一个应用来说, 同名的Cache键, 对应的Value, 大小几乎相当.
不同的键名的个数是有限的.
Cache的读的次数, 远远大于写的次数.
Cache不是数据库, 即使Cache失效也不会带来致命错误.

Yac 的限制

key的长度最大不能超过48个字符. (我想这个应该是能满足大家的需求的, 如果你非要用长Key, 可以MD5以后再存)
Value的最大长度不能超过64M, 压缩后的长度不能超过1M.
当内存不够的时候, Yac会有比较明显的踢出率, 所以如果要使用Yac, 那么尽量多给点内存吧.

乐观锁

乐观锁在并发控制和数据库设计里都拥有重要地位，其本质就是在特定的需求下，假定不会冲突，冲突之后再浪费较长时间处理，比直接每次请求都浪费较短时间检测，总体的性能高。乐观锁在算法领域有着非常丰富而成熟的应用。

乐观的分布式计算

分布式计算的核心思想就是乐观，由 95% 可靠的 PC 机组成的分布式系统，起可靠性也不会达到 99.99%，但是绝大多数场景下，99% 的可靠性就够了，毕竟拿 PC 机做分布式比小型机便宜得多嘛。下一篇文章我会详细介绍分布式计算的性能之殇，此处不再赘述。

乐观的代价

出来混，早晚是要还的。

乐观给了我们很多的好处，总结起来就是一句话：以微小的性能损失换来大幅的性能提升。但是，人在河边走，哪有不湿鞋。每一个 2015 年 6 月入 A 股的散户，都觉得大盘还能再翻一番，岂不知一周之后，就是股灾了。

乐观的代价来自于“微小的性能损失”，就跟房贷市场中“微小的风险”一样，当大环境小幅波动的时候，他确实能承担压力，稳住系统，但是怕就怕突然雪崩：

虚拟内存中的内存的局部性突然大幅失效，磁盘读写速度成了内存读写速度，系统卡死
分布式数据库的六台机器中的 master 挂了，系统在一秒内选举出了新的 master，你以为系统会稳定运行？master 挂掉的原因就是压力过大，这样就会导致新的 master 瞬间又被打挂，然后一台一台地继续，服务彻底失效。例如：「故障说明」对六月六日 LeanCloud 多项服务发生中断的说明

相关日志：

性能之殇（五）-- DPDK、SDN 与大页内存

JohnLui — Mon, 19 Nov 2018 06:26:23 +0000

上文我们说到，当今的 x86 通用微处理器已经拥有了十分强大的性能，得益于其庞大的销量，让它的价格和专用 CPU 比也有着巨大的优势，于是，软件定义一切诞生了！

软路由

说到软路由，很多人都露出了会心的微笑，因为其拥有低廉的价格、超多的功能、够用的性能和科学上网能力。现在网上能买到的软路由，其本质就是一个 x86 PC 加上多个网口，大多是基于 Linux 或 BSD 内核，使用 Intel 低端被动散热 CPU 打造出的千兆路由器，几百块就能实现千兆的性能，最重要的是拥有 QOS、多路拨号、负载均衡、防火墙、VPN 组网、科学上网等强大功能，传统路由器抛开科学上网不谈，其他功能也不是几百块就搞得定的。

软路由的弱点

软路由便宜，功能强大，但是也有弱点。它最大的弱点其实是性能：传统 *UNIX 网络栈的性能实在是不高。

软路由的 NAT 延迟比硬路由明显更大，而且几百块的软路由 NAT 性能也不够，跑到千兆都难，而几百块的硬路由跑到千兆很容易。那怎么办呢？改操作系统啊。

SDN

软件定义网络，其本质就是使用计算机科学中最常用的“虚拟机”构想，将传统由硬件实现的交换、网关、路由、NAT 等网络流量控制流程交由软件来统一管理：可以实现硬件不动，网络结构瞬间变化，避免了传统的停机维护调试的烦恼，也为大规模公有云计算铺平了道路。

虚拟机

虚拟机的思想自底向上完整地贯穿了计算机的每一个部分，硬件层有三个场效应管虚拟出的 SRAM、多个内存芯片虚拟出的一个“线性数组内存”，软件层有 jvm 虚拟机，PHP 虚拟机（解释器）。自然而然的，当网络成为了更大规模计算的瓶颈的时候，人们就会想，为什么网络不能虚拟呢？

OpenFlow

最开始，SDN 还是基于硬件来实施的。Facebook 和 Google 使用的都是 OpenFlow 协议，作用在数据链路层（使用 MAC 地址通信的那一层，也就是普通交换机工作的那一层），它可以统一管理所有网关、交换等设备，让网络架构实时地做出改变，这对这种规模的公司所拥有的巨大的数据中心非常重要。

DPDK

DPDK 是 SDN 更前沿的方向：使用 x86 通用 CPU 实现 10Gbps 甚至 40Gbps 的超高速网关（路由器）。

DPDK 是什么

Intel DPDK 全称为 Intel Data Plane Development Kit，直译为“英特尔数据平面开发工具集”，它可以摆脱 *UNIX 网络数据包处理机制的局限，实现超高速的网络包处理。

DPDK 的价值

当下，一台 40G 核心网管路由器动辄数十万，而 40G 网卡也不会超过一万块，而一颗性能足够的 Intel CPU 也只需要几万块，软路由的性价比优势是巨大的。

实际上，阿里云和腾讯云也已经基于 DPDK 研发出了自用的 SDN，已经创造了很大的经济价值。

【DPDK峰会回顾】支撑双十一的高性能负载均衡是如何炼成的阿里云携领先SDN能力，亮相全球网络技术盛会ONS 腾讯云超高网络性能云主机揭秘 F-Stack 全用户态 (Kernel Bypass) 服务开发套件

怎么做到的？

DPDK 使用自研的数据链路层（MAC地址）和网络层（ip地址）处理功能（协议栈），抛弃操作系统（Linux，BSD 等）提供的网络处理功能（协议栈），直接接管物理网卡，在用户态处理数据包，并且配合大页内存和 NUMA 等技术，大幅提升了网络性能。有论文做过实测，10G 网卡使用 Linux 网络协议栈只能跑到 2G 多，而 DPDK 分分钟跑满。

用户态网络栈

上篇文章我们已经说到，Unix 进程在网络数据包过来的时候，要进行一次上下文切换，需要分别读写一次内存，当系统网络栈处理完数据把数据交给用户态的进程如 Nginx 去处理还会出现一次上下文切换，还要分别读写一次内存。夭寿啦，一共 1200 个 CPU 周期呀，太浪费了。

而用户态协议栈的意思就是把这块网卡完全交给一个位于用户态的进程去处理，CPU 看待这个网卡就像一个假肢一样，这个网卡数据包过来的时候也不会引发系统中断了，不会有上下文切换，一切都如丝般顺滑。当然，实现起来难度不小，因为 Linux 还是分时系统，一不小心就把 CPU 时间占完了，所以需要小心地处理阻塞和缓存问题。

NUMA

NUMA 来源于 AMD Opteron 微架构，其特点是将 CPU 直接和某几根内存使用总线电路连接在一起，这样 CPU 在读取自己拥有的内存的时候就会很快，代价就是读取别 U 的内存的时候就会比较慢。这个技术伴随着服务器 CPU 核心数越来越多，内存总量越来越大的趋势下诞生的，因为传统的模型中不仅带宽不足，而且极易被抢占，效率下降的厉害。

NUMA 利用的就是电子计算机（图灵机 + 冯·诺依曼架构）天生就带的涡轮：局部性。 涡轮：汽车发动机加上涡轮，可以让动力大增油耗降低

细说大页内存

内存分页

为了实现虚拟内存管理机制，前人们发明了内存分页机制。这个技术诞生的时候，内存分页的默认大小是 4KB，而到了今天，绝大多数操作系统还是用的这个数字，但是内存的容量已经增长了不知道多少倍了。

TLB miss

TLB（Translation Lookaside Buffers）转换检测缓冲区，是内存控制器中为增虚拟地址到物理地址的翻译速度而设立的一组电子元件，最近十几年已经随着内存控制器被集成到了 CPU 内部，每颗 CPU 的 TLB 都有固定的长度。

如果缓存未命中（TLB miss），则要付出 20-30 个 CPU 周期的带价。假设应用程序需要 2MB 的内存，如果操作系统以 4KB 作为分页的单位，则需要 512 个页面，进而在 TLB 中需要 512 个表项，同时也需要 512 个页表项，操作系统需要经历至少 512 次 TLB Miss 和 512 次缺页中断才能将 2MB 应用程序空间全部映射到物理内存；然而，当操作系统采用 2MB 作为分页的基本单位时，只需要一次 TLB Miss 和一次缺页中断，就可以为 2MB 的应用程序空间建立虚实映射，并在运行过程中无需再经历 TLB Miss 和缺页中断。

大页内存

大页内存 HugePage 是一种非常有效的减少 TLB miss 的方式，让我们来进行一个简单的计算。

2013 年发布的 Intel Haswell i7-4770 是当年的民用旗舰 CPU，其在使用 64 位 Windows 系统时，可以提供 1024 长度的 TLB，如果内存页的大小是 4KB，那么总缓存内存容量为 4MB，如果内存页的大小是 2MB，那么总缓存内存容量为 2GB。显然后者的 TLB miss 概率会低得多。

DPDK 支持 1G 的内存分页配置，这种模式下，一次性缓存的内存容量高达 1TB，绝对够用了。

不过大页内存的效果没有理论上那么惊人，DPDK 实测有 10%~15% 的性能提升，原因依旧是那个天生就带的涡轮：局部性。

相关日志：

性能之殇（四）-- Unix 进程模型的局限

JohnLui — Wed, 14 Nov 2018 09:24:34 +0000

Unix 系统 1969 年诞生于 AT&T 旗下的贝尔实验室。1971 年，Ken Thompson（Unix之父）和 Dennis Ritchie（C语言之父）共同发明了 C 语言，并在 1973 年用 C 语言重写了 Unix。

Unix 自诞生起就是多用户、多任务的分时操作系统，其引入的“进程”概念是计算机科学中最成功的概念之一，几乎所有现代操作系统都是这一概念的受益者。但是进程也有局限，由于 AT&T 是做电话交换起家，所以 Unix 进程在设计之初就是延续的电话交换这个业务需求：保证电话交换的效率，就够了。

1984年，Richard Stallman 发起了 GNU 项目，目标是创建一个完全自由且向下兼容 Unix 的操作系统。之后 Linus Torvalds 与 1991 年发布了 Linux 内核，和 GNU 结合在了一起形成了 GNU/Linux 这个当下最成功的开源操作系统。所以 Redhat、CentOS、Ubuntu 这些如雷贯耳的 Linux 服务器操作系统，他们的内存模型也是高度类似 Unix 的。

Unix 进程模型介绍

进程是操作系统提供的一种抽象，每个进程在自己看来都是一个独立的图灵机：独占 CPU 核心，一个一个地运行指令，读写内存。进程是计算机科学中最重要的概念之一，是进程使多用户、多任务成为了可能。

上下文切换

操作系统使用上下文切换让一个 CPU 核心上可以同时运行多个进程：在宏观时间尺度，例如 5 秒内，一台电脑的用户会认为他的桌面进程、音乐播放进程、鼠标响应进程、浏览器进程是在同时运行的。

图片来自《CS:APP》

上下文切换的过程

以下就是 Linux 上下文切换的过程：

假设正在运行网易云音乐进程，你突然想搜歌，假设焦点已经位于搜索框内。

当前进程是网易云音乐，它正在优哉游哉的播放着音乐
你突然打字，CPU 接到键盘发起的中断信号（异常控制流中的一个异常），准备调起键盘处理进程
将网易云音乐进程的寄存器、栈指针、程序计数器保存到内存中
将键盘处理进程的寄存器、栈指针、程序计数器从内存中读出来，写入到 CPU 内部相应的模块中
执行程序计数器的指令，键盘处理程序开始处理键盘输入
完成了一次上下文切换

名词解释

寄存器：CPU 核心里的用于暂时存储指令、地址和数据的电路，和内核频率一样，速度极快
栈指针：该进程所拥有的栈的指针
程序计数器：简称 PC，它存储着内核将要执行的下一个指令的内存地址。程序计数器是图灵机的核心组成部分。还记得冯·诺依曼架构吗，它的一大创造就是把指令和数据都存在内存里，让计算机获得了极大的自由度。

Unix 进程模型的局限

Unix 进程模型十分的清晰，上下文切换使用了一个非常简单的操作就实现了多个进程的宏观同时运行，是一个伟大的杰作。但是它却存在着一个潜在的缺陷，这个缺陷在 Unix 诞生数十年之后才渐渐浮出了水面。

致命的内存

进程切换过程中需要分别写、读一次内存，这个操作在 Unix 刚发明的时候没有发现有什么性能问题，但是 CPU 裹挟着摩尔定律一路狂奔，2000 年，AMD 领先 Intel 两天发布了第一款 1GHz 的微处理器 “AMD Athlon 1GHz”，此时一个指令的执行时间已经低到了 1ns，而其内存延迟高达 60ns，这导致了一个以前不曾出现的问题：

上下文切换读写内存的时间成了整个系统的性能瓶颈。

软件定义一切

我们将在下一篇文章探讨 SDN（软件定义网络），在这里我们先来看一下“软件定义一切”这个概念。当下，不仅有软件定义网络，还有软件定义存储，甚至出现了软件定义基础架构（这不就是云计算嘛）。是什么导致了软件越来越强势，开始倾入过去只有专业的硬件设备才能提供的高性能高稳定性服务呢？我认为，就是通用计算机的发展导致的，确切地说，是 CPU 和网络的发展导致的。

当前的民用顶级 CPU 的性能已经爆表，因为规模巨大，所以其价格也要显著低于同性能的专用处理器：自建 40G 软路由的价格大约是 40G 专用路由价格的二十分之一。

下一篇文章我们将讨论上图中的 DPDK、SDN 以及知名的性能优化方案“大页内存”。

相关日志：

性能之殇（三）-- 通用电子计算机的胎记：事件驱动

JohnLui — Tue, 13 Nov 2018 10:38:09 +0000

Event-Driven（事件驱动）这个词这几年随着 Node.js® 的大热也成了一个热词，似乎已经成了“高性能”的代名词，殊不知事件驱动其实是通用计算机的胎记，是一种与生俱来的能力。本文我们就要一起了解一下事件驱动的价值和本质。

通用电子计算机中的事件驱动

首先我们定义当下最火的 x86 PC 机为典型的通用电子计算机：可以写文章，可以打游戏，可以上网聊天，可以读U盘，可以打印，可以设计三维模型，可以编辑渲染视频，可以作路由器，还可以控制巨大的工业机器。那么，这种计算机的事件驱动能力就很容易理解了：

假设 Chrome 正在播放 Youtube 视频，你按下了键盘上的空格键，视频暂停了。这个操作就是事件驱动：计算机获得了你单击空格的事件，于是把视频暂停了。
假设你正在跟人聊 QQ，别人发了一段话给你，计算机获得了网络传输的事件，于是将信息提取出来显示到了屏幕上，这也是事件驱动。

事件驱动的实现方式

事件驱动本质是由 CPU 提供的，因为 CPU 作为控制器 + 运算器，他需要随时响应意外事件，例如上面例子中的键盘和网络。

CPU 对于意外事件的响应是依靠 Exception Control Flow（异常控制流）来实现的。

强大的异常控制流

异常控制流是 CPU 的核心功能，它是以下听起来就很牛批的功能的基础：

时间片

CPU 时间片的分配也是利用异常控制流来实现的，它让多个进程在宏观上在同一个 CPU 核心上同时运行，而我们都知道在微观上在任一个时刻，每一个 CPU 核心都只能运行一条指令。

虚拟内存

这里的虚拟内存不是 Windows 虚拟内存，是 Linux 虚拟内存，即逻辑内存。

逻辑内存是用一段内存和一段磁盘上的存储空间放在一起组成一个逻辑内存空间，对外依然表现为“线性数组内存空间”。逻辑内存引出了现代计算机的一个重要的性能观念：

内存局部性天然的让相邻指令需要读写的内存空间也相邻，于是可以把一个进程的内存放到磁盘上，再把一小部分的“热数据”放到内存中，让其作为磁盘的缓存，这样可以在降低很少性能的情况下，大幅提升计算机能同时运行的进程的数量，大幅提升性能。

虚拟内存的本质其实是使用缓存 + 乐观的手段提升计算机的性能。

系统调用

系统调用是进程向操作系统索取资源的通道，这也是利用异常控制流实现的。

硬件中断

键盘点击、鼠标移动、网络接收到数据、麦克风有声音输入、插入 U 盘这些操作全部需要 CPU 暂时停下手头的工作，来做出响应。

进程、线程

进程的创建、管理和销毁全部都是基于异常控制流实现的，其生命周期的钩子函数也是操作系统依赖异常控制流实现的。线程在 Linux 上和进程几乎没有功能上的区别。

编程语言中的 try catch

C++ 编译成的二进制程序，其异常控制语句是直接基于异常控制流的。Java 这种硬虚拟机语言，PHP 这种软虚拟机语言，其异常控制流的一部分也是有最底层的异常控制流提供的，另一部分可以由逻辑判断来实现。

基于异常控制流的事件驱动

其实现在人们在谈论的事件驱动，是 Linux kernel 提供的 epoll，是 2002 年 10 月 18 号伴随着 kernel 2.5.44 发布的，是 Linux 首次将操作系统中的 I/O 事件的异常控制流暴露给了进程，实现了本文开头提到的 Event-Driven（事件驱动）。

Kqueue

FreeBSD 4.1 版本于 2000 年发布，起携带的 Kqueue 是 BSD 系统中事件驱动的 API 提供者。BSD 系统如今已经遍地开花，从 macOS 到 iOS，从 watchOS 到 PS4 游戏机，都受到了 Kqueue 的蒙荫。

epoll 是什么

操作系统本身就是事件驱动的，所以 epoll 并不是什么新发明，而只是把本来不给用户空间用的 api 暴露在了用户空间而已。

epoll 做了什么

网络 IO 是一种纯异步的 IO 模型，所以 Nginx 和 Node.js® 都基于 epoll 实现了完全的事件驱动，获得了相比于 select/poll 巨量的性能提升。而磁盘 IO 就没有这么幸运了，因为磁盘本身也是单体阻塞资源：即有进程在写磁盘的时候，其他写入请求只能等待，就是天王老子来了也不行，磁盘做不到呀。所以磁盘 IO 是基于 epoll 实现的非阻塞 IO，但是其底层依旧是异步阻塞，即便这样，性能也已经爆棚了。Node.js 的磁盘 IO 性能远超其他解释型语言，过去几年在 web 后端霸占了一些对磁盘 IO 要求高的领域。

相关日志：

性能之殇（二）-- 分支预测、流水线与多核 CPU

JohnLui — Tue, 13 Nov 2018 05:04:44 +0000

CPU 硬件为了提高性能，逐步发展出了指令流水线（分支预测）和多核 CPU，本文我们就将简单地探讨一下它们的原理和效果。

指令流水线

在一台纯粹的图灵机中，指令是一个一个顺序执行的。而现实世界的通用计算机所用的很多基础算法都是可以并行的，例如加法器和乘法器，它们可以很容易地被切分成可以同时运行的多个指令，这样就可以大幅提升性能。

指令流水线，说白了就是 CPU 电路层面的并发。

Intel Core i7 自 Sandy Bridge（2010）架构以来一直都是 14 级流水线设计。基于 Cedar Mill 架构的最后一代奔腾4，在 2006 年就拥有 3.8GHz 的超高频率，却因为其长达 31 级的流水线而成了为样子货，被 AMD 1GHz 的芯片按在地上摩擦。

RISC机器的五层流水线示意图

下图形象的展示了流水线式如何提高性能的。

缺点

指令流水线通过硬件层面的并发来提高性能，却也带来了一些无法避免的缺点。

设计难度高，一不小心就成为了高频低能的奔四
并发导致每一条指令的执行时间变长
优化难度大，有时候两行代码的顺序变动就可能导致数倍的性能差异，这对编译器提出了更高的要求
如果多次分支预测失败，会导致严重的性能损失

分支预测

指令形成流水线以后，就需要一种高效的调控来保证硬件层面并发的效果：最佳情况是每条流水线里的十几个指令都是正确的，这样完全不浪费时钟周期。而分支预测就是干这个的：

分支预测器猜测条件表达式两路分支中哪一路最可能发生，然后推测执行这一路的指令，来避免流水线停顿造成的时间浪费。但是，如果后来发现分支预测错误，那么流水线中推测执行的那些中间结果全部放弃，重新获取正确的分支路线上的指令开始执行，这就带来了十几个时钟周期的延迟，这个时候，这个 CPU 核心就是完全在浪费时间。

幸运的是，当下的主流 CPU 在现代编译器的配合下，把这项工作做得越来越好了。

还记得那个让 Intel CPU 性能跌 30% 的漏洞补丁吗，那个漏洞就是 CPU 设计的时候，分支预测设计的不完善导致的。

多核 CPU

多核 CPU 的每一个核心拥有自己独立的运算单元、寄存器、一级缓存、二级缓存，所有核心共用同一条内存总线，同一段内存。

多核 CPU 的出现，标志着人类的集成电路工艺遇到了一个严酷的瓶颈，没法再大规模提升单核性能，只能使用多个核心来聊以自慰。实际上，多核 CPU 性能的提升极其有限，远不如增加一点点单核频率提升的性能多。

优势

多核 CPU 的优势很明显，就是可以并行地执行多个图灵机，可以显而易见地提升性能。只不过由于使用同一条内存总线，实际带来的效果有限，并且需要操作系统和编译器的密切配合才行。

题外话： AMD64 技术可以运行 32 位的操作系统和应用程序，所用的方法是依旧使用 32 位宽的内存总线，每计算一次要取两次内存，性能提升也非常有限，不过好处就是可以使用大于 4GB 的内存了。大家应该都没忘记第一篇文章中提到的冯·诺依曼架构拥有 CPU 和内存通信带宽不足的弱点。（注：AMD64 技术是和 Intel 交叉授权的专利，i7 也是这么设计的）

劣势

多核 CPU 劣势其实更加明显，但是人类也没有办法，谁不想用 20GHz 的 CPU 呢，谁想用这八核的 i7 呀。

内存读写效率不变，甚至有降低的风险
操作系统复杂度提升很多倍，计算资源的管理复杂了太多了
依赖操作系统的进步：微软以肉眼可见的速度，在这十几年间大幅提升了 Windows 的多核效率和安全性：XP 只是能利用，7 可以自动调配一个进程在多个核心上游走，2008R2 解决了依赖 CPU0 调度导致死机的 bug（中国的银行提的 bug 哦），8 可以利用多核心启动，10 优化了杀进程依赖 CPU0 的问题。

超线程技术
Intel 的超线程技术是将 CPU 核心内部再分出两个逻辑核心，只增加了 5% 的裸面积，就带来了 15%~30% 的性能提升。

怀念过去

Intel 肯定怀念摩尔定律提出时候的黄金年代，只依靠工艺的进步，就能一两年就性能翻番。AMD 肯定怀念 K8 的黄金一代，1G 战 4G，靠的就是把内存控制器从北桥芯片移到 CPU 内部，提升了 CPU 和内存的通信效率，自然性能倍增。而今天，人类的技术已经到达了一个瓶颈，只能通过不断的提升 CPU 和操作系统的复杂度来获得微弱的性能提升，呜呼哀哉。

不过我们也不能放弃希望，AMD RX VAGA64 显卡拥有 2048 位的显存位宽，理论极限还是很恐怖的，这可能就是未来内存的发展方向。

相关日志：