4. 数据结构设计：因子数据的存储结构、评分结果的数据结构、内存对齐与缓存行优化

在低延迟评分接口中，数据结构的定义直接决定了内存访问效率、缓存命中率以及序列化/反序列化的开销。本节将围绕因子数据的存储布局、评分结果的紧凑表示，以及利用内存对齐与缓存行填充来避免伪共享（False Sharing）展开设计。

4.1 因子数据的存储结构

因子数据通常以时间序列或截面快照的形式存在。为了满足低延迟读取，我们采用 列式存储（Columnar Layout） 与 预分配连续内存 的策略。

4.2 评分结果的数据结构

评分结果需要同时支持高吞吐写入（评分引擎产出）和低延迟读取（API 响应组装）。我们定义两种视图：内部紧凑表示 和 外部序列化表示。

4.2.1 内部紧凑表示（ScoreResult）

// 64字节对齐，恰好占满一个缓存行
struct alignas(64) ScoreResult {
    uint64_t instrument_id;   // 8字节
    int64_t  timestamp_ns;    // 8字节
    double   score;           // 8字节
    uint32_t factor_mask;     // 4字节，标识参与评分的因子
    uint16_t version;         // 2字节
    uint16_t flags;           // 2字节，状态/质量标记
    // 填充32字节至64字节边界
    uint8_t  padding[32];
};
static_assert(sizeof(ScoreResult) == 64, "ScoreResult must be cache-line sized");

4.2.2 外部序列化表示（API 响应）

对外 API 使用 FlatBuffers 或 Cap'n Proto 进行零拷贝序列化，避免 JSON 解析开销。响应结构体直接映射到内部 ScoreResult 的内存布局，仅做字节序转换。

4.3 内存对齐与缓存行优化

现代 CPU 缓存行通常为 64 字节。当多个线程同时修改位于同一缓存行的不同变量时，会引发 伪共享，导致性能骤降。我们通过以下策略规避：

• 结构体对齐： 使用 alignas(64) 确保关键结构体起始地址与缓存行对齐。
• 缓存行填充： 在 ScoreResult 末尾显式填充至 64 字节，确保每个对象独占一个缓存行。
• 线程本地存储： 每个评分线程拥有独立的 FactorBuffer 实例，通过 thread_local 避免线程间共享。
• 预取指令： 在遍历因子数组时，使用 __builtin_prefetch 提前加载下一个缓存行。

4.4 内存布局对比：AoS vs SoA

在因子数据存储中，我们选择 SoA（Structure of Arrays） 而非传统的 AoS（Array of Structures）。

4.5 数据结构设计检查清单

• 对齐检查： 所有跨线程访问的结构体使用 alignas(64)。
• 大小检查： 使用 static_assert 确保结构体大小为 64 的整数倍。
• 填充检查： 在结构体末尾显式添加 padding 字段，避免编译器自动填充导致不可预测。
• 序列化检查： 内部表示与外部协议字段顺序一致，支持零拷贝转换。
• 预取检查： 在循环访问因子数组前，提前 2-3 次迭代预取数据。