简单的订单异步处理实现

介绍

前面几篇文章，我们从 「限流角度，缓存角度」 来优化了用户下单的速度，减少了服务器和数据库的压力。这些处理对于一个秒杀系统都是非常重要的，并且效果立竿见影，那还有什么操作也能有立竿见影的效果呢？答案是对于下单的异步处理。

在秒杀系统用户进行抢购的过程中，由于在同一时间会有大量请求涌入服务器，如果每个请求都立即访问数据库进行扣减库存+写入订单的操作，对数据库的压力是巨大的。

如何减轻数据库的压力呢，「我们将每一条秒杀的请求存入消息队列（例如RabbitMQ）中，放入消息队列后，给用户返回类似“抢购请求发送成功”的结果。而在消息队列中，我们将收到的下订单请求一个个的写入数据库中」，比起多线程同步修改数据库的操作，大大缓解了数据库的连接压力，最主要的好处就表现在数据库连接的减少：

• 同步方式：大量请求快速占满数据库框架开启的数据库连接池，同时修改数据库，导致数据库读写性能骤减。
• 异步方式：一条条消息以顺序的方式写入数据库，连接数几乎不变（当然，也取决于消息队列消费者的数量）。

「这种实现可以理解为是一中流量削峰：让数据库按照他的处理能力，从消息队列中拿取消息进行处理。」

秒杀系统

秒杀系统相信网上已经介绍了很多了，我也不想粘贴很多定义过来了。

废话少说，秒杀系统主要应用在商品抢购的场景，比如：

• 电商抢购限量商品
• 卖周董演唱会的门票
• 火车票抢座
• ……

秒杀系统抽象来说就是以下几个步骤：

• 用户选定商品下单
• 校验库存
• 扣库存
• 创建用户订单
• 用户支付等后续步骤

听起来就是个用户买商品的流程而已嘛！确实，所以我们为啥要说它是个专门的系统呢？

秒杀系列开篇文章，整理分布式微服务设计中，面对高并发场景的一系列潜在问题和处理思路。

缓存热点数据

在秒杀实际的业务中，一定有很多需要做缓存的场景，比如售卖的商品，包括名称、详情等。访问量很大的数据，可以算是“热点”数据了，尤其是一些读取量远大于写入量的数据，更应该被缓存，而不应该让请求打到数据库上。

小伙伴们有没有遇到过生产环境经常出现过重复的数据？在排查问题的时候，数据又是正常的。这个是何解呢？怎么会出现这种情况，而且还很难排查问题。

今天给大家分享一下这里的原因，以及解决方案。

本篇介绍 HSF 框架的开发应用。

HSF 框架，全称 High Speed Framework，是 Alibaba 内部使用的 RPC 框架，最初于 Dubbo 进行内部竞争，由于多方面的原因最终选择了 HSF。

HSF 作为阿里内部高性能的 RPC 框架，其优点是轻量，高性能，运维成本低的特性，为大规模集群的应用提供了好的基础。

入职前需要掌握的一个框架，HSF，自学的同时也分享给大家。

服务治理是 EDAS 的重要功能之一。在 EDAS 中，用户可以对 Spring Cloud、Dubbo、HSF 和多语言服务应用进行治理，包括服务查询、调用链查询、离群实例摘除和服务鉴权等。

您可以将 Java 应用托管到 EDAS 的 ECS 集群或混合云 ECS 集群。EDAS 为托管的应用提供了生命周期管理、CI/CD、监控、运维等一系列功能。

EDAS 支持以容器的形式托管应用到阿里云 Kubernetes 集群或混合云集群（其他云域或 IDC 内自建 Kubernetes 集群），用户无需理解容器服务底层细节，便可以低门槛拥抱容器技术，最大化地利用资源并完成应用在容器里的全生命周期管理，以及监控、运维等服务。

本文介绍 K8s 环境支持的应用类型和应用托管功能。