@wy315700
收费不收费再说，域名太多。一个个申请不起。
Let's Encrypt 好歹是自动化的。
项目早就做完了的，这是改，都找不到人了才折腾我头上帮忙。

@wy315700
对公的项目，事儿比较多，合同案值进第三方担保户里之后再申请一分钱都得去财政审批，没戏的。

@wy315700
使用 let's encrypt 是因为逗比客户不给钱买证书……
现在被劫持的比较厉害

@wy315700
不只是自己的 APP
有 APP 有 web 有客户端 有触摸屏 还有公众访问

@wy315700
我 google 的结果，根证书只能加入本地的 jre keystore ，用命令行指令

在代码中添加证书信任， google 到的结果并测试通过的只有把服务器当前的证书加入，这个操作可以代入根证书而不是当次连接的证书么？

ubuntu server 大法好

@naffan 我现在都是手机，最近长期驻医院陪护，等我倒开空给你发一组。楼主的我看的也不太仔细。

粗略的说 我的建表思路就是所有都独立商品，然后一个表存储哪些商品聚合在一起显示，一个额外的表对于非单条件聚合提供关联方式(比如颜色和尺码双选择这种)

具体表结构等我忙完给你找代码示例吧。

@naffan

实际生产上，我自己做的项目，以及我曾经加入的几个团队，都不是阿里那种处处关联的玩法。
每个 SKU 都是一个独立商品，在 item_show 的逻辑上进行一下关联聚合的比较多 顶天二次 ajax 一个库存余量虚了一些不存在的组合

@naffan
我说的不只是 SKU 这个名词
我表达不太好抱歉
很多阿里出来的高级开发，就总想着把 SKU 做到一起去，类似一楼的思想，就是这些东西一定是关联的，然后搞出一堆复杂的逻辑，可能内部实现非常好，技术、性能都非常牛逼，别人一看巨复杂，而且难以改变这个思想。

@jarlyyn
反正我发现他们出来的开发，天天把这个挂嘴上……

@sheldondai
现在都是依托内存 kv 引擎做这种东西了。性能极强，抗压能力提升三个量级以上。

我很早就搞过这种东西的算法，各种避免 select 再 update 的模型，最开始的理由极其朴素
你有没有发现我提到的这种算法可以不依赖支持事务的引擎？

最开始就是在高并发的前提下， MyISAM 引擎上跑类似这种逻辑，才提出的这种方案……

别纠结 SKU 什么的。
很讨厌跟阿里系出身的程序员、受阿里系代码逻辑影响谈商城系统设计。
天天就 SKU SKU 的……

只要有任何参数不同的，就是两种商品。
然后，提现所谓 SKU 的，只是显示层聚合，就是在 itemshow 的页面里面，根据配置去把本质是定义成不同的商品的东西聚合显示而已。

这种结构清晰，性能损失小，而且容易充分利用缓存系统。

国内环境，用原生绝逼死得快……
没有个系统底层实现的唤醒处理，权限处理机制，等着坑吧……

@sheldondai
不只是超售的问题，超售属于算法 0 分不及格。
性能差，抗压能力差两个量级。

@php230
pconnect 是 mysql 最大的一个骗局……
为啥 mysqli 都没有 pconnect 了……

建议实测 mysql_pconnect

如果纯在 mysql 的场景下操作，不用内存 key-value 系统，我更倾向于用另外一种模型处理这种竞争抢购的逻辑。

“需要先 select ，然后 insert ，最后 update -1 。最后这个-1 操作是不能出现负数的”

我可以分享一下我的思路，以及我的做法。

首先，楼主以及这个文章都提到超售的问题，如果你的系统设计上能出现超售，那说明你的逻辑太差。就这种 select insert update-1 的模型，在抢购的瞬间是怎么操作的呢？我们分析一下：

首先 用户 submit_order, 先去 select 库存，判断有，然后 insert 一个 order 表数据，然后 update 库存减 1

在 MYSQL 并发非常高的瞬间，这三部操作，都可能出现大坑，只要三步中一个操作被锁坑了，整体就坑了。

然后我们再抽象：假设抢购 50000 件商品

抢购前，库存表一条记录 值 50000 ，订单表 0 条记录
抢购后，订单表 50000 条记录，库存表 1 条记录，值 0

在抢购过程中（假设非常火， 5 秒钟抢完）
中间 select 次数远大于 50000 （抢购失败的也得查询库存）， update50000 次库存表-1 ， insert50000 个订单表 这么多查询吧。这三步是一个顺序逻辑，任何一步出问题整个操作都失败。

我的抢购系统，绝对不会设计的！

我有 50000 件商品，我在抢购开始前一个小时到抢购前 5 分钟， 55 分钟的时间里，写入订单表 50000 条记录。其中 orders 表的 uid 做 unique 约束。 UID 使用-1~-50000 预先填写好
我有 55 分钟时间插入 50000 条记录，不用 5 秒钟， MYSQL 无负载无压力

开始抢购，所有人就开放一个接口，拼命地往数据库里提交一个查询
update ignore `orders` set uid = '你的 UID' where uid<0 and item=3 limit 1
不用等执行结果 完全非阻塞的只接受一个指令 就行了

整个抢购过程，就是一群人发一个查询往里去，等管理端发现 50000 个记录确认都有主了，抢购结束标志设置好，关闭抢购接口，完成抢购。大家可以访问我的订单看抢购结果了。

按 PSR 规范貌似要求下一行

但是我烦死新建一行了……都是同行

V2EX 喷子太多了

人家并没说 LINUX 好， WINDOWS 不好吧，人家只是想从事 linux 相关工作，这都不行？