详细讲解：RocketMQ的限时订单实战与RocketMQ的源码分析！

一、限时订单实战

1.1、什么是限时订单

在各种电商网站下订单后会保留一个时间段，时间段内未支付则自动将订单状态设置为已过期，这种订单称之为限时订单。

1.2、如何实现限时订单

1.2.1、限时订单的流程

电商平台都会包含以下 5 种状态。
待付款：代表买家下单了但是还没有付款。
待发货：代表买家付款了卖家还没有发货。
已发货：代表卖家已经发货并寄出商品了。
已完成：代表买家已经确认收到货了。
已关闭：代表订单过期了买家也没付款、或者卖家关闭了订单。

1.2.2、限时订单实现的关键

我们可以看到，订单中的很多状态都是可以用户触发的，唯独订单过期了买家也没付款我们需要自动的把订单给关闭，这个操作是没有用户或者是 人工干预的，所以限时订单的关键就是如何检查订单状态，如果订单过期了则把该订单设置为关闭状态。

1.2.3、轮询数据库？

轮询数据库在实现限时订单上是可行的，而且实现起来很简单。写个定时器去每隔一段时间扫描数据库，检查到订单过期了，做适当的业务处理。 但是轮询会带来什么问题？
1、轮询大部分时间其实是在做无用功，我们假设一张订单是 45 分钟过期，每 1 分钟我们扫描一次，对这张订单来说，要扫描 45 次以后，才会检查 到这张订单过期，这就意味着数据库的资源（连接，IO）被白白浪费了；
2、处理上的不及时，一个待支付的电影票订单我们假设是 12:00:35 过期，但是上次扫描的时间是 12:00:30，那么这个订单实际的过期时间是什么时 候？12:01:30，和我本来的过期时间差了 55 秒钟。放在业务上，会带来什么问题？这张电影票，假设是最后一张，有个人 12:00:55 来买票，买得到吗？ 当然买不到了。那么这张电影票很有可能就浪费了。如果缩短扫描的时间间隔，第一只能改善不能解决，第二，又会对数据库造成更大的压力。
那么我们能否有种机制，不用定时扫描，当订单到期了，自然通知我们的应用去处理这些到期的订单呢？

1.2.4、Java 本身的提供的解决方案

java 其实已经为我们提供了问题的方法。我们想，要处理限时支付的问题，肯定是要有个地方保存这些限时订单的信息的，意味着我们需要一个容器， 于是我们在 Java 容器中去寻找。Map? List? Queue?
看看 java 为我们提供的容器，我们是个多线程下的应用，会有多个用户同时下订单，所以所有并发不安全的容器首先被排除，并发安全的容器有哪 些？一一排除，很巧，java 在阻塞队列里为我们提供了一种叫延迟队列 delayQueue 的容器，刚好可以为我们解决问题。
DelayQueue： 阻塞队列（先进先出）
1）支持阻塞的插入方法：意思是当队列满时，队列会阻塞插入元素的线程，直到队列不满。
2）支持阻塞的移除方法：意思是在队列为空时，获取元素的线程会等待队列变为非空。
延迟期满时才能从中提取元素（光队列里有元素还不行）。
Delayed 接口使对象成为延迟对象，它使存放在 DelayQueue 类中的对象具有了激活日期。该接口强制实现下列两个方法。

• CompareTo(Delayed o)：Delayed 接口继承了 Comparable 接口，因此有了这个方法。让元素按激活日期排队
• getDelay(TimeUnit unit):这个方法返回到激活日期的剩余时间，时间单位由单位参数指定。
  阻塞队列更多详情，参考 VIP 课程《并发编程》

1.2.5、架构师应该多考虑一点！

架构师在设计和实现系统时需要考虑些什么？
功能，这个没什么好说，实现一个应用，连基本的功能都没实现，要这个应用有何用？简直就是“一顿操作猛如虎，一看战绩零比五”
高性能，能不能尽快的为用户提供服务和能为多少用户同时提供服务，性能这个东西是个很综合性的东西，从前端到后端，从架构（缓存机制、异 步机制）到 web 容器、数据库本身再到虚拟机到算法、java 代码、sql 语句的编写，全部都对性能有影响。如何提升性能，要建立在充分的性能测试的基 础上，然后一个个的去解决性能瓶颈。对我们今天的应用来讲，我们不想去轮询数据库，其实跟性能有非常大的关系。
高可用，应用正确处理业务，服务用户的时间，这个时间当然是越长越好，希望可以 7*24 小时。而且哪怕服务器出现了升级，宕机等等情况下，能 够以最短的时间恢复，为用户继续服务，但是实际过程中没有哪个网站可以说做到 100%，不管是 Google，FaceBook，阿里，腾讯，一般来说可以做到 99.99% 的可用性，已经是相当厉害了，这个水平大概就是一个服务在一年可以做到只有 50 分钟不可用。这个需要技术、资金、技术人员的水平和责任心，还要 运气。
高伸缩，伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。就像弹簧一样挂东西一 样，用户多，伸一点，用户少，缩一点。衡量架构是否高伸缩性的主