分布式系统的典型应用场景

为什么需要

单机有连接数与 CPU 上限，且一旦宕机整站不可用。负载均衡通过多实例集群 + 流量分发，让系统能随业务横向加机器。

如何实现

• 四层（LVS / IPVS）：基于 IP+端口做转发，性能极高，常在流量最前端。
• 七层（Nginx / APISIX）：能解析 HTTP，按 URL、Header、Cookie 做路由与灰度。
• 调度算法：轮询、加权轮询、最小连接、一致性哈希（保证同一用户落到同一节点）、源 IP 哈希。
• 健康检查：定期探测后端存活，自动摘除故障节点，实现"无缝"故障转移。

实现：源站把图片/视频/JS/CSS 推送到遍布各地的边缘节点。用户请求时，DNS 解析到最近的边缘节点；命中则直接返回，未命中才回源拉取并缓存。

为什么需要

热点数据（商品详情、用户会话、排行榜）直接打数据库会瞬间击穿。缓存放在内存，读延迟亚毫秒级，但需要的内存远超单机容量。

如何实现（两种主流方案）

为什么需要

单表几千万行后，B+ 树变深、索引维护变慢、写入锁竞争剧烈。分库分表把数据水平拆分到多个库/表，突破单机容量与性能上限。

如何实现

• 分片键（sharding key）是核心：选错会导致"跨分片查询/热点"。常用 user_id、订单 id、tenant_id。
• 路由算法：取模、范围、一致性哈希、基因法（让关联数据落同一分片）。
• 中间件：ShardingSphere、MyCat 拦截 SQL，自动改写路由、聚合跨分片结果。
• 代价：分布式事务变难、跨分片 JOIN/分页复杂、扩容需迁移数据。

以 TiDB、CockroachDB、OceanBase 为代表：计算与存储分离，数据自动按 range 分片（Region），多副本通过 Raft 保证一致性与高可用，对业务暴露标准 SQL。

实现：数据写入经倒排索引构建；索引被拆成多个 shard（分片，可分布多机），每个 shard 有 replica（副本）。查询时协调节点把请求扇出到相关 shard，归并结果。近实时（refresh 间隔内可见）。

实现：以 Ceph、MinIO、阿里云 OSS 为例，文件被切分成多个数据块，按三副本或纠删码（EC）跨机架/跨机房存放，保证任意单点故障不丢数据；大文件上传走分片上传 + 合并。

三个典型用途

Kafka 的关键分布式设计

• Topic → Partition：分区是并行单元，也是顺序保证单元（同分区内有序）。
• Replication + ISR：每个分区多副本，Leader 处理读写，Follower 通过 ISR 同步，Leader 挂了从 ISR 选新 Leader。
• Consumer Group：同组消费者分摊分区，实现水平消费能力扩展。
• 顺序写盘 + 零拷贝：让 Broker 吞吐极高，单机可达百万级 TPS。

// 典型：下单成功后发事件，下游解耦处理
public void createOrder(Order o) {
    orderRepo.save(o);                 // 1. 本地事务落库
    kafkaTemplate.send("order-created", o.id); // 2. 发事件
}
// 库存/积分/风控服务各自 @KafkaListener 消费，互不阻塞

问题：实例 IP 随时在变（扩缩容、重启、迁移），硬编码地址不可能。实现：服务启动时把自己注册到注册中心（Nacos / ZooKeeper / Etcd / Consul）；调用方从注册中心拉取可用实例列表，配合负载均衡选一个调用；实例下线时注册中心通知调用方摘除。

为什么：无状态应用多实例部署后，用户第一次请求打到节点 A 登录，第二次请求被负载均衡到节点 B，B 不认识这个 Session。

问题：定时任务在多实例下会"每人都跑一次"，导致重复扣款、重复发券。实现：用 Elastic-Job、XXL-JOB、SchedulerX 等，借助注册中心做分片调度——把任务数据按分片键拆开，每台机器只跑自己分片的那部分；或通过选举/分布式锁保证同一时刻只有一个实例执行。

// XXL-JOB 分片示例：3 个实例分别处理 user_id % 3 == 0/1/2 的用户
int shardIndex = shardingUtil().getIndex();
int shardTotal = shardingUtil().getTotal();
List<User> users = userDao.findByMod(shardTotal, shardIndex);

场景：秒杀扣库存、幂等防重、定时任务防并发。单机 synchronized 在多机无效。

// SET key value NX PX 30000 原子加锁，带过期防死锁
boolean ok = redis.set("lock:order:1001", uuid,
                    "NX", "PX", 30000);
if (ok) {
   try { /* 临界区 */ } finally { /* 用 Lua 校验 uuid 后释放 */ }
}

MapReduce 思想：把"大任务"拆成 map（各算各的分片）+ shuffle（按 key 聚合）+ reduce（汇总）。Spark 在此基础上用内存 RDD + DAG 省掉反复落盘，速度快数十倍。

实现：把无限数据流切成小批次/逐条处理，算子并行度可任意调节；通过checkpoint（分布式快照）记录状态，故障后从最近快照恢复，实现精确一次（exactly-once）语义。

实现：把流量按单元（Cell）切分，每个单元自包含（接入+应用+数据），用户被路由到固定单元；单元间通过数据同步（如 MySQL 主从、DRC）保持最终一致。灾难时把流量整体切到健康单元。典型如支付宝"三地五中心"。