后续的后续：
因为 sn 是可预期的，所以做一个 task ，提前把用户的数据加热到数据表中
此业务环境下，不再对数据进行 SELECT 和 INSERT 操作，只要 UPDATE 就可以了
性能瞬间提升了很多

@concernedz
更新在附言里了

@CEBBCAT 请教下，用 rocketmq 能否完美解决这种问题？
回想安卓中涉及到这种问题，也是使用队列处理的

@CEBBCAT 我是在学习后端，摸鱼时间偷偷学习下

后续：
并发太高时，甚至连缓存都来不及生成
根据 @micean 的方法建立 unique key
在业务中捕获 1062 Duplicate entry 错误
调整业务代码，最终成功

@wowo243 是的，就是这个问题

最终解决办法：
在缓存中先预存 key = sn+member_id 的组合，
同时查询数据库 sn+member_id 记录条数，
如果缓存 key 的值不为空，但记录为 0 ，则返回提示： 您的手速太快了

想到更优雅的，但没时间做的解决办法：
把请求整合到一个队列中，稳定进出，应该也能解决

@turan12 应该不行，因为多个请求并发，可能前一个请求的数据还 没到达服务器 /存储成功 /未更新
应该要从其他地方解决问题

@Feiex 感谢

@Ritter 是的，因为 Mysql 是远程的，把这个问题暴露出来了，以前没注意到。。。

@Jooooooooo 好像确实不是的

@Feiex 没设置事务

@xzh20121116g
@sun1991
测试环境是单库，发出多个请求就会导致数据重复
假设有 1,2,3 个请求
请求 1 返回成功结果，这时候服务端应该把数据插入表中了
请求 2 和请求 3 应该能 SELECT 到正确的数据啊？

@markss 不太懂茶，晚点我去茶园拍照给你们看看

@longbye0 自己种自己采，比贩子价格好点就行了

@McLeeV 是的，我们这里种的都是绿茶

@radio777
@kingjpa 茶叶采摘和制作周期长，需要可以加我小而美： MTM3MTIzNTI1NDQ=
到时候走小黄鱼预定

@radio777 是手工的，需要的话，买口新的干净炒锅炒，不然会有锅的味道
我不太懂茶，需要可以视频给你直播，看看你要哪种哪部分，毛尖还是什么鬼的

有没有可能是你镜像问题？
2003 这种老古董镜像可能用低版本 vmware ，比如 8,9 可能会更稳定一点