使用唯一消息ID和业务状态校验实现幂等性，通过Redis去重、数据库乐观锁与状态机控制，确保事件重复消费时系统状态一致。
在微服务的事件驱动架构中，实现幂等性是确保系统稳定和数据一致的关键。由于消息可能被重复发送或消费（例如网络重试、消费者重启等），同一个事件被多次处理时，业务结果必须保持一致——这就是幂等性的核心要求。
使用唯一消息ID进行去重
每条事件消息在发布时都应携带一个全局唯一的标识（如UUID或基于业务键生成的ID）。消费者接收到消息后，先检查该ID是否已处理过，避免重复执行。
- 将已处理的消息ID存储在持久化存储中，如Redis、数据库表或分布式缓存
- 利用Redis的SETNX或SET key value NX命令实现原子性判断
- 设置合理的过期策略，防止存储无限增长（如TTL与业务生命周期匹配）
基于业务状态的条件更新
幂等性也可通过业务逻辑层面控制，确保相同操作对系统状态的影响是累积安全的。
- 在执行更新前查询当前状态，判断是否已达到目标状态，避免重复变更
- 使用数据库的乐观锁机制（如版本号字段）防止并发或重复修改
- 例如：订单从“待支付”变为“已支付”，再次收到“支付成功”事件时，先检查状态，若已是“已支付”则跳过处理
事件溯源与状态机校验
在采用事件溯源模式的系统中，每个实体的状态由事件流重构而来，天然具备一定的幂等基础。
- 在聚合根中记录已处理的事件序列号或ID，拒绝重复应用
- 结合状态机模型，明确允许的状态转移路径，非法转移直接丢弃
- 这种模式下，即使事件重放多次，最终状态仍保持一致
基本上就这些。关键在于识别重复事件并控制其影响，无论通过技术手段去重，还是业务逻辑防御，目标都是让“多次执行如同一次”。设计时要结合消息中间件特性（如Kafka的at-least-once语义）提前规划幂等策略，而不是事后补救。
