算法演进：从 0 到 1 亿用户

引言：负载改变一切

一个在 100 个用户时运行完美的算法，可能会在 100 万用户时让你的服务器崩溃。随着流量的增长，瓶颈会从 逻辑 转移到 I/O，然后是 网络，最后是 分布式协作。

以下是随着规模扩大，你的算法策略应当如何调整。

阶段 1：MVP 雏形期 (0 - 1 万用户)

目标： 交付速度。

• 算法： 直接使用语言内置的功能。Array.sort(), HashMap, List.filter()。
• 策略： 先不要优化。当 $N$ 是 1,000 时，$O(N)$ 没任何问题。
• 存储： 单个关系型数据库。让数据库通过简单的 B-Tree 索引来处理“搜索”和“排序”。

阶段 2：快速增长期 (1 万 - 100 万用户)

目标： 响应时间 (延迟)。

• 问题： 线性扫描 ($O(N)$) 开始出现在“慢查询日志”中。
• 算法：
  • 缓存： 引入 LRU 缓存 以避免频繁读取数据库。
  • 搜索： 从 LIKE %关键词% 转向 倒排索引 (Elasticsearch)。
  • 优化： 用专门的数据结构（如 前缀树 Trie）来实现搜索建议，替代繁重的循环。

阶段 3：规模化扩张期 (100 万 - 1000 万用户)

目标： 吞吐量与内存效率。

• 问题： 你无法将所有数据存入单台服务器的内存。
• 算法：
  • 概率型： 在查询数据库前，先用 布隆过滤器 (Bloom Filter) 检查用户是否存在。
  • 统计： 使用 HyperLogLog 进行独立访客计数，节省 99% 的内存。
  • 分片： 使用 一致性哈希 (Consistent Hashing) 将用户分布到多个数据库节点。

阶段 4：全球级规模 (1000 万 - 1 亿+ 用户)

目标： 高可用与系统弹性。

• 问题： 机器每天都在挂，网络不可靠。
• 算法：
  • 共识： 使用 Raft 或 Paxos 保持跨数据中心配置的一致性。
  • 流量控制： 实施 令牌桶 限流和 熔断器，防止级联失效。
  • 大数据： 使用 外部排序 和 MapReduce 模式来处理远超单块硬盘容量的数据。

典型业务场景

• ✅ 排行榜： 初期用 SQL ORDER BY。100 万用户时，改用 Redis ZSet (跳表)。1 亿用户时，使用 分片聚合 模式。
• ✅ 推荐系统： 初期用简单的“分类”过滤。规模化后，转向使用 HNSW 的 向量搜索 (ANN)。

小结：一句话记住它

“扩展就是用复杂性换取效率的过程。从简单开始，但脑中要有一张‘对数地图’，以便知道何时该升级你的武器库。”