高并发和容错是分布式系统绕不开的两件事，工程上对应三个经典机制：分片解决单机装不下，副本解决单机挂不起，选举解决谁说了算。三者经常被混在一起讲，但适用边界和坑完全不同。
分片：先想清楚分片键
按规则把数据拆到不同节点，突破单机存储与计算瓶颈。某电商平台按用户 ID 哈希，3 亿用户拆到 128 个分片，大促期间扛住每秒 12 万次订单请求。这里的关键不是分多少片，是选哪个字段做分片键——键选错，数据倾斜会让最热的分片先倒。
哈希分片分布均匀，但范围查询要扫多个分片；范围分片对范围查询友好，却有热点问题。扩容时的再平衡是第二个坑：大规模数据迁移会拖垮在线业务。一致性哈希或预分片（一开始就建足够多的逻辑桶）能把迁移代价压下来，新业务建议直接预分片。
redis-cli --cluster create 192.168.1.1:7000 192.168.1.2:7001 \
--cluster-replicas 1
副本：一致性换可用性的那杆秤
主从复制，主写从读。某金融支付系统跨地域部署 MySQL 主从，主中心网络中断后，半自动故障转移 43 秒完成切换，支付业务零中断。
复制模式的选择决定丢不丢数据：异步复制性能最好，但主库宕机可能丢最近几笔写入；半同步至少等一个从库确认才返回，RPO 更稳，写入延迟也会上去。金融场景建议半同步起步，只读场景再放宽。
选举：多数派是底线
ZooKeeper 的 ZAB、Raft 系的实现，核心都是预写日志加多数派确认。某物流调度系统用 Raft 做领导者选举，节点故障后 200ms 内选出新主，保障全球货运路线规划的实时性。
几个可以直接记的工程数字：etcd 默认心跳 100ms、选举超时 1 秒，调参先从这两个值理解起。Redis Sentinel 需要 quorum 发起判断，故障转移还必须获得多数派 Sentinel 同意才生效——部署奇数个节点不是玄学，是多数派的要求。
组合：分片加副本是常态
横向扩展和数据冗余通常一起上。某视频平台用 Cassandra 的 NetworkTopologyStrategy，跨机房分片存储加本地副本优先读取，延迟与可用性两头兼顾，可用性做到 99.99%。Kubernetes 的 StatefulSet，本质也是副本模式在容器层的延伸。
上线前先做故障演练
三个机制都要过同一道检验：kill 主节点，秒表记录切换耗时，同时核对两点——切换时长小于业务容忍窗口；如果承诺数据零丢失，确认写入路径上真的有半同步或等价确认。演练不过关的架构，参数调得再漂亮也别上生产。
模式没有新旧，组合才有讲究。选型时先明确自己最不能接受什么：丢数据、停服还是变慢——答案不同，三件套的配法完全不同。
