需求：领取优惠券时，优惠券有限制“总领取张数”，保证优惠券发放准确

[笑為紅顏苦為誰]

目前：redis 存放 用户 该活动 领优惠券的数量，原子++ ，判断 是否超过用户领取的上限。正常流程没有问题，如果 redis 数据丢失，计数器 从 又会从 0 开始，就存在问题 . 原子 ++ 后，将满足 条件的 入库（第一次 是插入，后面是 更新 ）会存在并发问题，使用的 ON DUPLICATE KEY UPDATE 来处理 ，但是这个不能加 where 条件判断是否 满足最大数量要求。

[笑為紅顏苦為誰]

[getdate]

"目前：redis 存放 用户 该活动 领优惠券的数量，原子++ ，判断 是否超过用户领取的上限"

1:在Redis中存入的时候,会写入数据库么?还是一边写入数据库,一边存入Redis?

2:如果Redis数据库丢失,你是怎么做的?难道就直接从0开始++,没有从数据库中进行查询然后存入Redis 后做其他页面操作?

[笑為紅顏苦為誰]

引用 2 楼 getdate 的回复:

"目前：redis 存放 用户 该活动 领优惠券的数量，原子++ ，判断 是否超过用户领取的上限"

1:在Redis中存入的时候,会写入数据库么?还是一边写入数据库,一边存入Redis?

2:如果Redis数据库丢失,你是怎么做的?难道就直接从0开始++,没有从数据库中进行查询然后存入Redis 后做其他页面操作?

1: redis原子+以后，判断+完之后的数据是否超过最大限制，若没有超过则入库，超过返回错误。2: redis 第一次数据为1(这个时候不知道是真的一次过来，还是数据丢失后过来)，查询数据库判断是否存在这个用户的数据的同时，redis等于2的数据过来了(并发)，如果是真实第一次的话，这个时候去更新数据库就有问题，应该先插入才可以更新。假设这个时候1还没有插入。如果是redis数据丢失过来的1这个时候更新没有问题，等于1的那个出插入异常之后，在进行更新。所以目前的场景有这样的一种情况。

[demongaobo]

库存版本号的概念了解一下

[进击丶Saber]

你为什么不反过来呢,先操作数据库再操作redis,你存这个数应该是有用,但是反过来流程也可以吧?