3、内存层级结构：CPU寄存器、L1/L2/L3缓存、主存(RAM)、SSD/HDD。理解局部性原理。
聊到Tick级数据缓存，很多人第一反应就是「多开几个HashMap」。嗯，这想法没错，但远远不够。你想想看，一个高频交易系统，每秒处理几万笔Tick数据，如果每次读写都跑到主存里折腾，那延迟早就爆了。
我个人习惯，在讲缓存策略之前，先带团队把内存层级结构理清楚。说白了，这就是计算机的「存储金字塔」。每一层速度差一个数量级，成本也差一个数量级。不理解这个，你写的缓存代码就是空中楼阁。
3.1 存储金字塔：从纳秒到毫秒
先看一张我手绘的结构图，把整个层级关系说清楚：
这张图我每次培训都会拿出来。你看，从CPU寄存器到HDD，延迟差了整整7个数量级。10纳秒 vs 10毫秒，这是什么概念？一次硬盘寻道的时间，CPU可以执行几千万条指令。
核心认知：Tick级数据处理的本质，就是尽量让数据停留在金字塔的上层。每次从主存加载数据，都意味着上百纳秒的浪费。如果数据在L1缓存里命中，延迟只有1纳秒左右。
3.2 每一层的角色与特点
3.2.1 CPU寄存器
这是离CPU最近的地方，速度最快，但容量极小。一般也就几十个字节。我在项目中见过有人试图把Tick数据塞进寄存器，这根本不现实。寄存器只适合存放当前正在计算的几个变量，比如循环计数器、临时累加器。
3.2.2 L1/L2/L3缓存
这三层是CPU内部的高速缓存。L1最快但最小，L3最大但相对慢一些。我记得有一次优化一个Tick聚合引擎，发现热点数据在L2缓存里频繁miss。后来调整了数据结构，把经常一起访问的字段放到同一个缓存行里，L2命中率从70%提到了95%以上。
避坑指南：我曾经踩过一个坑——把Tick数据按时间戳排序后，用链表存储。结果遍历时CPU缓存行完全失效，因为链表节点在内存里是离散的。后来改成数组，性能直接翻倍。这就是空间局部性的威力。
3.2.3 主存 (RAM)
主存是Tick数据的主要战场。几百GB的Tick历史数据，不可能全塞进CPU缓存。但问题是，主存访问延迟是L1缓存的300倍。所以策略很明确：把最热的数据（比如最近1秒的Tick）留在缓存里，冷数据放主存。
3.2.4 SSD/HDD
SSD和HDD属于持久化存储。对于Tick级系统，HDD基本被淘汰了，延迟太高。SSD虽然快，但跟主存比还是差了几个数量级。我一般只用SSD做历史数据归档和回放，实时交易绝不碰磁盘。
3.3 局部性原理：缓存命中的命门
为什么局部性原理这么重要？说白了，CPU缓存不是万能的，它只能缓存一小块数据。如果程序访问内存的模式是「跳跃式」的，缓存就形同虚设。
局部性分两种：
- 时间局部性：刚刚访问过的数据，很可能马上再次访问。比如循环里的累加变量。
- 空间局部性：访问了一个地址，附近的地址很可能也会被访问。比如遍历数组。
你想想看，Tick数据天然具有时间局部性——最新的Tick会被反复查询。所以缓存策略应该优先保留最近的数据。空间局部性呢？如果你把Tick的price、volume、timestamp放在一个结构体里，访问price时，volume和timestamp也会被一起加载到缓存行里。
注意：缓存行大小通常是64字节。如果你把不相关的字段塞进同一个结构体，反而会污染缓存。我见过有人把Tick数据和元数据（比如交易所名称字符串）放在一起，结果每次加载都多带一堆没用的字节，白白浪费带宽。
3.4 实战：Tick数据的内存布局优化
讲个具体的例子。假设我们要缓存1秒内的所有Tick，每个Tick包含：
| 字段 | 类型 | 大小 | 访问频率 |
|---|---|---|---|
| timestamp | int64 | 8字节 | 高 |
| price | double | 8字节 | 高 |
| volume | int64 | 8字节 | 中 |
| side | int8 | 1字节 | 低 |
| exchange | int16 | 2字节 | 低 |
如果按常规方式定义结构体，编译器可能会填充字节对齐，导致一个Tick占用超过32字节。但如果我们把高频访问的字段放在前面：
// 优化后的Tick结构体
struct Tick {
int64_t timestamp; // 8字节
double price; // 8字节
int64_t volume; // 8字节
int8_t side; // 1字节
int16_t exchange; // 2字节
// 填充5字节到24字节对齐
}; // 总共24字节，一个缓存行可以放2个多Tick这样设计后，访问timestamp和price时，它们大概率在同一个缓存行里。我实测过，这种布局比随意排列的结构体，缓存命中率提升了约15%。
总结一下：内存层级结构不是理论概念，它是Tick级系统性能的基石。理解每一层的延迟和容量，利用局部性原理优化数据布局，才能写出真正高效的缓存代码。别等到线上出现延迟抖动，才想起来查缓存命中率——那时候就晚了。
公众号:蓝海数据掘金营，微信deep3321