应用Redis分布式锁解决重复通知的问题

研究背景：

这几天被支付宝充值后通知所产生的重复处理问题搞得焦头烂额， 一周连续发生两次重复充钱的杯具， 发事故邮件发到想吐。。为了挽回程序员的尊严， 我用了Redis的锁机制。

事故场景：

支付宝下单 -> 客户支付 -> 回调我方接口通知支付结果

服务器节点： 2个

事故发生原因： 回调我方接口后， 第一次通知还未处理完， 第二次通知又来了（间隔几秒），未对通知进行判定重复，导致两个节点均处理了通知， 给客户加了两次钱。。

解决方案：

1. 基于数据库的原子性操作原理控制数据只能被处理一次。

方法： 由于数据能被处理的条件是 pay_record.status = 'paying'， 即支付状态为待支付中， 才能更新数据为支付成功。

修改前的更新SQL: update pay_record set status = 'succ' where id = #{id};

修改后的更新SQL: update pay_record set status = 'succ' where id = #{id} and status = 'paying';

通过对返回值是否 > 0判断是否有数据被更新成功， 如果有，则执行后续的给钱包加钱操作，否则不处理。

2. 基于Redis的分布式锁setnx方法控制同时只能有一个线程处理加钱逻辑

// 第一次通知，设置缓存
if(jedis.setnx(DONKEY_ALICALLBACK_NOTICE + outTradeNo, outTradeNo) > 0) {
    // 设置生效时长（因为setnx没有生效时间的入参）
    jedis.expire(DONKEY_ALICALLBACK_NOTICE + outTradeNo, 3600 * 3);
    LOGGER.warn("key = {} 新增缓存成功， 进入处理..", DONKEY_ALICALLBACK_NOTICE + outTradeNo);
    // 钱包加钱操作
    addMoney(outTradeNo);
} else {
    // 新增缓存失败， 不处理
    LOGGER.warn("key = {} 新增缓存失败， 不处理", DONKEY_ALICALLBACK_NOTICE + outTradeNo);
    return;
}

setnx: 当key不存在时设置成功，返回1， 否则返回0， 这个操作是线程安全的， 可以查看到它的源代码如下：

public Long setnx(String key, String value) {
    this.checkIsInMultiOrPipeline();
    this.client.setnx(key, value);
    return this.client.getIntegerReply();
}

this.checkIsInMultiOrPipeline()方法源码：

protected void checkIsInMultiOrPipeline() {
    if(this.client.isInMulti()) {
        throw new JedisDataException("Cannot use Jedis when in Multi. Please use Transation or reset jedis state.");
    } else if(this.pipeline != null && this.pipeline.hasPipelinedResponse()) {
        throw new JedisDataException("Cannot use Jedis when in Pipeline. Please use Pipeline or reset jedis state .");
    }
}

总结：

通过jedis.class源码分析可知， redis的大部分的方法均实现了线程安全，都是单线程操作， 故使用redis作为分布式锁效果很好， 也很轻量级。

完毕~~