用数学（和Rust）再省下100TB内存
内容提要
Cloudflare的Pingora后端路由器因一致性哈希环过多导致内存占用过高。团队将索引从32位压缩为16位节省25%内存，并通过数学推导证明可将每服务器哈希数减少90%而不增加误差。迁移采用双环并行、按数据中心分批切换，避免缓存失效冲击源站，最终全球回收超100TB内存。
延伸解读
内存优化背后的数学权衡
文章通过数学推导证明，一致性哈希的误差随每服务器哈希数增加而递减，但收益递减明显。当哈希数从1万增至10万时，误差仅降低0.7%，且32位哈希碰撞概率上升会引入额外误差。因此团队将哈希数减少90%而不显著增加误差，这体现了量化分析在系统优化中的关键作用。
迁移策略：双环并行与分数据中心切换
直接切换哈希环会导致缓存大规模失效，冲击源站。团队采用双环并行运行，通过迁移框架按请求哈希决定使用新旧环，并分数据中心逐步推进。这种控制爆炸半径的方式，结合实时监控，确保了迁移安全，为类似系统变更提供了可复用的模式。
Rust内存布局的陷阱与技巧
将索引从32位压缩为16位时，Rust的对齐规则会使结构体大小仍为8字节。团队通过将结构体改为字节数组并手动实现getter，避免了#[repr(packed)]的争议，成功减少25%内存。这提醒开发者，语言特性可能隐藏内存开销，需深入理解底层布局。
Q&A
Cloudflare的Pingora后端路由器为什么内存占用过高？
因为需要支持多种功能组合，每种组合都需要一个独立的一致性哈希环，导致哈希环数量呈指数级增长，从而消耗大量内存。
Cloudflare如何通过数学推导减少哈希数量？
他们推导出哈希数量与误差的数学关系，发现将每服务器哈希数减少90%不会显著增加误差，因此将默认的160个哈希大幅降低。
在Rust中如何压缩哈希索引以节省内存？
将索引从32位改为16位，并使用字节数组存储哈希和索引，通过getter访问，避免对齐填充，节省25%内存。
迁移到新哈希环时如何避免缓存失效冲击源站？
采用双环并行运行，按数据中心分批切换，控制流量比例和迁移范围，确保稳定并保留回滚能力。
这次优化最终节省了多少内存？
全球范围内回收了超过100TB的内存。
pingora-ketama库的v2版本有哪些改进？
v2版本具有紧凑的存储格式、更快的排序方法，并能调整每个节点的基础哈希数，同时支持与v1并行运行。
