- 标清
- 2.0x
- 1.5x
- 1.25x
- 1.0x
- 0.5x
如何设计并实现一个高可用的订单系统？
订单系统是交易平台的核心，而遇到丢单是最糟的情况。从接单到落库之间的这段过程，订单最容易丢单。一个日千单和一个日千万单级的订单系统，在架构设计实现上肯定是不一样的。那么如何设计并实现出一个不丢单的千万级订单系统架构呢？
讲师介绍
张松然，前京东架构师。他有 10 余年资深架构经验，一直从事平台的架构设计与开发工作，在构建高性能、高可用大规模分布式系统有较丰富的实战经验。有多年在微服务领域的设计、开发经验，对分布式技术有深入研究与领悟。
精选留言(12)
- keepmoving 置顶非常感谢，按这种方式，如果只在结算页进行合法性校验和金额的计算，那是不是就意味在生成结算页面的时候已经将生成订单所需的数据进行了持久化，比如满减后的金额，如果不这样，在进行订单提交的时候只根据页面传给后台的金额进行订单的后续流程生成会不会存在伪造请求数据的风险？
作者回复: 你好同学，你说的很对。在进入结算页的时候，商品数据数据会被记录，生成商品快照，否则就会出现你在结算看到的金额是50元，这时后台运营修改了商品价格变成了100元，你支付应该还是以商品快照的金额50元为准。另一点你提到了数据风选，这点考虑的很好，商品快照和预订单数据是存储在后台系统中，通过前台页面的唯一标识进行匹配校验的，结算页的敏感数据是只做前台显示，后台不会使用前台的数据进行后台操作的，以此保障数据安全。
2019-10-23 7 
gu从问题出发，针对业务场景进行设计开发。让学者更加容易理解。2019-10-15 6
夏亮果然是大牛，讲得非常透彻！解决了丢单的疑问2019-10-15 5- gu66662019-10-15 4
- keepmoving接单服务把数据存储到数据库并刷到缓存中，如果在后续订单引擎处理业务流程中发现业务的合法性校验有问题导致无法继续执行而下单失败，那之前生成的订单数据应该怎样处理
作者回复: 这位同学你好，你的问题很好。这个问题其实涉及到一个系统各模块的职责问题，接单和引擎的职责，已经是负责接入并转移生产，的确这个过程可能出现问题，但是如果是合法性校验错误问题，我个人认为这个是需要前置处理的，位置是在进入结算页，以及点击结算生成订单快照那些步骤，因为订单其实就是一份电子合同，如果是在后续环节出现问题，比如钱计算错了，这种情况往往平台还需要履约的。
2019-10-22 3 
AaronYu高并发下减库存是否可以通过消息队列异步执行。作者回复: 您好，同学。高并发下减库存要首先确认下场景，在限时秒杀场景使用消息队列，会不会出现消息延迟导致超卖的问题？你的业务是否接收呢。如果是普通场景，流程允许一定范围的超卖，使用消息队列我觉得也是可以的，当然采用缓存也是可以的。在极客时间上有个老师专栏专门讲了秒杀系统的设计，我也学习了，推荐给你。
2019-10-19 1 3- 小脚丫深入浅出，讲的真好2019-10-15 3
. 。o O 〇你好 下单没有减库存或者预减库存吗？另外千万级订单也没有减少数据库写入，并且流程更复杂了，他的性能是怎么比万级订单高的呢……作者回复: 这位同学你问的问题都很切入实际的关键点哦，给你个赞。第一个问题，正常的下单流程是在订单转移以后在减库存的，流程是允许超卖的出现，这个和降价限时秒杀是不一样的。第二个问题，高订单量采用的是分而治之的策略，接单服务只负责把订单存下来，并创建首任务，只负责这一个单一职责，后续操作则采用异步多线程的方式处理，这与万级架构中，读写操作都访问到同一数据库是有本质的区别的。感谢你的留言和支持。
2019-10-18 2
看不到de颜色订单编号是如何生成的呢。如何保证高并发场景下快速生成且不重复。作者回复: 订单号生成策略的设计与实现也是非常巧妙的，支撑数亿级的高并发设计，你可以参考下美团的案例。我提供的基本思路是一种生产者和消费者得理念。
2019-10-16 1 2
Alexdown讲得不错，这个算是系统设计了，给了一种思路但落地仍有困难。期待更具体的“功能点设计与实现”视频，只讲解大系统/子系统中的某一功能点比如排行榜、互粉，点赞、留言等在不同并发量级下的设计与实现。这样多个“功能点设计与实现”视频可以组成合集——实现出一个大系统/子系统。作者回复: 你的建议非常好，一看你就是好学的同学。谢谢你的支持，我会加油，争取有更好的分享给大家。
2019-10-16 2
AAA如果结算的时候享受到促销或者活动,实际支付的时候 促销或者活动失效了,也是按照结算的快照支付吗?2019-12-09
卡卡任务状态机是怎么实现的？是自己写的还是有现成的技术框架2019-12-03
36:19
43:04
41:43