@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 个，冲突概率也不高了。

店小秘？

union 不支持 struct ，只支持基本类型

看你想解决什么问题
1. 防止中间人攻击，数据安全：直接 https
2. 反抓包：客户端加密可行

SSO 其实很简单，我来尝试解释下，不讲具体协议，就讲一下大致原理和认证过程

先定义下参与方，前后端都接入了 CAS 认证过程：

AppA：*.appa.com
AppB：*.appb.com
CAS：*.cas.com 单点登录用户中心



一个用户进入 AppA ，发现没有登陆，跳转到 CAS 登陆，CAS 登陆以后，在 CAS 域名下保存 cookie ，然后将 cookie 放在 URL 上重定向到 AppA ，AppA 识别到 cookie ，将 cookie 保存到 AppA 域名下，下次就不需要跳转了，直接就是登陆过了。

同一个用户进入 AppB ，发现没有登陆，跳转到 CAS ，CAS 已经有 cookie 了，直接带着 cookie 重定向到 AppB 就可以了。

有好感可以继续，异地这个问题提前解决，先达成一致再进下一步。

一直准备着，有更好的机会就走呗

绩效这东西，就算有明确的规章制度，但是大部分还是由上级决定的
如果和上级合不来，早点走

两个都有锅，我觉得 55 开吧

不过，领导这么说话的公司呆着干嘛

然后，要看几次线上事故的原因是不是类似，反复犯同样的错，自己也需要反思下。