K8s部署第三方数据转发应用如何水平扩展避免RocketMQ重复消息

核心目标是让每条从第三方数据源推送的全量数据，仅被一个应用副本处理并发送到RocketMQ，具体可根据实际架构选择以下方案：

方案1：K8s流量层做请求分发（改造成本最低） #

如果第三方数据源是通过HTTP、gRPC等单播请求方式推送数据，直接将应用接入K8s Service，配置Service的负载策略为轮询或源IP哈希即可。第三方推送的每条请求只会被Service转发到其中一个Pod处理，从根源上避免多副本同时收到相同数据。

该方案不适用于第三方通过广播、组播，或者当前架构默认所有Pod都能拿到全量推送流量的场景。

方案2：应用层引入分布式去重（适配性最强） #

如果无法调整流量分发规则，必须每个Pod接收全量数据，可在转发RocketMQ前增加去重逻辑：

• 为每条数据生成唯一标识key，可使用数据自带的唯一业务字段拼接，或直接计算整条数据的哈希值作为key
• 引入Redis作为分布式缓存，缓存过期时间设置为大于第三方全量数据推送的最大间隔，避免缓存过期导致漏判
• 每个Pod收到数据后先查询Redis是否存在对应key：
  • 不存在则调用Redis SETNX 命令加分布式锁，加锁成功的Pod负责将数据发送到RocketMQ，写入Redis标记该key已处理
  • 已存在则直接跳过转发逻辑
• 可配合RocketMQ原生去重能力使用：发送消息时将生成的唯一key作为消息的key属性，开启RocketMQ服务端去重配置后，可进一步兜底避免重复消息进入topic。

方案3：StatefulSet分片处理（性能最优） #

如果数据量级大，引入Redis的成本较高，可采用固定分片逻辑拆分处理任务：

• 将Deployment替换为StatefulSet，每个Pod会获得固定的编号标识（如pod-0、pod-1、pod-2）
• 提前约定分片规则：应用启动时读取自身Pod编号，仅处理「数据唯一key哈希值对副本数取模后结果等于自身编号」的数据，其余数据直接丢弃

该方案无需引入额外中间件，性能损耗最低，但扩缩容副本数时需要同步调整分片规则，避免出现分片遗漏或重复。

内容的提问来源于stack exchange，提问作者Wayne Chang