如何设计电商系统中的幂等机制？从积分发放聊起你就懂了

在电商平台积分发放场景中，我们经常会遇到这样的问题：用户点击”领取积分”按钮后由于网络延迟重复提交请求，导致积分被错误地多次发放。这种看似简单的业务场景背后，正是幂等性设计需要解决的核心问题。

在分布式架构下，网络抖动、服务重试、用户重复操作等问题都会导致请求重复提交。以积分发放为例：

用户重复点击领取按钮导致多次请求
服务端超时重试机制造成重复处理
消息队列重复消费引发的数据异常

据阿里云技术团队统计，未做幂等设计的系统在促销期间会产生0.5%到3%的异常数据，直接影响用户信任和平台收益。

业务流水号+请求唯一ID的组合方案：

// 生成全局唯一ID示例
String requestId = UUID.randomUUID().toString() + "_" + System.currentTimeMillis();

配合数据库唯一索引实现防重：

MySQL建立UNIQUE索引: ALTER TABLE points_log ADD UNIQUE (request_id);
Redis SETNX原子操作保证并发安全

设计积分发放的状态流转模型：

状态	描述	允许操作
INIT	初始化	PROCESSING
PROCESSING	处理中	SUCCESS/FAILED
SUCCESS	发放成功	不可变更

通过定时任务+对账系统实现最终一致性：

每小时扫描异常状态订单
与账户系统进行余额对账
自动触发积分修正流程

某电商平台通过以下方案实现零差错积分发放：

按钮点击后禁用300ms
请求间隔小于500ms的视为重复操作
错误提示模板：”您的请求正在处理中，请勿重复点击”

public boolean grantPoints(String userId, String requestId) {
    // 检查请求ID是否存在
    if(checkDuplicate(requestId)) return false;
    
    // 开启分布式锁
    Lock lock = redisson.getLock("POINT_LOCK:"+userId);
    try {
        lock.lock();
        // 执行积分发放逻辑
        return processGrantPoints(userId);
    } finally {
        lock.unlock();
    }
}

使用RocketMQ的事务消息机制：