本文面向处理高并发、低延迟交易系统的工程师与架构师，深入探讨撮合引擎输入流的防抖（Debouncing）与去重（Deduplication）设计。我们将从网络协议的“不可靠”特性出发，剖析重复请求的根源，并基于计算机科学基本原理，设计一套从网关到核心业务逻辑，覆盖内存、分布式缓存与持久化存储的多层防御体系，确保在客户端、网络、服务端的各种抖动与重试场景下，核心账本的最终一致性与正确性。
现象与问题背景
在一个典型的金融交易系统（如股票、期货、数字货币交易所）中，撮合引擎是心脏。其核心职责是接收买卖订单（Order），并根据价格优先、时间优先的原则进行匹配成交。一笔订单的错误执行，无论是重复撮-合还是丢失，都可能导致严重的资损和信任危机。问题的复杂性在于，重复的请求可能源于系统的任何一个环节。
想象一个场景：一个交易员通过客户端软件下一个市价买单，购买 100 个单位的某资产。由于网络瞬时拥塞，客户端在设定的超时时间内未收到服务端的确认响应。此时，会发生什么？
- 用户行为： 交易员可能会手动再次点击“下单”按钮，产生一个业务层面的重复请求。
- 客户端程序： 客户端的SDK或框架为了保证可靠性，可能会自动发起重试。
- 网络中间件： 请求经过的负载均衡器（如 Nginx），如果配置了 `proxy_next_upstream` 策略，在后端服务响应慢或超时的情况下，也可能将同个请求转发到另一个服务实例，造成重复。
- TCP协议栈： 这是最隐蔽也最根本的来源。即便业务层没有做任何重试，TCP协议本身为了保证可靠传输，存在超时重传机制。一个请求可能早已被服务端成功处理，但服务端回传的ACK包在网络中丢失，客户端的TCP栈会误以为请求未送达，从而发起重传。
这些重复的请求，如果未经处理直接进入撮合引擎，后果不堪设想。原计划购买 100 单位的订单，可能会被执行两次，导致账户以非预期的头寸暴露在市场风险中。因此，设计一个健壮、高效的防抖与去重系统，是撮合引擎乃至所有关键交易系统的入口第一道，也是最重要的一道防线。我们的目标是实现接口的幂等性（Idempotency），即对于同一个操作的多次请求，其产生的效果与一次请求完全相同。
关键原理拆解
在设计解决方案之前，我们必须回归到底层原理，理解为什么“重复”在分布式系统中是常态，以及我们能依赖哪些理论基础来构建防御。这里，我将以一位大学教授的视角来阐述。
1. TCP/IP协议栈的“at-least-once”语义
我们常说TCP是可靠的连接，但这“可靠”指的是数据流的完整性和顺序性，而非应用层操作的“exactly-once”。TCP通过序列号（Sequence Number）、确认号（Acknowledge Number）和超时重传（Retransmission Timeout）机制，保证了数据包能至少一次（at-least-once）地从发送方到达接收方。问题的关键点在于“确认”的边界。当服务端应用层处理完一个请求（例如，数据库事务已提交），并将响应写入其TCP发送缓冲区时，操作在业务上已经完成。但如果这个响应对应的ACK在返回客户端的途中丢失，客户端操作系统内核会认为数据发送失败，触发TCP重传。此时，服务端应用会收到一个内容完全相同的请求。从应用视角看，这就是一个“重复请求”，但从TCP协议视角看，这只是正常的协议行为。
2. 分布式系统中的时钟与状态
要识别重复，就需要一个唯一标识符。最直观的是时间戳，但分布式系统中的物理时钟是不可靠的（时钟漂移）。我们不能依赖多个服务器上的 `System.currentTimeMillis()` 结果来判断事件的先后或同一性。因此，我们需要一个逻辑上唯一的、由调用方生成的标识符，通常称为幂等键（Idempotency Key）或 `client_order_id`。这个ID必须由客户端在“第一次”发起请求时生成，并在后续所有重试中保持不变。服务端的任务，就是记录并识别这些ID。
3. 状态机与原子操作
去重系统的核心是一个状态机。对于每一个幂等键，其状态至少应该有三种：[不存在]、[处理中]、[已完成]。当一个请求携带幂等键首次到达时，系统需要原子地完成“检查是否存在”和“标记为处理中”这两个步骤。这在计算机科学中是一个典型的“Test-And-Set”问题。如果采用非原子操作，例如先 `SELECT` 查询是否存在，再 `INSERT` 标记为处理中，那么在两个高并发的重复请求之间，可能会同时通过 `SELECT` 检查，导致重复处理。因此，我们需要依赖底层设施提供的原子操作，如CPU的CAS指令、数据库的唯一键约束、或Redis的 `SETNX` (SET if Not eXists) 命令。
系统架构总览
一个生产级的撮合系统，其入口流量处理架构通常是分层的。我们的防抖去重机制也应嵌入这个分层架构中，形成纵深防御。
这是一个典型的架构文本描述：
Client -> Edge Load Balancer (LVS/F5) -> Gateway Cluster (Nginx/Spring Cloud Gateway) -> Pre-processing Service Cluster -> Message Queue (Kafka) -> Matching Engine Cluster
我们的去重逻辑主要实现在 Pre-processing Service（预处理服务）层。这一层是无状态的，可以水平扩展，专门负责协议解析、用户鉴权、风控初审以及本文的核心——幂等性校验。
处理流程如下：
- 客户端生成一个唯一的 `client_order_id`（通常是UUID或基于某种高精度时间戳的算法），并随订单请求一起发送。
- Gateway将请求路由到某个Pre-processing Service实例。
- Pre-processing Service实例收到请求后，立即以 `client_order_id` 为key，在一个共享的、高可用的状态存储中检查该ID的状态。
- 场景一（新请求）： 如果ID不存在，服务原子地将该ID状态置为 `PROCESSING`，并设置一个合理的过期时间（例如，订单处理的最大耗时）。然后，它继续执行后续的业务逻辑（如风控检查），最后将订单消息投递到Kafka。
- 场景二（重复请求 – 正在处理）： 如果ID已存在且状态为 `PROCESSING`，说明前一个相同的请求正在被处理（可能由另一个服务实例处理）。此时，服务端应直接向客户端返回一个“处理中”的响应，告知客户端稍后查询订单状态，而不是无谓地等待。这是一种快速失败（Fail-Fast）策略，防止请求在服务内部堆积。
- 场景三（重复请求 – 已完成）： 如果ID已存在且状态为 `COMPLETED`，说明前一个请求已成功处理。此时，服务应从持久化存储（如订单数据库）中查询出原始的处理结果，并将其返回给客户端。这样，客户端的重试也能收到一个确定的成功响应，体验更佳。
- 订单进入Kafka后，由撮合引擎消费并进行匹配。撮合成功后，会有一个状态更新服务，将订单状态持久化，并同步更新共享状态存储中对应 `client_order_id` 的状态为 `COMPLETED`。
这个架构的核心在于那个“共享的、高可用的状态存储”。在工程实践中，它通常是 Redis Cluster 或其他高性能的分布式K-V存储。
核心模块设计与实现
现在，我们切换到极客工程师的视角，深入代码细节，看看如何实现这个预处理服务中的核心去重逻辑。
模块一：幂等键的状态存储与原子操作
别自己造轮子用 `ConcurrentHashMap` 加锁。在分布式环境下，你需要一个外部组件。Redis 是最佳选择之一，它的单线程模型和丰富的原子命令天生适合这个场景。
我们将使用 `SET` 命令配合 `NX` 和 `EX` 选项。`NX` 保证了只有在键不存在时才能设置成功，`EX` 设置了过期时间，防止服务实例处理过程中宕机导致“死锁”。
一个请求过来，我们的第一步是这样：
package idempotency
import (
"context"
"time"
"github.com/go-redis/redis/v8"
)
type RedisStore struct {
client *redis.Client
}
// 状态常量
const (
StateProcessing = "PROCESSING"
StateCompleted = "COMPLETED"
)
// AttemptAcquireLock 尝试获取处理锁，并返回是否是首次请求
// lockTimeout 是为了防止进程崩溃导致死锁，应该大于业务处理的最大时间
func (s *RedisStore) AttemptAcquireLock(ctx context.Context, key string, lockTimeout time.Duration) (bool, error) {
// SET key "PROCESSING" EX timeout NX
// 这个命令是原子的。如果key不存在，设置成功并返回true。
// 如果key已存在，命令执行失败，返回false。
wasSet, err := s.client.SetNX(ctx, key, StateProcessing, lockTimeout).Result()
if err != nil {
return false, err // Redis挂了，需要有告警和熔断
}
return wasSet, nil
}
// GetState 获取一个key的当前状态
func (s *RedisStore) GetState(ctx context.Context, key string) (string, error) {
return s.client.Get(ctx, key).Result()
}
// MarkCompleted 标记处理完成，并可以存储最终结果
// resultTTL 是最终结果的缓存时间，比如24小时
func (s *RedisStore) MarkCompleted(ctx context.Context, key string, result string, resultTTL time.Duration) error {
// 直接SET覆盖PROCESSING状态，并设置更长的过期时间
return s.client.Set(ctx, key, result, resultTTL).Err()
}
上面的Go代码片段展示了与Redis交互的核心逻辑。`AttemptAcquireLock` 函数封装了 `SETNX` 原子操作。业务代码的调用逻辑会是：
func (h *OrderHandler) CreateOrder(req *CreateOrderRequest) (*OrderResponse, error) {
idempotencyKey := req.ClientOrderID
isFirstTime, err := h.idempotencyStore.AttemptAcquireLock(context.Background(), idempotencyKey, 30*time.Second)
if err != nil {
// Redis故障，返回系统错误，触发上游熔断
return nil, ErrSystemBusy
}
if isFirstTime {
// 1. 首次请求，执行核心业务逻辑
order, err := h.orderService.Create(req)
if err != nil {
// 业务处理失败，可以选择删除锁或保留一个FAILED状态
// h.idempotencyStore.DeleteLock(...)
return nil, err
}
// 2. 业务成功，标记为完成状态，并缓存结果
// 这里为了简化，直接将order ID作为结果缓存
h.idempotencyStore.MarkCompleted(context.Background(), idempotencyKey, order.ID, 24*time.Hour)
return &OrderResponse{OrderID: order.ID}, nil
} else {
// 2. 重复请求，检查当前状态
state, err := h.idempotencyStore.GetState(context.Background(), idempotencyKey)
if err != nil {
return nil, ErrSystemBusy
}
if state == StateProcessing {
// 另一个请求正在处理中
return nil, ErrRequestProcessing
}
// 如果状态不是PROCESSING，那它就是我们存入的最终结果（订单ID）
// 这意味着原始请求已成功
return &OrderResponse{OrderID: state}, nil
}
}
这个实现非常直接，解决了核心的原子性问题。`lockTimeout` 和 `resultTTL` 的设置是关键，前者需要略大于业务处理的P99响应时间，后者则根据业务需求（如订单结果查询的时效性）来定，通常是24小时。
性能优化与高可用设计
对于一个每秒处理几十万笔订单的系统，上述基础方案会遇到瓶颈。我们需要考虑性能和可用性。
性能瓶颈与优化：
- Redis单点瓶颈： 所有的去重请求都打到单个Redis实例或主库上，网络IO和CPU会成为瓶颈。解决方案是引入分片（Sharding）。使用Redis Cluster，它会自动根据key的哈希值将数据分布到不同节点。Pre-processing服务需要使用支持Redis Cluster的客户端，这样单点的写入压力就被分散到了整个集群。
- 内存占用： 每天几亿笔订单，即使每笔订单的key和value只有几十个字节，24小时的累积数据量也会非常庞大，对内存成本是巨大考验。这里有一个经典的权衡：是不是所有请求都需要去重？对于查询类、非变更类的请求，可以不做严格的幂等校验。对于写入类请求，如果业务允许，可以将去重窗口从24小时缩短为1小时，极大减少内存占用。但对于金融交易，这个窗口通常不能太短。
- 关于Bloom Filter的陷阱： 有些人可能会想到用布隆过滤器（Bloom Filter）作为前置快速筛查。它能快速判断一个元素“一定不存在”或“可能存在”。但它的问题是假阳性（False Positive），即它可能把一个新请求误判为重复请求。在金融场景，这意味着一笔合法的订单被拒绝，这是绝对不能接受的。所以，不要在需要100%准确性的金融交易去重场景使用标准的布隆过滤器。
高可用设计：
- 去重存储的高可用： Redis Cluster本身提供了主从复制和故障切换（Failover）能力，能保证存储层的高可用。你需要关注集群的健康状态和切换时可能带来的短暂不可用。
- 预处理服务自身的高可用： 由于服务是无状态的，可以部署多个实例，通过负载均衡器分发流量，单个实例宕机不影响整体服务。
- 极端情况——“脑裂”问题： 考虑一个最坏的情况：一个请求在实例A上获取了锁（在Redis中写入了 `PROCESSING` 状态），但实例A在将订单发往Kafka之前就宕机了。这个 `client_order_id` 就会被锁定，直到30秒后过期。在这期间，客户端的重试请求会被其他实例判定为 `PROCESSING` 而拒绝。这造成了业务在30秒内不可用。解决方案是：
- 缩短锁的超时时间，但这会增加业务逻辑必须在超时前完成的压力。
- 建立一个后台对账（Reconciliation）系统。该系统可以定期扫描那些长时间处于 `PROCESSING` 状态的ID，并去下游（如订单数据库）查询其最终状态，然后修复Redis中的状态。这是一个补偿机制，保证最终一致性。
架构演进与落地路径
没有一个架构是“一步到位”的，它需要随着业务量和复杂度演进。
第一阶段：单体应用或小规模服务
在系统初期，流量不大，可以将去重逻辑和业务逻辑放在同一个服务中。状态存储可以直接使用一个高可用的数据库表，利用 `client_order_id` 的唯一键约束（Unique Key）来实现去重。当插入重复ID时，数据库会报错，应用捕获这个异常即可。这种方式简单可靠，但性能较差，数据库会成为瓶颈。
第二阶段：服务化与分布式缓存
随着流量增长，将预处理逻辑拆分为独立服务，并引入Redis Cluster作为幂等性校验的专用存储。这是目前绝大多数互联网和金融科技公司的标准实践。它在性能、成本和可维护性之间取得了很好的平衡。本文详述的方案就属于这个阶段。
第三阶段：追求极致低延迟（HFT场景）
在高频交易（HFT）场景，每一微秒都至关重要。访问外部Redis集群带来的网络延迟（通常在亚毫秒级）可能都无法接受。此时，架构会向着更极致的方向演进：
- 内存计算网格（In-Memory Data Grid）： 使用如Hazelcast, Apache Ignite等组件，它们可以将数据和计算部署在同一个JVM或进程空间内，消除网络开销。去重逻辑和数据分片都在内存中完成。
- 服务内共享内存： 在同一台物理机上部署多个服务进程，通过共享内存（shared memory）来维护去重状态表。这需要复杂的进程间同步机制，但可以达到纳秒级的访问延迟。
这种演进路径清晰地展示了架构是如何被业务需求（特别是性能SLA）驱动的。对于绝大多数系统，第二阶段的架构已经足够健壮和高效。关键在于理解其背后的原理，并在工程实践中处理好各种边界情况和异常。防抖与去重，看似是一个小功能，实则是构建可靠分布式系统的基石。
延伸阅读与相关资源
-
想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
交易系统整体解决方案。 -
如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
产品与服务
中关于交易系统搭建与定制开发的介绍。 -
需要针对现有架构做评估、重构或从零规划，可以通过
联系我们
和架构顾问沟通细节，获取定制化的技术方案建议。