商城系统，根据不同的业务需求，归类出几种购买活动。比如：常规商品的购买，稀缺商品的秒杀活动，特价商品的限时优惠活动，加价换购活动，拼团活动，众筹活动，将要发行销售的预售活动。这里，针对预售活动场景，来进行细聊。

预售活动，一个商品，还未上市，提前进行预售，这是对市场需求的摸底。比如，某位歌手，要发行新的专辑，提前进行销售，根据预售的情况，进行生产，而不会造成大量库存积压。

粉丝为了自己偶像，冲击各种记录，比如几分钟销量破多少万，第一天销量多少万，而导致预售开始的前几十分钟，并发很高。

商家为了更好的刺激用户，会设置多种促销方案，比如，实时销量，用户购买排行榜，购买的用户可以解锁某个合成的海报，可以获得专辑的抽奖码等。所以，用户支付成功后，后端需要进行很多相应的处理。

根据上面的分析，预售活动，一般无需设置库存，也就不存在由于扣减库存导致的锁争夺而造成提交订单失败。

但是按照常规提交订单的流程，高并发去提交订单到一个数据库表中，这时服务器磁盘io性能瓶颈限制了mysql性能。

首先，我们可以更换服务器的硬盘为SSD，但单台的服务器性能始终有上限，那么我们可以通过扩展服务器的数量，横向扩展(理论上可以无限扩展)。

比如，有1w个用户，提交订单，1台数据库服务器性能支撑不住，那么如果我们有10台缓冲数据库服务器，一台缓冲数据库服务器只需支撑1k用户提交订单，大大减少了服务器io压力。最后在一个后台任务中把缓冲数据库中的订单同步到订单表中。

一台服务器能够支撑的并发，上限是5k，那么如果只有一台web服务器，需要支撑1w个并发请求，也是远远不够的，更何况还要处理支付成功后的几种促销方案。这时我们需要准备多几台web服务器，需要根据不断的压测，来决定web服务器的数量。

我们还需要一台总入口nginx服务器，来进行轮询访问几台web服务器。这样，其中一台web服务器的宕机，只影响一部分用户的访问。同时，还需要用一台性能差些的服务器作为入口nginx服务器的备份。

Token，身份令牌，可以让一个用户访问不同的web服务器，而用户是无感知的。而用户具体的信息，我们可以存放到redis缓存中。这样不同web服务器，拿到token的时候，都可以获取到用户id，组成一个缓存key(比如：user:session:用户id),从而去redis获取到用户的相关信息，实现session在不同web服务器间共享。

1，提交订单

(1)生成订单号。我们可以使用“年月日时分秒+流水号”，redis的incr方法实现流水号，key值为年月，这样每个月的流水号都从1开始。

(2)获取缓冲数据库的索引。比如，我们有2台缓冲服务器。订单流水号为1，那么index=1%2=1订单流水号为2，那么index=2%2=0订单流水号为3，那么index=3%2=1

(3)订单插入到对应的缓冲数据库中。我们可以只存订单号，订单数据转化为josn字符串存放到字段中，方便扩展。订单号为了方便搜索订单数据。

2，写入缓存

(1)根据用户id和订单号合成redis缓存key，比如“Mall:OrderBuffer:1：2020021312130100001”(1=用户id，2020021312130100001=订单号),把订单详情缓存key存放到缓存中。后面获取所有还没同步到订单表的缓冲订单号列表，就可以直接从redis中读取。

(2)根据订单号合成redis订单详情缓存key，比如“Mall:OrderBuffer:2020021312130100001”(2020021312130100001=订单号)，把订单所有信息存放到缓存中。这样，可以根据上面两种redis缓存，读取出用户所有在缓冲表中但还没同步到订单表中的订单。

3，写入消息队列

把订单号和缓冲库的索引，推送到消息队列中，这里使用的是RabbitMQ，返回提交成功。

4，后台订阅任务

(1)订阅消息队列

(2)同步缓冲表中的订单到订单表中

(3)删除缓冲表中到订单数据

5，订单有变更，更新缓存

订单支付成功同步回调/异步回调，都需要判断，缓冲订单是否同步到订单表中，如果没有，需要更新缓冲数据库中的订单支付状态，更新redis缓存中的订单支付状态。这里需要注意：如果缓存订单在同步中，刚好支付成功回调了，要规避好边界点。

每一个技术，很难直接生产价值，只能依托于某个产品，去兑现价值。