每秒100W请求，架构如何优化？

秒杀业务，可以使用典型的服务化分层架构：

• 端(浏览器/APP)，最上层，面向用户
• 站点层，访问后端数据，拼装html/json返回
• 服务层，屏蔽底层数据细节，提供数据访问
• 数据层，DB存储库存，当然也有缓存

这四层分别应该如何优化呢?

一、端上的请求拦截(浏览器/APP)

想必春节大家都玩过微信的摇一摇抢红包，用户每摇一次，真的就会往后端发送一次请求么?

回顾抢票的场景，用户点击“查询”按钮之后，系统卡顿，用户着急，会不自觉的再去频繁点击“查询”，不但没用，反而平白无故增加系统负载，平均一个用户点5次，80%的请求是这么多出来的。

JS层面，可以限制用户在x秒之内只能提交一次请求，从而降低系统负载。

画外音：频繁提交，可以友好提示“频率过快”。

APP层面，可以做类似的事情，虽然用户疯狂的在摇微信抢红包，但其实x秒才向后端发起一次请求。

画外音：这就是所谓的“将请求尽量拦截在系统上游”，浏览器/APP层就能拦截80%+的请求。

不过，端上的拦截只能挡住普通用户(99%的用户是普通用户)，程序员firebug一抓包，写个for循环直接调用后端http接口，js拦截根本不起作用，这下怎么办?

二、站点层的请求拦截

如何抗住程序员写for循环调用http接口，首先要确定用户的唯一标识，对于频繁访问的用户予以拦截。

用什么来做用户的唯一标识?

ip?cookie-id?别想得太复杂，购票类业务都需要登录，用uid就能标识用户。

在站点层，对同一个uid的请求进行计数和限速，例如：一个uid，5秒只准透过1个请求，这样又能拦住99%的for循环请求。

一个uid，5s只透过一个请求，其余的请求怎么办?

缓存，页面缓存，5秒内到达站点层的其他请求，均返回上次返回的页面。

画外音：车次查询和余票查询都能够这么做，既能保证用户体验(至少没有返回404页面)，又能保证系统的健壮性(利用页面缓存，把请求拦截在站点层了)。

OK，通过计数、限速、页面缓存拦住了99%的普通程序员，但仍有些高端程序员，例如黑客，控制了10w个肉鸡，手里有10w个uid，同时发请求，这下怎么办?

（编辑：平顶山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!