为什么分布式事务需要限流算法
在微服务架构中，一个分布式事务通常需要跨越订单、库存、支付、物流等多个服务。一旦上游流量突增，大量事务同时开启，每个事务都会占用数据库连接、线程池、网络带宽和锁资源。资源耗尽后，事务开始超时，补偿操作被触发，进而产生雪崩效应。限流算法并不是直接解决分布式事务的一致性难题，而是作为一种保护性模式，在事务开启或关键步骤执行前控制请求速率，为事务协调器争取处理时间，减少因资源竞争导致的失败重试。
核心限流算法与Scala实现思路
理解限流算法是落地实践的前提。常见算法包括固定窗口计数器、滑动窗口日志、漏桶和令牌桶，它们在Scala中都可以用不可变数据结构和原子引用简洁实现。
固定窗口计数器
固定窗口算法将时间划分为固定长度窗口，每个窗口内维护一个计数器。请求到来时计数加一，超过阈值则拒绝。该算法实现简单，但存在临界突刺问题，例如窗口切换瞬间可能放过两倍流量。Scala中可以使用AtomicInteger配合定时重置，适合对精度要求不高的粗粒度限流。
滑动窗口日志
滑动窗口记录每次请求的时间戳，判断当前时间往前推一个窗口长度内的请求总数。它解决了固定窗口的临界问题，但需要存储大量时间戳，内存占用较高。在Scala中可以用ArrayDeque或基于时间轮的不可变队列维护时间戳，并通过定时清理过期数据控制内存。
漏桶与令牌桶
漏桶算法强制请求以固定速率流出，流量过于平滑但无法应对突发；令牌桶则以固定速率生成令牌，请求获取到令牌才被放行，允许一定程度的突发流量。分布式事务场景中经常出现瞬时峰值，因此令牌桶更受欢迎。Scala实现令牌桶时通常需要封装桶容量、当前令牌数、上次填充时间三个字段，并使用AtomicReference或Ref保证并发安全。
分布式事务模式中的限流实践
限流算法必须与具体事务模式结合才能发挥最大价值。下面分别说明Saga和TCC两种常见模式中的限流协同方式。
Saga模式与限流协同
Saga将长事务拆分为多个本地事务，每个本地事务都有对应的补偿操作。在编排型Saga中，事务协调器依次调用各参与服务。可以在协调器执行每一步之前调用限流器尝试获取许可，如果获取失败则快速失败或进入等待队列，避免把压力传导给下游服务。例如订单创建步骤前限流，可防止库存服务被瞬间打垮。
TCC模式与资源预留限流
TCC分为Try、Confirm、Cancel三个阶段。Try阶段会预留资源，如果预留过多而后续Confirm失败，会浪费大量业务资源。在Try阶段入口加入限流，可以控制预留请求的速率，同时配合资源配额管理，使事务失败时补偿压力更可控。通常将限流阈值设置为下游服务容量的百分之七十到八十，为补偿操作保留余地。
逐步实现：Scala令牌桶限流器
接下来给出一个可落地的实现步骤，帮助读者将令牌桶限流器逐步集成到分布式事务协调器中。
- 步骤一：定义状态类型。使用Scala的case class封装桶容量、当前令牌数、上次填充时间三个字段，并通过不可变数据保证线程安全。
- 步骤二：实现填充逻辑。根据当前时间与上次填充时间的差值计算应新增令牌数，令牌数不能超过容量，并更新上次填充时间。
- 步骤三：实现获取逻辑。请求到来时先执行填充，再判断当前令牌数是否大于等于一，满足则扣减一个令牌并返回成功，否则返回失败或等待重试。
- 步骤四：使用原子引用。将状态放入AtomicReference或ZIO Ref中，通过compareAndSet或update操作消除并发修改冲突。
- 步骤五：接入事务协调器。在Saga编排器或TCC Try阶段调用tryAcquire方法，获取失败时记录监控指标并执行快速失败策略。
- 步骤六：分布式化。单机限流无法应对多实例部署，这时可把令牌桶状态放入Redis或etcd等共享存储中，使用Lua脚本或原子命令完成令牌填充与扣减。
注意事项与优化建议
限流阈值不是固定不变的，需要根据下游服务的实际容量、平均事务耗时、补偿成功率动态调整。监控指标至少包括限流拒绝次数、等待时间、令牌桶填充速率和事务失败率。对于跨数据中心的分布式事务，还要考虑时钟漂移对滑动窗口和令牌桶计算的影响。建议在关键路径上优先使用本地限流降低延迟，再通过分布式限流保证全局一致性，二者结合可以同时获得性能与准确性。最后，限流算法只能缓解压力，不能替代超时、重试、幂等和补偿等分布式事务基础机制，它们必须共同协作才能构建一个健壮的系统。
通过将令牌桶限流器逐步嵌入Saga和TCC事务流程，Scala开发者可以在不大幅增加复杂度的情况下，显著提高分布式事务在高并发场景下的成功率与稳定性。从状态封装、原子更新到共享存储，每一步都可以根据实际业务规模灵活裁剪，这正是工程实践中最值得投入的部分。