算法不是面试题（一）：算法是业务武器，不是屠龙之术

现象：
  - 扩容前：4 台缓存服务器，命中率 95%
  - 扩容后：8 台缓存服务器，命中率 40%

结果：
  - 数据库直接被打爆
  - 大促第一个小时，损失数千万

原来的路由：hash(key) % 4
扩容后的路由：hash(key) % 8

key = "user:12345"
  扩容前：hash % 4 = 1 → 服务器 1
  扩容后：hash % 8 = 5 → 服务器 5

同一个 key，被路由到不同的服务器
服务器 5 没有这个 key 的缓存 → 穿透到数据库

// 你以为你在用 HashMap
let cache: HashMap<String, User> = HashMap::new();

// 实际上你在用：
// - 哈希函数（把 key 映射到桶）
// - 开放寻址或链表（处理冲突）
// - 动态扩容（rehash）

// 你以为你在用 BTreeMap
let sorted_users: BTreeMap<i64, User> = BTreeMap::new();

// 实际上你在用：
// - B 树（自平衡多路搜索树）
// - O(log n) 的查找、插入、删除
// - 有序遍历

场景：实现一个 LRU 缓存

需要的操作：
  - get(key)：O(1) 获取
  - put(key, value)：O(1) 插入
  - 淘汰最久未使用的：O(1) 删除

单一数据结构做不到，需要组合：
  - HashMap：O(1) 查找
  - 双向链表：O(1) 调整顺序、删除

HashMap + 双向链表 = LRU Cache

use std::collections::HashMap;

struct LRUCache<K, V> {
    map: HashMap<K, *mut Node<K, V>>,
    head: *mut Node<K, V>,  // 最近使用
    tail: *mut Node<K, V>,  // 最久未使用
    capacity: usize,
}

场景：敏感词过滤

朴素方案：
  for word in sensitive_words:
      if word in content:
          replace(word, "***")

  10000 个敏感词 × 10000 字文章 = 1 亿次比较

优化方案：AC 自动机
  - 把所有敏感词构建成一个状态机
  - 一次扫描文章，O(n) 完成所有匹配
  - 10000 个敏感词也是 O(n)

1. 数据规模
   - 100 条数据：O(n²) 也无所谓
   - 1 亿条数据：O(n log n) 和 O(n) 差约 27 倍（log₂(10⁸) ≈ 26.5）

2. 访问模式
   - 读多写少：可以牺牲写性能换读性能
   - 写多读少：反过来

3. 一致性要求
   - 金融场景：宁可慢，不能错
   - 推荐场景：快比准重要

4. 运维成本
   - 自己实现红黑树 vs 用 BTreeMap
   - 99% 的情况选后者

每篇文章的结构：

1. 业务场景
   - 你会遇到什么问题
   - 朴素解法为什么不行

2. 算法原理
   - 核心思想（用类比解释）
   - 关键操作的复杂度

3. 代码实现
   - Rust 代码（关注可读性）
   - 关键步骤注释

4. 工程考量
   - 什么时候用
   - 什么时候不用
   - 有什么坑

错误的学习路径：
  学红黑树 → 发现很难 → 放弃 → 觉得算法没用

正确的学习路径：
  遇到有序 Map 性能问题 → 了解 B 树/红黑树 → 理解为什么需要自平衡 → 选择合适的实现

场景：排序 100 个元素

冒泡排序：O(n²) = 10000 次比较
快速排序：O(n log n) ≈ 700 次比较

差 14 倍，但都是微秒级
花 2 小时优化，省 0.01 毫秒，不值得

想学 LRU？看 Rust 的 lru crate
想学跳表？看 Redis 的 zset 实现
想学限流？看 Sentinel 的滑动窗口

比任何教程都实用