[Yima酷站编程开发教程]从互联网上收集高质量的教程和源代码资源！

高质量的软件开发，图形设计和其他教程以及来自上的高质量源代码资源可在一站式提供！

推荐：“ PHP视频教程”

1。为什么很难进行闪光销售业务？

1）IM系统，例如QQ或微博，每个人都读取自己的数据（朋友列表，组列表，个人信息）；

2）微博系统，每个人都可以阅读您关注的人的数据，一个人可以阅读多人的数据；

3）在 Sale系统中，只有一份库存副本。每个人都会在集中的时间阅读和写入数据，并且多人可以读取一个数据。

例如：小米手机每个星期二都有闪光拍卖。可能只有10,000部手机，但是瞬时交通可能是数亿或数千万。

另一个例子：抓票，门票有限，有一个库存，有很多瞬时流量，并且都阅读了相同的库存。读写冲突和锁非常严重，这是即时销售业务变得困难的地方。那么，我们如何优化销售业务的结构？

2。优化方向

有两个优化方向（我今天将谈论这两个点）：

（1）尝试拦截系统上游的请求（请勿让锁定冲突落在数据库中）。传统闪存销售系统失败的原因是请求不堪重负的后端数据层，数据读写锁定冲突是严重的，并发率很高，响应很慢，几乎所有请求都超时。尽管流量很大，但成功订单的有效流量很小。例如，实际上只有2,000张火车门票。如果200万人来购买它们，几乎没有人能成功购买它们，请求效率率为0。

（2）充分利用缓存并以闪光灯购买门票。这是阅读越来越少的典型应用程序。大多数请求是火车号查询，票务查询，订单和付款是写请求。实际上，火车只有2,000张门票，有200万人来购买它。最多有2,000人成功下订单，其他所有人都在查询库存。写比率仅为0.1％，读取率为99.9％。它非常适合缓存优化。好的，让我们谈谈“系统中尽可能上游请求的拦截”方法以及稍后“缓存”的方法。让我们谈谈细节。

3。常见的闪存销售结构

共同的站点架构基本上是这样（绝对不要绘制欺骗性的体系结构图）

（1）浏览器侧，顶层，将执行一些JS代码

（2）服务器端，该层将访问后端数据并将HTML页面返回到浏览器

（3）服务层（Web服务器），屏蔽了上游数据详细信息的基础，并提供数据访问

（4）数据层，最终库存存储在这里，这是一个典型的库存（当然会被缓存）

尽管这张图片很简单，但它可以生动地说明高流量和高额货币闪存销售业务体系结构。每个人都应该记住这张照片。

如何优化每个级别将在稍后进行详细分析。

4。每个级别的优化细节

第一层，如何优化客户端（浏览器层，应用程序层）

让我问你一个问题。每个人都玩过微信的摇动以抓住红色信封，对吗？每次摇晃时，请求会发送到后端吗？回顾一下我们下达订单以获取门票的场景，在单击“查询”按钮后，系统卡住了，进度栏慢慢增加。作为用户，我会不知不觉地再次单击“查询”，对吗？继续点击，继续单击，单击，点击。 。 。有用吗？系统负载无缘无故地增加。用户点击5次，并生成80％的请求。如何修复它？

（a）在产品级别上，用户单击“查询”或“购买票”后，该按钮将被灰色，并且禁止用户提交重复请求；

（b）在JS级别上，用户仅限于x秒内仅提交一个请求；

在应用程序级别，您可以做类似的事情。尽管您正在疯狂地摇动微信，但实际上您只在X秒内就向后端发出请求。这就是所谓的“系统在系统中尽可能远的截止请求”。上游越远，越好。浏览器层和应用程序层被阻止。这样，可以阻止80％+的请求。此方法只能阻止普通用户（但是99％的请求被阻止）。 ％的用户是普通用户）无法阻止组中的高端程序员。捕获数据包后，您将知道HTTP的样子。 JS不能阻止程序员为循环写作并调用HTTP接口。如何处理该请求的这一部分？

第二层，请求服务器级别的拦截

如何拦截？如何防止程序员为循环呼叫写作？是否有重复数据删除的基础？ ip？ -ID？ ...情况很复杂。这种业务需要登录，只需使用UID即可。在服务器级别，执行UID的请求计数和重复数据删除，并且无需统一存储计数并将其直接存储在服务器内存中（此计数将是不准确的，但最简单）。 UID只能在5秒内传递一个请求，这可以阻止循环请求的99％。

5S仅通过一个请求，另一个请求呢？缓存，页面缓存，相同的UID，限制访问频率，执行页面缓存以及在X秒内到达服务器的所有请求都将返回同一页面。对于同一项目的查询，例如火车号，执行页面缓存，并且在x秒内到达服务器的请求都将返回同一页面。这种当前的限制不仅可以确保用户具有良好的用户体验（返回404个），还可以确保系统的鲁棒性（使用页面缓存拦截服务器端的请求）。

页面缓存不一定确保所有服务器返回一致的页面。它也可以直接放置在每个站点的内存中。优势是简单性，但缺点是HTTP请求属于不同的服务器，并且返回的票务数据可能不同。这是服务器的请求拦截和缓存优化。

好吧，这种方法阻止了为循环写入HTTP请求的程序员。一些高端程序员（黑客）控制了100,000个肉鸡，并且手中有100,000个UID，并同时发送请求（撇开现实名称系统的问题，小米正在抓住手机，无需真正的名称系统） ，我现在该怎么办？服务器无法根据UID限制停止流量。

服务层的第三层用于拦截（无论如何，不​​要让请求落到数据库）

如何在服务层拦截？兄弟，我处于服务水平。我清楚地知道，小米只有10,000部手机。我知道火车只有2,000张门票。向数据库提出100,000请求的意义是什么？没错，请求队列！

对于写请求，创建一个请求队列，并且每次仅将有限的写入请求发送到数据层（下订单，支付此类书面业务）

10,000部手机，只有10,000个订单请求转到DB

3K火车票，只有3K订单请求转到DB

如果一切成功，将放下另一批。如果库存还不够，则所有队列中的所有写请求都将返回“售罄”。

如何优化阅读请求？电阻，无论是什么，或者，如果单台机器可以抵抗10W每秒10W，则应该没有问题。在当前的限制下，只有很少的写请求和很少的读取缓存错误会渗透到数据层，而99.9％的请求被阻止。

当然，业务规则也有一些优化。回想我们所做的事情，我们按时间和部分出售门票。他们曾经在10点钟出售门票，但现在他们在8点钟，8：30，9点钟出售门票...每半小时释放一批：均匀地分布流量。

其次，数据粒度的优化：当您购买门票时，剩余的门票查询业务，剩下58张门票或26张门票。你真的在乎吗？实际上，我们只关心门票还是没有门票？当交通繁忙时，只需制作一个粗粒的“票务”和“未售”的缓存。

第三，某些业务逻辑是异步的：例如，订单业务和付款业务的分离。这些优化都与业务结合使用。我以前曾分享过一种观点，即“与业务不同的所有建筑设计都是流氓。”体系结构的优化还必须针对业务。

好的，最后是数据库层

浏览器拦截80％，服务器拦截99.9％并缓存页面。该服务层还执行编写请求队列和数据缓存。数据库层的每个请求都是可控的。 DB基本上没有压力。您可以悠闲地漫步，并可以在一台机器上处理。同样，库存有限，小米的生产能力有限。向数据库提出这么多请求是没有意义的。

所有这些都传输到数据库，下达100万个订单，0成功，请求效率为0％。获得了3K数据，全部成功，请求效率为100％。

5。摘要

上面的描述应该非常清楚，没有什么可总结的。对于销售系统，我将从个人经验中重复两个体系结构优化的想法：

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

（2）常用的缓存，读取更多和写入更少的读数（缓存抵抗读取压力）；

浏览器和应用程序：速度限制

服务器端：基于UID和页面缓存的速度限制

服务层（Web服务器）：制作书面请求队列以根据业务控制流量，并进行数据缓存

数据层：在花园里漫步

和：根据业务进行优化

6。问答

问题1。根据您的体系结构，服务器实际上处于最大的压力下。假设实际和有效请求的数量为1000万，则不太可能限制请求连接的数量。那么如何处理这部分压力呢？

答：每秒并发可能不是1kW。假设有1kW，有两种解决方案：

（1）可以通过添加计算机来扩展服务层（Web服务器），最糟糕的是1K机器。

（2）如果没有足够的机器，请放弃请求并放弃50％（将直接退还50％，然后再试一次）。原则是保护系统，并且不允许所有用户失败。

问题2。“控制100,000个肉鸡，手头有100,000个UID，并同时发送请求。”如何解决这个问题？

答案：如上所述，服务层（Web服务器）编写请求队列控制

问题3：限制访问频率的缓存还可以用于搜索吗？例如，如果用户A搜索“手机”和用户B搜索“手机”，会首先使用A搜索生成的缓存页面吗？

答：这是可能的。此方法通常也经常用于“动态”操作活动页面，例如在短时间内将App-Push操作活动推向4kW用户并进行页面缓存。

问题4：如果队列处理失败，该怎么办？如果肉鸡爆破队列，该怎么办？

答：如果处理失败，则该订单将作为失败返回，用户可以重试。队列成本非常低，因此很难爆炸。在最坏的情况下，在缓存了几个请求后，随后的请求将直接返回“无票”（队列中已经有100万个请求，并且它们都在等待，因此接受任何请求再也没有意义了）

问题5：对于服务器端过滤，是否将UID请求的数量分开存储在每个站点的内存中？如果是这种情况，如何处理多个服务器群集通过负载平衡器将同一用户分配给其他服务器的响应的情况？还是我们应该在负载平衡之前将服务器端过滤放置？

答：可以将其放置在内存中。在这种情况下，似乎一台服务器仅限于5s中的一个请求。在全球范围内（假设有10台机器），实际上它仅限于5s中的10个请求。解决方案：

1）增加限制（这是推荐的解决方案，最简单）

2）在层上进行第7层平衡，以便尽可能多地要求使用UID

问题6：如果服务层（Web服务器）过滤器，是否由服务层（Web服务器）统一的队列？还是为每个服务器提供服务的队列？如果是统一的队列，是否有必要在将每个服务器提交的请求放入队列中之前执行锁定控件？

答：您不需要统一队列。在这种情况下，每个服务都可以传递少量请求（门票总数/服务数量）。这很简单。统一队列再次变得复杂。

问题7：付款后付款后完成后，占位符而在没有付款的情况下取消，如何及时控制和更新剩余的库存？

答：数据库中有一个状态，未付款。例如，如果时间超过45分钟，则库存将再次恢复（称为“返回仓库”）。我们获得门票的灵感是，开始闪光销售后，45分钟后重试，也许会再次有门票〜

问题8：不同的用户浏览相同的产品和在不同的缓存实例中显示的库存完全不同。您能告诉我如何使缓存数据保持一致或允许肮脏的读取吗？

答：借助当前的体系结构设计，请求可能落在不同的站点上，并且数据可能不一致（页面缓存不同）。这种业务方案是可以接受的。但是数据库级别的实际数据没问题。

问题9：即使企业考虑“ 3K火车票和向DB的3K订单请求”以进行优化，这些3K订单也不会引起拥塞吗？

答案：（1）数据库仍然可以承受3K写请求； （2）数据可以拆分； （3）如果无法维持3K，服务层（Web服务器）可以根据压力测试情况来控制并发请求的数量，而3K只是一个示例；

问题10：如果背景处理在服务器或服务层（Web服务器）上发生故障，我们是否需要考虑重播这批失败的请求？还是只是扔掉？

答：不要重播。如果查询失败或订单失败，请返回用户。建筑设计原则之一是“快速失败”。

问题11。

答：垂直分裂

问题12。想到另一个问题。这个过程是同步还是异步？如果对其进行同步，则应有缓慢的响应反馈。但是，如果它是异步的，那么如何控制响应结果是否可以返回正确的请求者？

答：用户级别绝对是同步的（用户的HTTP请求被抑制），并且服务层（Web服务器）可以同步或异步。

问题13。 问题：在哪个阶段应减少库存？如果您下订单锁定库存，如果大量恶意用户下订单以锁定库存而无需付款，该怎么办？

答：数据库级别的写请求量非常低，这是可以的。如果您不付款而下订单，则可以在时间过去后“返回位置”。如前所述。

提示：值得关注的事情

1。远离原始站点（用于闪存销售功能和购物中心服务器的服务器不应放在同一服务器上，以防止 Sale崩溃，并且购物中心无法访问...）

2.更多监视，仔细监视，找到一个人关注的人

销售的要点：

1。高可用性：双重活性

2。高并发：负载平衡，安全过滤

设计思想：

1。静态页面：CDN（使用主要制造商的现成的页面），URL隐藏，页面压缩，调节机制

2。动态页面：排队，异步，资格购买

其他建议：

1。的建议：缓存，CDN，较大的服务器实例

2。阿里巴巴的建议：云监测，云盾，ECS，OSS，RDS，CDN

使用CDN的想法：

1。将静态资源（图像，JS，CSS等）上传到CDN

2。缺点：但是请注意，在更新期间，CDN未在时间上更新，因此此时将被推出。

了解当前的环境和形式：

1。用户：大量普通/坏人（CDN加速也是一种转移，因为他们访问最近的CDN节点）

2.区域：全国各地（延迟1或2秒无效，因为1秒的延迟可能会在闪存中结束，并且需要CDN以允许用户选择最近的节点）

3。业务流程：前台的产品显示和注册。后端数据访问和数据处理

在销售前添加页面以转移流量并推广其他产品

产品显示层体系结构

页面的3个状态：

1。产品显示：倒计时页面

2。正在进行闪存销售：单击以输入闪存销售页面

3。闪存销售事件结束：提示该事件已经结束

新想法：从时间表方面考虑问题

假设我们看到的是闪存销售正在进行中，向前推进是倒计时，而向后推是终点。

下图从用户的角度看了问题：

代码：

静态资源存储在OSS中进行部署。

首先删除“倒计时”页面，然后立即将其复制到闪存销售页面。

然后定期执行此脚本

总结：

从倒计时到Rush Sale：它是使用计划的任务和脚本完成的

急于购买结束了，急于购买结束了：PHP会做到这一点，当桌子消失时，它将结束。

用户注册层体系结构

代码：

$。

数据访问层

代码：

如何计算从第2层到第3层的时间？ ？

第2层引起的总延迟将数据发送到第3层 +网络传输DNS分辨率和其他因素是多长时间？这样，我们可以评估需要配置的服务器数量。

总结2个句子：

1。如果您无法传递关键点，则将直接返回上一层（用户注册层）。

2。如果通过关键点，将通知其他层。

功效：类似于序列号的加密和解密

队列：使用的有序集合

上限：技术标记

数据处理层