分布式系统实战指南：从分布式锁到事务与微服务架构

团队越大，管理越难，写代码也一样。你有没有遇到过这种情况：多个服务节点同时处理同一笔订单，有人多扣了库存，有人重复发了优惠券，日志里各种“并发冲突”刷屏，事后排查半天发现是某个节点把别的节点的数据覆盖了。这时候你大概率会意识到，单机时代那套“一个进程管所有事”的玩法，放到分布式架构下根本行不通。

我最近在复盘一个微服务集群的改造项目时，脑子里突然冒出个比喻：微服务集群其实就像一个正在搞团建的团队。每个服务是一个成员，大家分散在不同机房、不同容器、不同进程里，但又要协同完成同一个目标。“分布式团建”要搞成，得先解决几个非常现实的问题：谁负责什么、谁能碰哪块资源、任务怎么派、干砸了怎么追责、消息怎么同步。有意思的是，这些问题映射到技术上，正好对应着分布式ID、分布式锁、分布式事务、任务调度、分布式缓存、监控追踪这一整套东西。这篇文章就把这场“分布式团建”从筹备到收尾的完整过程拆开讲，覆盖了我在实际项目中验证过的方案和踩过的坑。适合正在做分布式开发、微服务改造，或者准备面试分布式相关岗位的同学参考。

1. 团建前的“名册革命”：先给每个成员一个唯一编号

1.1 分布式环境下的ID问题：为什么数据库自增ID会翻车

搞团建的第一件事是什么？点名。你得先确认团队里有多少人，每个人叫什么，谁是谁。在单体应用里这事很简单，数据库主键设置一个自增ID就完事了，反正只有一个库，ID从1、2、3往下排，不会有冲突。

但到了分布式场景，情况就变了。你的服务可能有多个实例，每个实例都能往数据库里写数据，如果各写各的，用自增ID，那服务A生成了ID=100，服务B也生成了ID=100，两边数据一合并，直接撞车。更麻烦的是，像订单号、交易流水号这种ID，还承载了业务含义，需要全局唯一、尽量短、还要有一定的可读性，你不能拿个UUID往那一甩就完事。

UUID作为分布式ID的备选方案，网上很多人说它不行，其实得分场景。UUID乱是乱了点，但它生成简单、无需协调、本地就能搞定，在不需要排序、不需要展示给用户的内部表里，用UUID是完全没问题的。但你要是拿UUID当订单号，用户看到一长串乱七八糟的字符，体验就很糟糕；而且UUID是无序的，如果用它做主键，在InnoDB这种B+树索引下，页分裂会非常频繁，写入性能会明显下降。

我当时做订单系统改造的时候，第一版就用的UUID，上线后数据库写入在高峰期出现了明显的性能波动，后来排查才发现，主键的随机性导致索引频繁重建。这个教训让我后来在选型ID方案时，第一优先级永远是“有序性”。

1.2 几种主流分布式ID方案的实战对比和选型建议

目前业界主流的分布式ID方案，我梳理了一下，大概有这么几类：基于数据库号段模式、基于Redis的INCR命令、基于ZooKeeper/etcd的序列化分配、基于雪花算法及其变种。

数据库号段模式，就是每次从数据库取一批ID放到本地内存里用，用完再去取。比如每次取100个号，本地分配完后，数据库的起始值加100。这个方案实现简单，性能也不错，但有一个问题：每个节点拿到的号段是固定的，如果节点扩容，旧号段还没用完，新节点又拉了新号段，可能存在一段时间的ID空洞，不过这不影响全局唯一性。

Redis的INCR方案，本质上是利用Redis单线程执行命令的特性，保证计数器的原子性，每次执行INCR都能拿到一个绝对递增的数值。但这个方案有个隐患，Redis宕机会丢数据，如果没做持久化，ID就可能重复。而且Redis本身也是要被高可用的，绕了一圈，你还是要处理分布式的一致性问题。

最被广泛接受的方案还是雪花算法。雪花算法生成的ID是一个64位的长整型，1位符号位、41位时间戳、10位机器标识、12位序列号。同一毫秒内，同一台机器上最多能生成4096个ID，完全够用。它的好处是纯本地生成、不依赖外部存储、趋势递增，非常适合作为分布式数据库主键和订单号。

雪花算法我用了很多年，踩过最典型的坑是服务器时间回拨。运维手动校时或者NTP同步导致机器时间往后退，生成的ID就可能出现重复。我们后来在封装的时候加了时钟回拨检测，回拨时间小于5毫秒的时候直接自旋等待，回拨幅度大的时候就报错并切到备用策略。这块代码看起来简单，但测试一定要到位，不然生产环境一出问题就是大事故。

选型建议很简单：中小型项目优先用数据库号段或者直接让框架帮你接一个雪花算法的封装；如果你已经在用Spring Cloud全家桶，Nacos本身没有ID生成能力，那就自己实现一个雪花算法的Starter，比接入额外的中间件要轻得多。订单号这种要给人看的，可以在雪花ID基础上加个业务前缀，比如订单号用O+日期+雪花ID，可读性和唯一性兼顾。

2. 团建的“领导力”问题：没有中心也能步调一致

2.1 选主与共识：Raft算法的通俗理解

团队搞团建，总得有个人拿主意：几点集合、走哪条路线、在哪吃饭。分布式系统也一样，多个节点在一起协同，经常需要选出一个“领导”来协调大家。这就是选主问题。

选主听着简单，但真正难的是“共识”：所有节点必须就谁当领导达成完全一致，不能有两个节点同时认为自己才是领导。这就涉及到Raft算法。

Raft算法的核心思想可以概括成三句话：先投票，票多者当选；领导负责接收所有写请求，然后复制给其他节点；多数节点确认后，这个操作才算成功。你看，这跟团建选队长一模一样，大家投票选出来一个队长，队长做决策，但决策要大家多数人点头才生效。

我在生产环境用etcd做选主的时候，最直观的感受是，Raft算法对网络抖动非常敏感。哪个节点网络慢半拍，它的投票请求就可能超时，导致选举反复触发，整个集群的可用性会在那一瞬间下降。后来我们给etcd集群加了独立的内网带宽保障，并且把心跳间隔和选举超时时间调得更加合理，情况才稳定下来。

2.2 时钟同步：分布式环境最容易被低估的麻烦

团队里每个人都戴表，但表走得不一样齐，团建集合就容易出问题：你认为是8点集合，别人认为是8点零3分。分布式系统里的时钟问题，看起来轻飘飘，实际上坑得很。

比如你记录日志，请求先打到了A节点，之后被转发到B节点处理，最后汇总日志的时候，发现B节点的日志时间比A节点早了十秒。你以为处理流程有严重bug，实