|
|
51CTO旗下网站
|
|
移动端
创建专栏

秒杀架构优化,产品折衷

最近有朋友问我,说我的文章里,总是提“脱离业务的架构设计是耍流氓”。每次都是架构根据业务折衷,有没有业务和产品由于技术难度太大来做折衷的?

作者:58沈剑|2018-06-24 08:40

【线上直播】11月21日晚8点贝壳技术总监侯圣文《数据安全之数据库安全黄金法则》

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

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

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

秒杀架构优化,产品折衷

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

case 1

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

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

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

case 2

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

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

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

case 3

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

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

case 4

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

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

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

...

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

脱离业务的架构设计是耍流氓。

架构难度大,产品也应该折衷。

画外音:秒杀业务的架构优化讲过了,这次说产品上的优化。

【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

【编辑推荐】

  1. 百亿级日志系统架构设计及优化
  2. Spring Cloud构建微服务架构:分布式配置中心(加密解密)
  3. 一文读懂 Spring Boot、微服务架构和大数据治理三者之间的故事
  4. 外媒速递:DevOps爱好者不容错过的七本微服务架构论著
  5. 王宜怀:窄带物联网NB-IoT应用架构|V课堂第115期
【责任编辑:赵宁宁 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢