秒杀架构设计.docxVIP

秒宰架构设计 最近在部门内部共享了原来在电商业务做秒宰活动的全体思路，大家对这次共享反馈还不错，所以我就简约整理了一下，共享给大家参考参考 业务引见 什么是秒宰？通俗一点讲就是网络商家为促销等目的组织的网上限时抢购活动 比如说京东秒宰，就是一种定时定量秒宰，在规定的时间内，无论商品能否秒宰完毕，该场次的秒宰活动都会结束。这种秒宰，对时间不是特殊严格，只需下手快点，秒中的概率还是比较大的。 淘宝以前就做过一元抢购，一般都是限量 1 件商品，同时价格低到「令人发齿」，这种秒宰一般都在开头时间 1 到 3 秒内就已经抢光了，参与这个秒宰一般都是看运气的，不必太强求 业务特点 瞬时并发量大 秒宰时会有大量用户在同一时间进行抢购，瞬时并发访问量突增 10 倍，甚至 100 倍以上都有。 库存量少 一般秒宰活动商品量很少，这就导致了只要极少量用户能成功购买到。 业务简约 流程比较简约，一般都是下订单、扣库存、领取订单 技术难点 现有业务的冲击 秒宰是营销活动中的一种，假如和其他营销活动应用部署在同一服务器上，确定会对现有其他活动形成冲击，极端情况下可能导致整个电商系统服务宕机 直接下订单 下单页面是一个正常的 URL 地址，需要把握在秒宰开头前，不能下订单，只能扫瞄对应活动商品的信息。简约来说，需要 Disable 订单按钮 页面流量突增 秒宰活动开头前后，会有很多用户恳求对应商品页面，会形成后台服务器的流量突增，同时对应的网络带宽添加，需要把握商品页面的流量不会对后台服务器、DB、Redis 等组件的形成过大的压力 架构设计思想 限流 由于活动库存量一般都是很少，对应的只要少部分用户才能秒宰成功。所以我们需要限制大部分用户流量，只准少量用户流量进入后端服务器 削峰 秒宰开头的那一霎时，会有大量用户冲击进来，所以在开头时候会有一个霎时流量峰值。如何把霎时的流量峰值变得更平缓，是能否成功设计好秒宰系统的关键因素。实现流量削峰填谷，一般的接受缓存和 MQ 两头件来处理 异步 秒宰其实可以当做高并发系统来处理，在这个时候，可以考虑从业务上做兼容，将同步的业务，设计成异步处理的任务，提高网站的全体可用性 缓存 秒宰系统的瓶颈次要体现在下订单、扣减库存流程中。在这些流程中次要用到 OLTP 的数据库，类似 MySQL、SQLServer、Oracle。由于数据库底层接受 B+ 树的储存结构，对应我们随机写入与读取的效率，相对较低。假如我们把部分业务规律迁移到内存的缓存或者 Redis 中，会极大的提高并发效率 全体架构 客户端优化 客户端优化次要有两个问题 秒宰页面 秒宰活动开头前，其实就有很多用户访问该页面了。假如这个页面的一些资源，比如 CSS、JS、图片、商品详情等，都访问后端服务器，甚至 DB 的话，服务确定会消灭不行用的情况。所以一般我们会把这个页面全体进行静态化，并将页面静态化之后的页面分发到 CDN 边缘节点上，起到压力分散的作用 防止提前下单 防止提前下单次要是在静态化页面中加入一个 JS 文件引用，该 JS 文件包含活动能否开头的标记以及开头时的动态下单页面的 URL 参数。同时，这个 JS 文件是不会被 CDN 系统缓存的，会一直恳求后端服务的，所以这个 JS 文件肯定要很小。当活动快开头的时候（比如提前），通过后台接口修改这个 JS 文件使之生效 API 接入层优化 客户端优化，对于不是搞计算机方面的用户还是可以防止住的。但是稍有肯定网络基础的用户就起不到作用了，因而服务端也需要加些对应把握，不能信任客户端的任何操作。一般把握分为 2 大类 限制用户维度访问频率 针对同一个用户（ Userid 维度），做页面级别缓存，单元时间内的恳求，统一走缓存，前往同一个页面 限制商品维度访问频率 大量恳求同时间段查询同一个商品时，可以做页面级别缓存，不管下回是谁来访问，只需是这个页面就直接前往 SOA 服务层优化 上面两层只能限制特别用户访问，假如秒宰活动运营的比较好，很多用户都参与了，就会形成系统压力过大甚至宕机，因而需要后端流量把握 对于后端系统的把握可以通过消息队列、异步处理、提高并发等方式处理。对于超过系统水位线的恳求，直接实行 「Fail-Fast」准绳，拒绝掉 秒宰全体流程图 秒宰系统核心在于层层过滤，渐渐递减瞬时访问压力，削减最终对数据库的冲击。通过上面流程图就会发觉压力最大的地方在哪里？ MQ 排队服务，只需 MQ 排队服务顶住，后面下订单与扣减库存的压力都是本人能把握的，依据数据库的压力，可以定制化创建订单消费者的数量，避开消灭消费者数据量过多，导致数据库压力过大或者直接宕机。 库存服务特地为秒宰的商品供应库存管理，实现提前锁定库存，避开超卖的现象。同时，通过超时处理任务发觉已抢到商品，但未付款的订单，并在规定付款时间后