讨论下 卡密下发 保证不重发 除了不用 redis 还有啥方案

[lipaa]

业务背景:公司采购了一批爱奇艺会员卡密,导入到了 mysql 现在的做法是有用户购买就获取最后一张未使用的, 更新时判断状态(可能已被使用 会失败),如果失败就自旋重试 redis 的方案已经启弃用了 感觉难以保证一致性... 各大 v 友还有啥方案 麻了

[lu5je0]

update tb set order=xxx limit 1

[lipaa]

@philchang1995 我们一开始就这么做的

[whcoding]

@philchang1995 怕 redis 里的数据丢失?

[ETiV]

做成队列，改发放机制成申请制，申请后提示用户“稍后将卡片以短信、邮件发送”

然后慢慢消费队列就好了

话说你们不怕灰产、羊毛党吗？

[philchang1995]

@whcoding 对啊😂

[philchang1995]

@lipaa 25 楼那种方案么？

[whcoding]

@philchang1995 reids 挂掉? 丢数据 可能性不大吧 再说了还有持久化呢 不怕.....

[git00ll]

for update 。简单 暴力。性能也不差

[zhoujinjing09]

就正常分布式自增 ID 的解法，每个 ID 对应一个卡密不就行了吗……可能会有跳过但是无所谓吧，你们每天定时任务重新归档一下？

[ryd994]

比起纠结这个，你更需要销售的日志。对库存表的每一个操作都应当有审计记录。这样就算碰到发错货或者无赖买家也有据可查。

[v2orz]

单线程 消费队列下发

[Hug125]

@ETiV #44 我司核心业务也是用消息队列异步处理保证数据准确性，就是需要注意消费者多实例部署时加分布式锁，避免两个实例同时消费同一条消息。OP 的业务场景做到准实时也够用了。

[NeezerGu]

非技术人员好奇问问。
能不能简单粗暴的吧所有卡密分成 10 分，放在 10 个 redis 分库里，对应 10 个取卡密进程（取卡时加锁排队）。
取卡的时候做个负载均衡，保证高并发场景能扛得住就行
印象里 redis 消耗资源不大，一台机开 n 个也行？当然如果内存不够 redis 可以换成 pika ？

[rekulas]

@NeezerGu 单机的话 redis 主要瓶颈在内存，多开不能提高什么性能(我怀疑还会降低)
如果是多机，那不如直接 redis 集群了，还不用考虑分配系统逻辑更简单