一、电商平台交易系统架构设计
1、交易系统的含义&作用
首先要思考一个问题，何为交易？说白了就是一笔买卖。
从商家的角度看，把自己货架上的商品推销出去，就算一比是一笔买卖达成了。
先暂且不讨论售出之后会不会产生任何的退款纠纷，因为严格来说那属于售后范畴，也改变不了这件商品曾经被商家推销出去的事实。
那么从电商的角度来看，一件商品是否被成功推销出去最最核心的依据就是一笔订单有没有被创建出来。
无论用户最后是否付款成功，只要用户按下“提交订单”这个按钮，就说明把产品推销出去了，也就产生了一笔交易。明白了这个概念
现在可以知道交易系统能是什么了——能够促进用户下订单的系统就可称为交易系统。如图↓：
图↑中我们看到，交易系统展现了商品价格的低廉，将商品推销出去，促进了用户下单
但往往推销商品的手段和方式又何止凭借 价格低廉 这一种 如图↓：
可以看到一个交易系统，可以对产品进行各种维度的推销包装，来吸引用户下单。
上面↑ 列举的促销维度大致包括：广告，结算策略，支付方式，商品详情页，秒杀场次
这些维度的信息往往由对应的服务来维护，大家可以想象这么多维度的数据都交易系统来维护的话，那么所有请求都在交易系统进行复杂的逻辑处理，交易系统一定会不堪重负的 如图↓：
2、交易系统服务架构
所以此时想必大家都知道了，这个时候就需要依据各个维度的数据进行服务的拆分，也就是划分微服务。
此时 一个交易系统是由多个微服务提供相应的功能来完成自身所负责的业务功能 ，反过来说 交易系统对各个微服务进行整合 如图↓：
其中值得注意的一点是↑图中用蓝色填充的购物车模块，原则上它不能算是一个促销维度，但是当你对购物车里的商品进行变更时，也会触发例如，运费以及折扣的计算，影响着订单的提交金额，顾也算是交易系统的一部分。
通过↑上图就可以知道，在这样的架构下，交易系统就是一个业务中台，那么此时我们要对一件商品进行下单时，就要通过交易系统，将这个过程中涉及到的一些服务，根据业务需求的不同进行串联从而形成一条交易链路，如图↓：
看了上图↑想必大家都知道了，为什么当发现预约人数严重超标时，宁可提前结束预约活动，都要保证交易链路的安全， 因为这条链路上只要一个服务被巨额流量打垮，直接就有可能影响整个电商网站的正常运转 。
因此需要为口罩增设秒杀专场，此时交易链路就很不一样了，如图↓：
从上图↑中我们可以看到秒杀的链路，商品详情页的页面都是直接做了静态化处理，收银台也只牵扯到了金额计算相关的服务，自然不影响正常的交易链路，中间的秒杀系统我之前的文章中有提到如何进行建设，在此不多赘述。
3、总结
大家是否注意到黄色标出的链路节点没有？这些节点都是有对应的前端页面，正所谓爱美之心人皆有之，一个美观的前端界面也是吸引客户下单的重要因素，那必然是交易系统重要组成部分。
不仅如此，还要保证任何一种客户端访问都能提供良好的观感体验，在电商竞争环境如此激烈的当下，通过前端页面，或者是有对应界面的前台系统不断的更新迭代。让电商平台有更加出色的用户体验。
这类系统往往自身的业务功能并不复杂，主要是依赖更多后端服务来完成与客户端的交互，也是与客户端最为贴近的服务系统，被称为前台。
为前台提供数据支撑和接受前台业务请求的服务，这类系统被称为中台。
所以前台系统和中台系统完美搭配才能构建一个完整的系统 如图↓：
二、平台预约中台系统的整体架构设计
1、预约的含义&作用
预约的本质就是获得一件商品的购买权，没预约不让买，预约了也有可能买不到，场景一般适用于，新品发布，靠商品首发在竟对环境中凸显优势，如图↓：
以及因为某件商品库存紧缺，通过预约的方式把有限的库存尽可能合理分配，如图↓：
根据预约的数量情况，来判断接下来某个获取的库存量
也就是说预约本身并不能简单理解为一种促销手段，它更像是一种市场调研，亦或是凸显首发优势增强用户好感及黏性。
所以对于预约商品来说与普通售卖商品的交易链路本质是一样的，只是在它的链路上多了自己业务处理如图↓：
所以此次口罩预约活动的本意是为祖国母亲尽一份绵薄之力，没想到却引发了一场史诗级的秒杀，还造成了一定的社会反响。。。。
2、预约中台的架构介绍
我们想一下如果一件商品有用户已经预约了，那么此时商户如果把商品的款式，甚至是价格进行修改的话，那么商户的信誉势必会有不小的损伤，所以一旦一件商品发布了相关的预约场次是几乎不可能修改的，是典型的读多谢少的场景。此时，他是一种访问量很高，但是数据不常改变的数据
可以将这些有预约场次的商品信息写入redis，以保证读取数据的性能，但是不怕一万就怕万一，商品信息毕竟是核心的业务数据，一定要保证其查询的时效性
这里会出现我们之前讨论的一个问题，就是mysql&redis数据不一致问题
如果做不好的话就会出现如下的情况，如图↓：
所以在更新数据前一定要先删除缓存，避免用户读取到脏数据如图↓：
那么现在是否就万无一失了？还差一点，因为如果用户并发访问系统，一个进行写，一个进行读会出现如下情况，如图↓：
那么此时可以采用之前说的内存队列的方式来解决，如图↓：
注意一下上图↑我始终没有两个读请求，道理很简单，如果前一个是读请求的话，就意味着没有发生数据更新，没有任何必要进行redis和mysql的同步操作，自然也没有必要入队列了。
这套预约系统的架构根据我们现在学到的知识大致如图↓所示：
预约系统架构如上↑，那么现在和之前的秒杀链路拼接起来如图↓：
三、电商平台预约中台的核心要素&处理链路
1、前言
此小节讲解预约业务的相关核心要素并梳理预约业务的处理链路
2、时间统一的重要性
先看图↓内容：
刨除掉预约商品本身的信息不谈，你觉得图中哪些信息是你作为商品的预约用户所关心的呢？
那毫无疑问的就是预约活动何时开始抢购，也就是说作为预约用户你关心的是这场预约活动的状态；
决定预约活动状态最为关键因素就是时间，如图↓所示：
那么时间和预约活动的状态有着密不可分的关系，那就意味着前端的展示时间，一定要和后端进行逻辑处理时所获取的时间一样，并且现在都是前后端分离，并且后端系统架构也都是分布式的，所以一定要确保预约系统所涉及到的机器，用于处理业务的时间一定要统一，否则就会出现下图↓的状况：
为了防止这样的情况，就不能让前端系统和后端系统依据他们的本机时间
必须有一个方案确保它们的时间没有误差。如图↓
通过一个授时服务来同步各个服务的时间
由此可以看到，预约自身重点就是在做数据采集，并没有太多复杂的业务牵涉，状态机的流转直接和时间挂钩，基本不涉及到其他复杂的逻辑判断。
所以如果仅仅是预约商品的的话，业务处理链路大致如图↓：
四、如何面对突然起来的高流量访问
1、预约中台在高流量的情况下显露出的问题
供不应求首先从业务层面上来说，预约口罩的人数量高出了可供库存，正是因为这种供不应求的情况已经到了无以复加的地步，直接让这场口罩预约活动直接冲上热搜。
这一方面说明了某电商开展这个活动，是非常有益的，吸引了大量用户参与其中，但另一面也是因为参与人数过多，致使大量用户最终抢购失败，虽然广大用户对这样的情况表示理解。
但毕竟是一种非常差的用户体验，也难免大家会在微博上进行小小的吐槽。所以从业务上来说当发现供不应求到了一定的比例，就要以一种全新的购买方式，稀释无效的参与人数以增强用户体验。不能实时关注流量情况若此次口罩预约的问题之所以能够被发现，只是在一次普通的例行检查中，被发现，这么严重的问题，居然没有计入系统告警系统。如果值班人员稍有疏忽，造成的结果是难以预估的，所以对于预约系统，应该增加对爆品SKU的监控才行。
用户的热情本是对这场预约活动的最好的认可，可某电商的程序员同学们，却一点也开心不起来，用户的热情汇聚成了泛滥的洪水。
那个“等待抢购”的置灰按钮就像是洪水的闸门，抢购的按钮一旦亮起，洪水的闸门打开，可以说对整个交易链路的参与者们，足以形成水淹七军之势，他们必将毫无招架之力，被弄得人仰马翻。如图↓：
2、解决方案
摇号首先从从业务说，如果预约人数远远大于商品的供应可供应量时，应该采取的方式这样，参与抢购的人数少了，服务器压力也不会很大，参与抢购的用户也能如愿的购买到需要的商品，未能参与抢购的用户也只是觉得运气不佳，不会有很大的埋怨。设定流量阈值再者就是监控，根据压测结果计算出一个核心交易链路所能承受的TPS阈值，高于这个阈值时发出警告，让相关人员能够引起警觉，尽早发现问题，给与开发人员更多的处理时间。熔断机制根据预约人数情况，添加熔断机制，即预约参与人数达到一定阈值后，切断之后的请求通向交易链路的通道，
如图↓：
