秒杀业务，除了技术，还需要业务折衷
脱离业务的架构都是耍流氓
每次都是架构根据业务折衷，有没有业务和产品由于技术难度太大来做balance的？
当然有，当一个业务技术难度非常大的时候，可以通过业务和产品的优化，来简化系统架构。
秒杀业务架构难度很大，业务和产品可以这样折衷：
一般来说，下单和支付放在同一个流程中，能够提高转化率。
对于秒杀场景，产品上，下单流程和支付流程异步，放在两个环节里，能够降低数据库写压力。
拼多多秒杀，下单成功后，系统占着库存，30分钟之内支付即可。
一般来说，所有用户规则相同，体验会更好。
对于秒杀场景，产品上，不同区域分时售票，虽然不是所有用户规则相同，但能够极大降低系统压力。
北京9：00开始售票，上海9：30开始售票，广州xx开始售票，能够分担系统压力。
秒杀场景，由于短时间内并发较大，系统返回较慢，用户心情焦急，可能会频繁点击按钮，对系统造成压力。
产品上可优化为，一旦点击，不管系统是否返回，按钮立刻置灰，不给用户频繁点击。
我们在携程网购票的时候，如果是显示具体的数据，会给用户带来比较好的体验。
但是对于秒杀场景，产品上，只显示有/无车票，不显示具体票数目，能够降低缓存淘汰率。
那是因为显示库存会随着业务的层级淘汰N次，只会在最后真正购买的时候淘汰一次，大多数时候用户关注是否有票，而不是几张。
这边可以参考<<6.18秒杀架构模型设计实践>>,这是从技术的考量角度来解决问题。
无论如何，产品技术运营一次，目标是一致的，把事情做好，不存在谁是甲方，谁是乙方的关系。
脱离业务的架构设计就是耍流氓。
架构难度大，产品也应该折衷。
原文作者：二进制跳动；如有侵权，请联系管理员删除。
