1. 课程导入与容量规划全景

内存密集型业务并不是简单地“内存占用高”，而是指一类性能与容量几乎由内存子系统决定的负载：数据库缓冲池、内存数据库、实时分析、Java 大堆应用、缓存与键值存储、虚拟化与容器密度型负载等。它们的共同特征是工作集（Working Set）长期驻留内存，一旦容量不足就会触发换页、缓存命中率下降、GC 停顿加剧，性能呈断崖式下跌，而不是平滑退化。因此，这类业务的容量规划核心不是“CPU 够不够快”，而是“内存够不够大、带宽够不够宽、延迟够不够稳”。

Intel Xeon 平台在这类业务中扮演的是“内存容量与带宽的承载底座”角色。以当前主流平台为例，单路可提供 8 通道 DDR5，配合 MRDIMM 或 RDIMM 可显著提升单路容量与带宽；多路系统通过 UPI 互联，形成 NUMA 架构。这意味着同一台服务器内部，内存访问存在“本地节点”与“远端节点”的差异：本地访问延迟低、带宽高，跨 UPI 访问则延迟上升。容量规划若只算总内存，而忽略 NUMA 拓扑与每通道均衡，就会出现“总量够、性能不够”的典型问题。

从业务需求到硬件选型的端到端框架，可以概括为四层映射：业务指标层（并发用户、TPS、数据量、SLA）→ 资源需求层（工作集大小、内存带宽、容量余量）→ 平台能力层（Xeon 型号、通道数、单条容量、NUMA 节点数）→ 配置输出层（内存条数量与规格、通道填充方式、BIOS 策略、监控阈值）。这个框架的价值在于：任何一次扩容或选型，都能追溯到它服务的业务指标，而不是凭经验“加几条内存”。

理解这个框架后，需要明确容量规划的目标与输出物。目标有三个层次：第一是“装得下”，即总容量覆盖工作集并留有余量；第二是“跑得动”，即内存带宽与 NUMA 本地化率满足吞吐要求；第三是“扩得起”，即预留通道与插槽，使未来扩容不必更换整机。对应的输出物通常包括：内存配置清单（型号、容量、数量、插槽位置）、NUMA 绑定建议、容量水位监控指标与告警阈值、以及一份可复算的容量估算表。

下面给出一份可直接参考的容量估算表模板，字段围绕内存密集型业务的实际决策点设计。表中数值为教学示例，用于说明计算逻辑，并非实测结果。

从表中可以看到，容量规划不是一步到位的“算总数”，而是先由业务数据量推导工作集，再叠加余量得到目标容量，最后反向映射到通道数与单条容量。这里有一个容易被忽略的约束：通道填充方式会影响带宽。若只插一半通道，虽然容量可能达标，但带宽减半，内存密集型业务的吞吐会明显受限。因此，规划时应优先保证所有通道均有内存，再通过单条容量调整总量。

最后需要建立“从业务需求到硬件选型”的闭环意识。容量规划不是一次性任务，而是一个持续校准的过程：上线前用估算表确定初始配置，上线后通过监控观察实际内存使用率、缓存命中率、NUMA 远端访问比例，再反推估算是否偏保守或偏激进。只有把业务指标、资源需求、平台能力和配置输出串成一条可追溯的链路，后续的扩容、调优和故障排查才有共同的语言和依据。