如文章“”中提到的，对于同样的高并发情景，这三种类型的企业的建筑挑战是不同的：

那么，如何优化系统和业务中的销售业务呢？这是本文中要讨论的问题。

在系统级别，销售业务的优化方向是什么？有两个主要项目：

（1）尝试拦截系统上游的请求，并且不要让锁冲突落入数据库中。

传统闪存销售系统被悬挂的原因是，请求被按下后端数据层，数据读取和写入锁定冲突是严重的，并发率很高，响应很慢，几乎所有请求都超时，访问流量很大，并且成功订购的有效流量很小。

火车有2,000张门票，同时有200,000人来购买。没有人能成功购买它，请求效率为0。

配音：此时系统的效率不如离线票务窗口的效率。

（2）充分使用缓存。

快照在几秒钟内购买门票，这是一种典型的业务场景，在其中更多的读物，较少的写作和更少的内容：

火车有2,000张门票，同时有200,000人来购买，多达2,000人成功下订单。其他人则检查库存，写入率仅为0.1％，读取率为99.9％，非常适合使用缓存来优化。

销售的常见系统层次结构是什么？

对于销售，您可以使用典型的面向服务的层次结构：

这四层应该如何优化？

1。终端上的请求拦截（浏览器/应用程序）

我相信，每个人都在春季音乐节上扮演微信的颤抖和抓住红色信封。用户每次摇晃时都会真正向后端发送请求吗？

回头看票的场景，用户单击“查询”按钮后，系统被结结巴巴，用户很着急，并且会不知不觉地再次单击“查询”。它不仅没有用，而且无缘无故地增加了系统负载。平均而言，一个用户点击5次，而80％的请求是很多。

在JS级别，用户只能在X秒内提交一次请求，从而减少系统负载。

画外音：经常提交，您可以提示“频率太快”。

在应用程序级别上，可以做类似的事情。尽管用户疯狂地摇动微信来抓住红色的信封，但实际上，只有在x秒内进行后端一次。

-Over：这就是所谓的“尝试在系统上游拦截请求”，并且浏览器/应用程序层可以拦截80％+请求。

但是，终端上的拦截只能阻止普通用户（99％的用户是普通用户）。程序员捕获数据包后，写一个for循环并直接调用后端HTTP接口。 JS截距根本不起作用。我现在该怎么办？

2。在网站层的请求拦截

如何抗拒编写循环的程序员来调用HTTP接口，首先，您必须确定用户的唯一身份并拦截经常访问它的用户。

什么用来成为用户的唯一标识符？

ip？ -ID？不要认为太复杂了。门票购买服务需要登录，您可以使用UID识别用户。

在站点级别上，对同一UID的请求进行计数和速度限制。例如，仅允许UID在5秒内通过1请求，这可以阻止99％的循环请求。

如果UID，5S仅通过一个请求以及其余的请求，该怎么办？

缓存，页面缓存和其他在5秒内​​到达站点级别的请求将返回上次返回的页面。

旁白：火车号查询和票务查询都可以用来确保这一点，这不仅可以确保用户体验（至少不返回第404页），还可以确保系统的鲁棒性（使用页面缓存来拦截站点级别的请求）。

好的，有99％的普通程序员通过计数，速度限制和页面缓存被阻止，但是仍然有一些高端程序员，例如，控制了100,000个肉鸡的黑客，手中有1000个UID，并同时发送了请求。我现在该怎么办？

3。在服务层请求拦截

并发请求已达到服务层。如何拦截它？

服务层非常清楚，有关业务库存和数据库的压缩阻力。它可以根据这两个进行峰值切割和速度限制。

例如，商业服务清楚地知道，火车只有2,000张门票，此时向数据库发送100,000个请求是毫无意义的。

旁白：如果数据库只能承受每秒500个写请求，则只能传递500个传递。

使用什么峰值切割？

请求队列。

对于写请求，这是一个请求队列，每次都只会传递有限的写入请求，即可到达数据层（下订单并支付此类写入服务）。

只有2,000张火车票，即使有10,000个请求，也只会传输2,000个以访问数据库：

如何优化阅读请求？

无论是否是，一台机器每秒都可以抵抗100,000。

旁白：缓存是水平扩展的，很容易线性扩展。

通过这样的峰值切割和当前限制，只有很少的写请求，很少有读取缓存mis请求将渗透到数据层中，而99％的请求被阻止了。

4。数据库层

在前三层优化之后：

您会发现数据库层的每个请求都是可控的。

DB基本上没有压力，您可以在花园里走来走去。

：这种类型的业务数据并不大，也无需划分数据库。只需做一个高可用性数据库即可。

目前，有2,000个传递给数据库，所有这些都成功，请求效率为100％。

配音：在优化之前，0个10W的请求成功，有效性为0％。

根据上述优化计划，场地层的压力最大。假设实际有效的请求数量为每秒100W，那么如何处理这一部分压力？

有两种解决方案：

（1）通过添加机器容量扩展，一个单位可以抵抗5,000或200个单位；

（2）服务降级，放弃请求，例如放弃50％；

原则是保护系统，不要使所有用户失败。

站点级限制是每个UID的请求计数吗？如果在大量吞吐量的情况下，如果存在高的并发访问，网络带宽会成为瓶颈吗？

相同的UID计数和速度限制，如果您担心访问带宽会成为瓶颈，则可以这样对其进行优化：

（1）计数直接放置在内存中，从而保存网络请求；

（2）在层上做7层平衡，让UID请求落在同一台计算机上；

配音：此计数不需要高数据一致性和准确性。即使服务重新启动计数丢失，最糟糕的事情是重新开始计数。

除了系统优化外，产品和业务还可以做出一些权衡，以减少建筑难度。

业务权衡

一般而言，下订单并在同一过程中付款可以提高转化率。对于销售方案，产品，订购过程和付款过程是异步的，并将其放置在两个链接中，它可以减轻数据库编写的压力。举例来说，成功下订单后，系统将占据库存并在45分钟内付款。

业务权衡两个

一般来说，如果所有用户都有相同的规则，那么体验会更好。对于销售方案，就产品而言，在不同地区的时间共享票务销售，尽管并非所有用户规则都是相同的，但它们可以大大减轻系统压力。门票销售从北京的9:00开始，门票销售从上海开始，票价从上海开始，票价从广州的XX开始，这可以分享系统的压力。

业务权衡三

在销售方案中，由于在短时间内同时发生，系统恢复缓慢，并且用户非常焦虑，并且可能会经常单击按钮，从而对系统造成压力。可以优化产品，以使该按钮立即被灰色，无论系统是否返回，都不会给用户经常单击。

业务权衡四

一般而言，显示特定库存数量可以增强用户体验。对于销售方案，仅显示产品中有/不带有门票的门票，而不是显示特定数量的门票，才能降低缓存消除率。

画外音：显示库存将被删除n次，并显示是否只会消除一次。更重要的是，用户担心是否有门票，而不是有多少张门票。

无论如何，与产品技术运营一起，目标是一致的。做得很好，谁是党派和谁是党。

总结

对于 Sale ，除了产品和业务妥协外，建筑设计中还有两个主要优化方向：

（1）尝试拦截系统上游的请求；

（2）阅读更多，写少并使用缓存；

任何倒闭的建筑设计都是流氓。