[转]秒杀架构优化，产品折衷

文章目录

今天有朋友问我，说我的文章里，总是提“脱离业务的架构设计是耍流氓”。

每次都是架构根据业务折衷，有没有业务和产品由于技术难度太大来做折衷的？

当然有，当一个业务技术难度非常大的时候，可以通过业务和产品的优化，来简化系统架构。

以“12306车票秒杀”为例，秒杀业务架构难度大，业务和产品可以这么折衷：

case 1

一般来说，下单和支付放在同一个流程里，能够提高转化率。

对于秒杀场景，产品上，下单流程和支付流程异步，放在两个环节里，能够降低数据库写压力。

12306，下单成功后，系统占住库存，45分钟之内支付即可。

一般来说，所有用户规则相同，体验会更好。

对于秒杀场景，产品上，不同地域分时售票，虽然不是所有用户规则相同，但能够极大降低系统压力。

北京9:00开始售票，上海9:30开始售票，广州XX开始售票，能够分担系统压力。

秒杀场景，由于短时间内并发较大，系统返回较慢，用户心情十分焦急，可能会频繁点击按钮，对系统造成压力。

产品上可以优化为，一旦点击，不管系统是否返回，按钮立刻置灰，不给用户机会频繁点击。

一般来说，显示具体的库存数量，能够加强用户体验。

对于秒杀场景，产品上，只显示有/无车票，而不是显示具体票数目，能够降低缓存淘汰率。

显示库存会淘汰N次，显示有无只会淘汰1次。更多的，用户关注是否有票，而不是票有几张。

…

无论如何，产品技术运营一起，目标是一致的，把事情做好，不存在谁是甲方，谁是乙方的关系。

脱离业务的架构设计是耍流氓。
架构难度大，产品也应该折衷。
画外音：秒杀业务的架构优化讲过了，这次说产品上的优化。

兄弟，你的产品折衷了吗？或者，奇葩了吗？
欢迎分享你的故事。