如何在发放优惠码时保证同一个码不会被重复发出多次？

[kran]

表结构如下：

`id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '编号',
`coupon` varchar(255) COLLATE utf8_unicode_ci NOT NULL COMMENT '优惠券码',
`type` tinyint(1) unsigned NOT NULL COMMENT '类型',
`is_use` enum('N','Y') COLLATE utf8_unicode_ci NOT NULL DEFAULT 'N' COMMENT '是否使用',
`use_date` int(10) unsigned NOT NULL COMMENT '使用时间',
`is_del` enum('N','Y') COLLATE utf8_unicode_ci NOT NULL DEFAULT 'N' COMMENT '是否删除',
`creation_date` int(10) unsigned NOT NULL COMMENT '创建时间',
PRIMARY KEY (`id`),
KEY `type` (`type`,`is_use`,`is_del`)


现在使用这样的查询，会锁表：

begin;
select * from coupon_list where is_use='N' and type=5 and is_del='N' limit 1 for update;

如何才能触发行锁而不是表锁？

[kran]

@laoyur
也就是同步的方法吗？ 如果是这样的话，直接表锁也和它差不多了吧？

[kran]

@happywowwow 文章里说的是，使用相同索引那么就会对索引加锁，跟锁表差不多。

@zhicheng 对哦！进程数是有个大概范围的。我真是笨死了 T_T
看来这个场景下之需要所表就ok的。
能问一下100k以上需要那些处理吗？

[kran]

@zhicheng 啊。按终端分就是处理方法吗？

[zhicheng]

一个数据库肯定顶不住，在创建优惠码之后可以分布到多个数据库里，同时读写，等一批码发完最后同步一下。这种方式可以任凭你分布到多少服务器上都不会互相影响。

[kran]

@zhicheng 非常好！感谢ing！

[zhicheng]

恭喜你掌握了每秒顶住10亿红包系统的秘密。。。

[kran]

@zhicheng 别吓唬我，我最怕知道秘密了～哈哈

[ayv]

把优惠码放到一个持久化的队列 例如redis的list

[happywowwow]

”InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！“

[lujjjh]

如果一定要用 MySQL，为什么要设计成记录“优惠码是否使用”而不是记录“优惠码拥有者”呢？
先 SELECT 再 UPDATE 原子性难以得到保证的话，最简单的方案就是先 UPDATE 再 SELECT 嘛。

[julyclyde]

@abelyao 临时生成会比较慢，再加上判断重复、判断重复、判断重复、判断重复的耗时就可能超时了
@c742435

[abelyao]

@julyclyde 可没说临时生成就必须做重复判断哦，可以把 unique id 视作优惠码多一部分，算法有很多种，就看你怎么设计了。当然楼主说优惠码是已经有客户那边生成了，就不再讨论这个方案了。

[lujiajing1126]

@lujjjh select的时候加悲观锁
或者用version_code做乐观锁

[lujiajing1126]

话说为啥不试试redis的list。。。
很多抢票都是这么干的

[donglingyongadls]

借鉴bloom filter？没试过，仅供参考

[ly827]

貌似是新浪游戏的面试题啊~~可以尝试事务处理+for update~保证唯一 看情况决定用不用存储过程

[li24361]

@zhicheng 腾讯就是利用狂加数据库来顶住的压力,我觉得不只是堆数据库这么简单吧