====
本文内容完全是作者自己的技术分析和总结。由于作者水平和能力有限，如有错误之处，敬请谅解并留言指正和评论。
Flash Kill 系统智能的背景
=========
我想大家都接触过流量巨大的平台和网站，比如新浪微博、淘宝、京东等。至于“高流量”和“高并发”，这是我们（技术开发人员）要做的。一个非常棘手的“行李”问题。看来，要想在这个行业立足，就必须创造自己的“高并发”，迎接挑战，即使你没有接触过高并发场景。因为只有这样我们才能走得更远。
Flash Kill系统智能概述
=========
今天给大家展示的内容是高并发最极端的场景之一。 “闪购”一词通常出现在“大促销”期间。当然，它也会出现在您在某些平台上的活动中。有的朋友可能会说，闪杀系统要注意哪些问题呢？为什么困难？
闪杀系统——特性分析
瞬时激增：流量在特定时刻开始流入（几乎没有预热或缓慢增长机制）。在闪购期间，大量用户会同时抢购相同的产品和网站。您的流量将立即飙升。
如果人数太多：产品供应有限。闪购请求的订单数量远远超过库存数量。只有少数人才能成功开展限时抢购。
锁定资源：闪购的业务流程相对简单，通常只是下订单以减少库存。库存是用户争夺的“资源”。实际消耗的资源不能超过计划销售的资源。换句话说，你不能“超卖”。
闪杀系统-难度分析
=========
难点在于完善“60-100点”闪杀系统。在这种情况下，至少必须考虑三个方面才被视为合格：这三个“魔鬼”分别称为“服务可用性”和“数据一致性”。 ”和“反应快”，有点“严厉”！
在目前的场景下，很难考虑非分布式的系统架构。 （分布式架构）CAP理论我想大家都知道吧！如果你不明白内容也没关系。
CAP理论又称CAP理论。它描述了服务（数据）层面的一致性、服务本身的可用性以及网络中不同节点的分区容忍度。分布式系统。
我认为任何人都可以理解A 和C。现在我想对一个陌生的P做出一个声明。这意味着，如果你希望即使网络出现问题，不同的节点仍然能够访问你的数据，最直接的方法是：冗余分配节点。否则，一切都将是空的。因此，作为一个分布式系统，我们可以理解为P是A和C的基础。
CAP 体系总结
它只是保证AC是一个单一的应用程序，根本不是分布式的。当然，这是在分布式系统出现之前构建系统的方式。如果这个系统中的任何一个节点出现故障，都不会出现脑裂，而是整个系统会直接宕机。
此外，网络中的节点越多，分区容错性就越高，但需要复制和更新的数据就越多，就越难确保一致性。
当更新所有节点上的数据以确保一致性需要时间时，可用性就会降低。
服务的可用性
服务可用性是指即使在内存、网络甚至硬件资源有限以及并发流量的影响下，服务仍保持可用的能力，使服务能够正常运行而不会造成停机或资源损坏。可以输出到外部。那样的话，你就不会输给“死”了。
数据的一致性
我们知道，当今大多数服务器，例如我们开发的程序或数据库，在处理数据时，可能会有多个线程同时从Java 修改同一行数据或同一部分内存。不一致的问题也会出现。从程序和中间件的角度来看也是如此；数据修改指令同时发生，数据被打乱，出现重复操作。数据有问题，结果与预期不一样。
这是最重要、最安全的方法，但也是最影响性能的方法，除非你能实现序列化并一一处理，这样就不会同时修改或操作任何数据。 （悲观锁、同步队列）。
另一种方法是始终在原子级别进行操作，即当最接近底层的计算机更改数据时，或者在所有节点之间的中间应用程序级别汇总主干点（例如Redis 或数据库主干点）。上面增加了写屏障和读屏障，在更改数据之前进行验证判断，如果数据与预期不同，则不会更改。这就是著名的乐观锁！
服务快速响应性
一般来说，这属于用户体验，一个比较好的闪购系统不应该让用户等待很长时间，最好能尽快提供反馈结果。要实现快速响应，不需要异步返回，直接快速响应。另外，你需要帮助用户计算数据并尽快直接返回。
闪购系统架构设计
=========
我们将闪购架构从外到内分为三个层次进行分析：应用层、服务层、数据访问层。
应用层架构设计
动静分离+CDN 技术
动静分离分析
场景分析：在闪购活动开始前，用户通常会尝试不断刷新浏览器页面（俗称F5），以避免错过闪购活动中的任何产品。
根据常用的网站应用架构：
如果这些浪费的请求经常通过Web服务器（LVS、Nginx等）、应用服务器（tomcat或Jetty等）、连接的数据库（MySQL）等影响您的后端服务器，您的用户肯定会期望这会有重大影响。关注问题它会给终端服务和服务器带来很大的负载。
解决方案：重新设计闪购产品页面，避免使用网站原有的产品详情页面，并将页面内容设为静态，以减少/分离通过后端服务的浪费请求。
CDN技术分析
增加网络带宽
如果您的网站静态页面数据大小为100K，则所需的网络和服务器带宽为2G（100K x 10000）。这些额外的网络带宽是由限时抢购活动增加的，超出了网站通常使用的带宽。
即使将动态业务转换为静态页面，闪购活动也会显着增加网络带宽消耗，并且不会降低前端网站服务器的负载。因此，如果可能的话，您应该缓存更多。除了前端Nginx 服务器级别之外，我们还需要临时从CDN 服务提供商处租用新的导出带宽，以便为我们的CDN 创建闪购产品页面。
阻止缓存页面
添加对页面的JavaScript文件引用（传递随机数+状态位），JavaScript文件
是否包含闪购开始标志？
闪购开始后，生成一个新的JavaScript 文件（文件名相同，但内容不同），将开始闪购标志更新为“是”，并添加订单页面URL 和随机数参数（此随机数即服务器端使用分布式缓存服务器（例如Redis），用于存储加载到用户浏览器上的随机数，以控制闪购商品的显示。
该JavaScript 文件可以使用随机版本号（例如xx.js?v=32353823）加载，以避免被浏览器、CDN 和反向代理服务器缓存。
此JavaScript 文件非常小，因此每次浏览器刷新时访问JavaScript 文件服务器不会给您的服务器集群或网络带宽带来很大的负载。
根据ID限制频率
为了控制公平原则，黄牛和一些黑客专家使用“高科技”，例如利用爬虫脚本操作疯狂更新页面。一旦超过每个人需要达到的频率阈值，使用相同的标准来控制访问频率信息的UID（用户ID），以防止破坏和公平分配某些需要这样做的人。在交互窗口中！
例如，您可以使用Redis 为每个用户创建访问统计信息，并根据用户身份和产品身份控制用户访问特定产品的频率。如果超过访问频率，用户的请求将被暂时阻止。
负荷分配
限时抢购系统应该是一个集群系统，在不升级硬件的情况下使用nginx进行负载均衡也是一个不错的选择。
负载均衡是集群技术的一种应用，可以将工作任务分配给多个处理单元，提高并发处理能力，帮助提高中大型网站的性能。您应该使用服务集群和水平扩展将“峰值”请求卸载到另一台服务器进行处理。
http协议负载均衡
它根据用户http请求的DNAT计算出真实的Web服务器地址，并将该Web服务器地址写入http重定向响应中返回给浏览器，然后浏览器再次访问它。这种方法比较简单，但性能较差。
DNS解析负载均衡
在DNS 服务器上配置多个域名的IP 记录。这种方式将负载均衡工作直接交给DNS，大大减少了网站管理和维护的工作量，提供更快的访问速度，有效提升性能。
反向代理负载均衡
反向代理服务器除了提供负载均衡功能外，还管理一组Web服务器，根据负载均衡算法将请求的浏览器访问定向到不同的Web服务器，并将处理结果返回给浏览器。反向服务器。
网络层IP负载均衡
网络层通过改变目标地址来进行负载均衡。此方法比反向服务器负载平衡提供更快的请求响应。但如果请求数据较大（大视频或大文件），响应速度会很慢。
MAC层负载均衡
数据链路层更改Mac地址以实现负载平衡。负载平衡服务器IP 与您管理的Web 服务组的虚拟IP 匹配。负载均衡服务器不需要进行地址转换，但是负载均衡服务器确实需要较高的网卡带宽。
硬件负载均衡
F5的正式名称为F5-BIG-IP-GTM，是一款硬件负载均衡设备，最多具有两个并发执行能力。该方式可以实现多链路负载均衡和冗余，允许您访问多条ISP链路，实现跨链路负载均衡和高可用性。
服务层架构设计
降速机制
无论您扩展多少应用程序服务、使用多少应用程序服务器以及部署多少负载均衡器，都会有无法支持大量请求的时候。
最后
服务层架构设计
降速机制
无论您扩展多少应用程序服务、使用多少应用程序服务器以及部署多少负载均衡器，都会有无法支持大量请求的时候。
最后
[外部链接图像正在传输.(img-w17zEvGN-1719178378985)]
[外部链接图像正在传输.(img-gyvEGLlq-1719178378986)]
[外部链接图像正在传输.(img-b6cxDXJM-1719178378986)]
#从完整的秒杀结构设计到“信息源网”的技术要点，以上有关“绝密档案”和“突发新闻”的信息仅供参考。相关信息请参见官方公告。信息！
原创文章，作者：CSDN，如若转载，请注明出处：https://www.sudun.com/ask/91883.html
