万字好文，电商秒杀系统架构分析与实战.docxVIP

万字好文，电商秒宰系统架构分析与实战 首先要有一个呈现秒宰商品的页面，在这个页面上做一个秒宰活动开头的倒计时，?在预备阶段内用户会间续打开这个秒宰的页面， 并且可能不停的刷新页面。这里需要考虑两个问题： 第一个是秒宰页面的呈现 我们晓得一个html页面还是比较大的，即便做了压缩，http头和内容的大小也可能高达数十K，加上其他的css，js，图片等资源，假犹如时有几千万人参与一个商品的抢购，一般机房带宽也就只要1G10G，网络带宽就极有可能成为瓶颈，所以这个页面上各类静态资源首先应分开存放，然后放到cdn节点上分散压力，由于CDN节点遍及全国各地，能缓冲掉绝大部分的压力，而且还比机房带宽廉价 其次个是倒计时 出于功能缘由这个?一般由js调用客户端本地时间?，就有可能消灭客户端时钟与服务器时钟不全都，另外服务器之间也是有可能消灭时钟不全都。客户端与服务器时钟不全都可以接受客户端定时和服务器同步时间，这里考虑一下功能问题，用于同步时间的接口由于不涉及到后端规律，只需要将当前web服务器的时间发送给客户端就可以了，因而速度很快，就我以前测试的结果来看，一台标准的web服务器2W+QPS不会有问题，假如100W人同时刷，100WQPS也只需要50台web，一台硬件LB就可以了~，并且web服务器群是可以很简约的横向扩展的(LB+DNS轮询)，这个接口可以只前往一小段json格式的数据，而且可以优化一下削减不必要cookie和其他http头的信息，所以数据量不会很大，一般来说网络不会成为瓶颈，即便成为瓶颈也可以考虑多机房专线连通，加智能DNS的处理方案?；web服务器之间时间不同步可以接受统一时间服务器的方式，比如每隔1分钟全部参与秒宰活动的web服务器就与时间服务器做一次时间同步?。 扫瞄器层恳求拦截 （1）?产品层面?，用户点击“查询”或者“购票”后，按钮置灰，禁止用户反复提交恳求; （2）?JS层面?，限制用户在x秒之内只能提交一次恳求; 4.2 站点层设计 前端层的恳求拦截，只能拦住小白用户（不过这是99%的用户哟），高端的程序员根本不吃这一套，写个for循环，直接调用你后端的http恳求，怎样整？ （1）?同一个uid，限制访问频度?，做页面缓存，x秒内到达站点层的恳求，均前往同一页面 （2）?同一个item的查询，例如手机车次?，做页面缓存，x秒内到达站点层的恳求，均前往同一页面 如此限流，又有99%的流量会被拦截在站点层。 4.3 服务层设计 站点层的恳求拦截，只能拦住一般程序员，高级黑客，假设他把握了10w台肉鸡（并且假设买票不需要实名认证），这下uid的限制不行了吧？怎样整？ （1）大哥，我是服务层，我清楚的晓得小米只要1万部手机，我清楚的晓得一列火车只要2000张车票，我透10w个恳求去数据库有什么意义呢？对于写恳求，做恳求队列，每次只透过有限的写恳求去数据层，假如均成功再放下一批，假如库存不够则队列里的写恳求全部前往“已售完”?； （2）?对于读恳求，还用说么？cache来抗?，不管是memcached还是redis，单机抗个每秒10w应当都是没什么问题的； 如此限流，只要格外少的写恳求，和格外少的读缓存mis的恳求会透到数据层去，又有99.9%的恳求被拦住了。 用户恳求分发模块?：使用Nginx或Apache将用户的恳求分发到不同的机器上。 用户恳求预处理模块?：推断商品是不是还有剩余来打算是不是要处理该恳求。 用户恳求处理模块?：把通过预处理的恳求封装成事务提交给数据库，并前往能否成功。 数据库接口模块?：该模块是数据库的独一接口，担任与数据库交互，供应RPC接口供查询能否秒宰结束、剩余数量等信息。 用户恳求预处理模块 经过HTTP服务器的分发后，单个服务器的负载相对低了一些，但总量照旧可能很大，假如后台商品已经被秒宰完毕，那么直接给后来的恳求前往秒宰失败即可，不必再进一步发送事务了，示例代码可以如下所示： ????package?seckill;????import?org.apache.http.HttpRequest;????/**????????*?预处理阶段，把不必要的恳求直接驳回，必要的恳求添加到队列中进入下一阶段.????????*/????public?class?PreProcessor?{??????????//?商品能否还有剩余??????????private?static?boolean?reminds?=?true;??????????private?static?void?forbidden()?{??????????????//?Do?something.??????????}??????????public?static?boolean?