太惨了

@corningsun 可以，转串行，没问题，就是改动比较大。

@giiiiiithub 忘记说明一个大限制，因为一些不可控的原因，创建 coupon 是有 rate limit 限制的 2 QPS ，40 RPM 。但是提供批量创建机制 每次 100 个。

@edward1987 @mango88 可以，直接不落数据库

@corningsun 服务多实例的，你这是转单实例了。

@oddcc 你这个和我 12 楼的一样的，是可以的。读 100 个，然后把这 100 个删掉，就不会被其他实例读取了。

@haython 这一点和我们业务不一样，我们的 coupon 是一个 coupon code 发给用户就需要能使用的。
现在的方案，不是在生成 coupon 的时候就给用户绑定，不过确实启发了一下，可以在生成的时候就绑定到人。就是较大调整。

@freelancher 你这是一种方案，对用户分区，冲突概率会低一些，但是哪个实例负责哪个分区也是一个问题，需要协商。。。

@mekingname 看我 23 楼。

随机不是目的。
而且随机入库以后，我多个服务实例读出来怎么错开

@Habyss
@mxT52CRuqR6o5

我强调随机是是因为当前的保证不重复分配的方案是乐观锁，随机能避免冲突，提高性能。

如果分配方案不使用乐观锁，可以不需要
但是整体方案需要考虑到正确性以及性能

@mxT52CRuqR6o5 看分配步骤，随机性是为了避免乐观锁冲突，影响分配性能，因为要保证不能重复分配同一个 coupon 。

你的那个方案和我 10 楼回复的一样，能 work ，但是性能应该应该比较差。其实我测试过，性能应该能满足我们系统现在的需求，但是天花板比较低。

@Habyss
1. 第一种考虑过，读取 100 个，然后全部删除掉，和预分配状态本质差不多；就是考虑到这时候挂掉了就浪费一批 coupons 。
2. 存到数据库可以给一个随机编号，但是不知道怎么能读出来是随机的？

@murmur 实时性其实要求也不是特别高，但是还是需要提高分配性能而已。

现在其实有一个最基本的方案：

1. 读 100 个 coupons
2. 随机选择一个

冲突概率还是挺低的，但是每一次都要读数据库，有点浪费

重点其实看怎么能提高随机读取 coupon 的性能以及随机性

@murmur 数量其实不是重点，重点是一个 coupon 只能给一个人发，不能重复发。

@agzou 分布式锁更重了，分布式锁的 timeout 很难解决。用数据库乐观锁简单点，但是大佬还是觉得复杂了，不希望引入 redis 。

@sagaxu 可以具体一点吗。生成的时候随机，其实生成以后已经不随机了。
我们用的 spanner ，不支持 random 函数。。不然每一批可以 random 选择 100 个，冲突概率也不高了。

店小秘？