先执行select sn from xxxx where oid=xxxx, 找指定的oid的记录，如果错误，就是记录不存在（数据库挂了？不可能的啦。。），然后既然不存在，那就新增对应oid的一条记录。这是常用的如果有就读出来没有就创建新记录的机制。
逻辑和流程没问题？
笑话，大力出奇迹，板砖也能飞上天！
同时并发一堆这请求，只要力气够大速度够快，大家都可以同时在select还没来得及insert的时候进入if err!=nil，就产生了一堆相同oid的记录。
啥？没这么巧？系统因为这个重复一大堆，现在都还不知道怎么擦这屁股。。。
还好，只是短信和cos受影响，我们的用户的app大都一直登录着的，不需要发短信验证码，然后cos的东西都被cdn缓存着的。所以，实际上对我们没影响。不然今天要烦死。
虽然这blog也没指望人来，不过google/bing的蜘蛛也都不来，这很奇怪啊。
外链少，但是是有的，我把它加在一个高权重站里的，然后去google站长工具里面提交，连sitemap.xml它都不读，直接返回错误。
难道这个域名先前有恶劣的历史吗?
**后记: 更换成一个老域名后，google/bing基本都是瞬间就来了。不过，那是个备案过的域名，不敢造次，新注册了这个org看看了，以前是用的xyz，也许是这个问题吧。
blog目前是指向的oracle伦敦的npm，反向代理到维也纳的netcup。netcup用的年合约的机器，ip不能暴露，所以用可以随时免费改ip的oracle做前端。 访问首页总时间是0.95秒，凑合了。
www是使用的cf，在我的测试中，国内目前是使用的英国伦敦的节点(阿里和腾讯云都是)，所以，路径和前一个其实是一样的，都是中国-英国-奥地利。然而，访问首页总时间是3.3秒。和blog相比差了不是一点点了。
很明显的，这个就和gayhub一样，CF的路由被劣化，就是因为客观原因不能让人不能访问，但不能让人很顺畅的访问。
呵呵。
root@iZprae2jiix4ryZ:~# curl -o /dev/null -s -w time_namelookup:"\t"%{time_namelookup}"\n"time_connect:"\t\t"%{time_connect}"\n"time_appconnect:"\t"%{time_appconnect}"\n"time_pretransfer:"\t"%{time_pretransfer}"\n"time_starttransfer:"\t"%{time_starttransfer}"\n"time_total:"\t\t"%{time_total}"\n"time_redirect:"\t\t"%{time_redirect}"\n" https://blog.yessure.org/
time_namelookup: 0.002285
time_connect: 0.237758
time_appconnect: 0.480612
time_pretransfer: 0.480750
time_starttransfer: 0.779871
time_total: 0.951455
time_redirect: 0.000000
root@iZprae2jiix4ryZ:~# curl -o /dev/null -s -w time_namelookup:"\t"%{time_namelookup}"\n"time_connect:"\t\t"%{time_connect}"\n"time_appconnect:"\t"%{time_appconnect}"\n"time_pretransfer:"\t"%{time_pretransfer}"\n"time_starttransfer:"\t"%{time_starttransfer}"\n"time_total:"\t\t"%{time_total}"\n"time_redirect:"\t\t"%{time_redirect}"\n" https://www.081119.xyz/
time_namelookup: 0.263481
time_connect: 0.626214
time_appconnect: 1.000285
time_pretransfer: 1.000428
time_starttransfer: 1.430606
time_total: 3.297110
time_redirect: 0.000000人生的意义在于折腾，人不折腾，和咸鱼还有啥区别。 :)
玩了一个通宵，看上去差不多了。
