系统架构 · 数据分布与扩缩容

场景 1 · 订单表 4 亿行水平拆分, 买家卖家两边都要等值查

按 buyer_id 切 16 库后买家查询直达, 卖家查订单却要广播 16 库。解法: 冗余一份按 seller_id 切的 seller_orders 异构表, 双维度各查各的。ShardingSphere MOD 算法配置:

# ShardingSphere 5.x rules.yaml — 订单库水平拆分
rules:
  - !SHARDING
    tables:
      orders:
        actualDataNodes: ds_${0..15}.orders_${0..15}
        databaseStrategy:
          standard:
            shardingColumn: buyer_id            # 买家维度等值直达单库
            shardingAlgorithmName: orders_mod
    shardingAlgorithms:
      orders_mod:
        type: MOD
        props:
          sharding-count: 16
      # 卖家维度不广播的解法: 另存 seller_orders 按 seller_id 再切一份,
      # 下单事务里双写, 用本地消息表保证最终一致

上线后买家/卖家查询都是单分片直达, 广播查询占比从 37% 降到 2%。

场景 2 · Redis Cluster 6 主扩到 8 主, 高峰期不停服迁 slot

手工 CLUSTER ADDSLOTS 容易漏段; 用 redis-cli --cluster reshard 非交互迁移, 控制批量与超时, 全程服务可用:

# 1) 新节点入簇
redis-cli -c -h 10.0.0.8 -p 6379 CLUSTER MEET 10.0.0.1 6379
# 2) 非交互 reshard: 从现有主各抽 4096 个 slot 给新主
redis-cli --cluster reshard 10.0.0.1:6379 \
  --cluster-from all --cluster-to <新主节点ID> \
  --cluster-slots 4096 --cluster-yes
# 3) 迁完体检: 16384 个 slot 必须全覆盖, 无 migrating 卡住的段
redis-cli --cluster check 10.0.0.1:6379
# 迁移中命中迁走的 key 会收到 ASK/MOVED 重定向 —
# 智能客户端(JedisCluster/Lettuce)自动跟, 裸客户端当异常抛

场景 3 · Kafka 订单消息乱序消费, 状态机反复横跳

Producer 没带 key, 轮询发到各分区, 同一订单的"创建→支付→发货"乱序到达。模板: key 哈希分区保住分区内有序, 分区数一次规划到位:

// 同一 key 恒定落同一分区 — 分区内严格有序
ProducerRecord<String, String> rec =
    new ProducerRecord<>("order-events", orderNo, payload);
producer.send(rec, (meta, ex) -> {
    if (ex != null) log.error("send fail {}", orderNo, ex); // 别静默丢
});
// 默认 partitioner: murmur2(key) % 分区数, 同 key 同分区
// 分区数规划: 目标 300MB/s ÷ 单分区 30MB/s = 10 → 留 2 倍余量定 24
// 关键: 分区只能加不能减 — 加分区同一 key 可能换分区, 上线前算够

场景 4 · 监控大盘 8 亿行按月 range 分区, 归档秒删新数据不堵

时序指标按月 range 分区: 查询走分区裁剪, 月底归档 DROP PARTITION 秒级完成, 不产生大事务 undo。关键是预建分区防"无分区可落":

-- 预建下月分区 (别等新月份第一笔写入报 ERROR 1526 才想起来)
ALTER TABLE metrics ADD PARTITION (
  PARTITION p202610 VALUES LESS THAN (UNIX_TIMESTAMP('2026-11-01')));
-- 归档: 秒级删整月, 不锁业务表
ALTER TABLE metrics DROP PARTITION p202501;
-- 查询必须带分区键才裁剪, 否则扫全部分区
EXPLAIN SELECT v FROM metrics
  WHERE created_at >= '2026-09-01' AND created_at < '2026-10-01';
-- 关键: RANGE 写永远打最新分区 — 用热点写换"删除免大事务", 划算

场景 5 · SaaS 3000 租户大小悬殊, directory 路由表 + 本地缓存

租户体量差三个数量级, 哈希切不均; directory 路由表最灵活: 大租户单独指大分片, 长尾哈希均摊。风险是路由表自己成单点——本地缓存 + 版本化变更兜住:

func (r *RouteTable) Lookup(tenant string) (int, error) {
    if shard, ok := r.cacheGet(tenant); ok {
        return shard, nil  // 关键: 命中本地缓存, 路由库 QPS 与业务解耦
    }
    var shard int
    err := db.QueryRow(
        "SELECT shard FROM tenant_route WHERE tenant_id=?", tenant).Scan(&shard)
    if err != nil { return 0, err }
    r.cacheSet(tenant, shard)  // 回填 + 订阅变更失效, 别每请求回源
    return shard, nil
}
// 路由表 3 副本 + 每实例 60s 全量快照兜底 — 路由库挂了系统还能跑

场景 6 · 明星官宣恋情, 缓存命中率 99% 还是崩了 (事故排查)

大V user:9527 的 info key 落在 shard-3, 缓存命中也全打 shard-3 单节点——热点在分片不在 DB。复盘排查路径:

# 1) 全站缓存命中率 99.2%, DB 毫无压力, 但用户超时 → 定位 redis shard-3
redis-cli -h 10.0.0.5 -p 6379 --hotkeys | head
# 2) top key: "user:9527:info" 占该节点请求 87% (45w QPS)
# 3) 处置: info 内容本地缓存 100ms (singleflight 防击穿),
#    key 拆成 {0..15} 多副本, 读随机挑一个副本分摊压力
#    localCache.Get("user:9527:info", 100ms, fetchFromAnyReplica)
# 关键: 命中率是全站指标, 热点要按 per-shard / per-node 看

复盘后给所有读接口补了 per-node QPS 粒度监控, max/mean > 3 自动告警。

场景 7 · 副本重分配打满万兆网卡, 消费堆积 2000 万条

扩盘搬副本没限速, replica fetch 吃光带宽, 生产者 ack 超时雪上加霜。标准三步: 生成计划 → 带限速执行 → 验证并清除限速:

# 生成搬迁计划
kafka-reassign-partitions.sh --bootstrap-server b1:9092 \
  --generate --topics-to-move-json-file topics.json --broker-list 1,2,3,4
# 带限速执行: 50MB/s, 留一半带宽给线上流量
kafka-reassign-partitions.sh --bootstrap-server b1:9092 \
  --execute --reassignment-json-file plan.json --throttle 52428800
# 验证 — 同时负责移除 throttle 配额
kafka-reassign-partitions.sh --bootstrap-server b1:9092 \
  --verify --reassignment-json-file plan.json
# 关键: 不跑 --verify, 限速配额永久残留, 以后正常同步也被咬

场景 8 · 分片键选错两年, 历史数据整体迁到新分片体系

老分片键是"手机尾号", 基数只有 100 且集中在几个尾号; 纠错方案: 影子库按新键建好 → 背景回填 → 对账 → 灰度切读, 全程可回滚:

-- 1) 按 id 段回填影子库 (幂等: 已存在的行跳过)
INSERT IGNORE INTO orders_v2
  SELECT * FROM orders_old WHERE id BETWEEN ? AND ?;
-- 2) 分段对账: 行数 + 内容 CRC 双比对
SELECT COUNT(*), SUM(CRC32(CONCAT(id, amount)))
  FROM orders_v2 WHERE id BETWEEN ? AND ?;
-- 3) 灰度切读: 按租户 1% → 10% → 100%, 每步盯路由命中与耗时
-- 关键: 双写期以旧库为准 — 新库只告警不阻断, 任何时刻可退

场景 9 · 订单搜索跨 16 分片聚合, 尾分片 P99 3s 拖死整个接口

scatter/gather 不设预算, 总延迟=最慢分片; 一个大分片慢查询就把全接口打穿。解法: 并发下发 + 单片超时 + 超时返回部分结果:

ctx, cancel := context.WithTimeout(ctx, 800*time.Millisecond)
defer cancel()
results := make(chan []Order, 16)
for _, shard := range shards {
    go func(s *Shard) {
        sc, scCancel := context.WithTimeout(ctx, 500*time.Millisecond)
        defer scCancel()  // 关键: 单片预算 500ms, 慢分片不拖整体
        res, err := s.Query(sc, cond)
        if err != nil { metrics.ShardFail(s.Name); results <- nil; return }
        results <- res
    }(shard)
}
// 汇总只等 ctx 截止 — 超时返回"已到货的部分结果 + partial 标记"

场景 10 · 计算引擎跨机房拉数据, 每月多付 40 万流量费

消费者与 Kafka 副本不在同机房, 每条消息都走一遍机房间骨干。locality 亲和: consumer.rack 对上 broker.rack, 计算贴着数据跑:

# consumer.properties: 只从本机架副本拉流, 跨机房流量归零
client.rack=rack-1
# broker 侧: broker.rack=rack-1 标记机架; 2.4+ 可配 replica.selector.class
# 启用机架感知副本选择, client.rack 与 broker.rack 对上才生效
# Spark 侧: 宁可 1s 调度等待也别跨机架拉数据; 实在没本地就快失败
spark.locality.wait=1s
spark.locality.wait.process=500ms
# 关键: 亲和不是玄学 — 每条消息少走一次机房骨干, 账单肉眼可见降