成业务节点2上的业务操作，并得到最终的处理结果。
[0081]进一步的，如图4所示，可设置会话同步节点40，会话同步节点40与反向代理节点10和业务节点20连接。反向代理节点获取与业务节点对应的会话信息的步骤为:
[0082]接收会话同步节点下发的会话信息，该会话信息由会话同步节点检测得到。
[0083]也就是说，业务节点20在处理接收到的业务请求时，会将该业务请求的会话状态通过长连接上传到会话同步节点40,会话同步节点40则可接收多个业务节点20上传的会话状态，并统计每个业务节点上传的会话状态的个数，然后下发给反向代理节点10，反向代理节点即可获知每个业务标识对应的业务节点上当前有多少个会话在并发处理以及是哪些终端建立的会话，对于会话并发数量较高的业务节点，则可降低其连接数限额；对于会话并发数量较低的业务节点，则可提高其连接数限额。
[0084]需要说明的是，业务节点在会话状态发生变化时，均会通过前述的长连接通知会话同步节点进行更新，从而保证会话同步节点下发给反向代理节点的会话信息为实时信肩、O
[0085]例如，如图6所示，图6展示了涉及会话同步节点的时序过程。业务节点在处理业务请求时均会通过长连接将相应的会话状态上传至会话同步节点。
[0086]会话同步节点也可通过脚本检测与业务节点对应的会话信息。例如，在一个应用场景中，可基于Node, js框架实现会话同步节点的功能,例如,可在业务节点返回的响应页面中包含基于Node, js框架的脚本，当用户的浏览器或手机应用加载该响应页面或关闭该加载该响应页面时，则均会触发该脚本，通知基于Node, js的会话同步节点，会话同步节点则可获知该用户终端的会话状态，经统计后，即可下发给反向代理节点。
[0087]进一步的，获取资源定位符对应的业务标识的步骤之后还包括:获取业务请求对应的会话状态，根据会话状态判断业务请求是否需要排队，若否，则将其转发给与业务标识对应的业务节点。
[0088]例如，若邮件业务对应一个业务节点，某个用户先发起了邮件查看的业务请求，经过阻塞队列排队后，被转发至邮件业务的业务节点进行处理，返回了包含该用户的邮件列表的响应页面，然后用户选中该邮件列表中的某个邮件，并在会话超时期内发起了相应的邮件删除的业务请求，则由于邮件查看的业务请求在转发到业务节点时，业务节点创建了与该用户的终端对应的会话，则在该会话没有被注销时，仍然将后续的邮件删除的业务请求转发至该业务节点。
[0089]也就是说，用户若通过排队进入了某个业务节点进行某个业务流程的处理，则在该用户在该业务节点上的会话的生命期内，该用户后续发起的与该业务节点对应的业务请求均不需要排队而直接被转发至该业务节点，从而保证了用户操作的连续性，不会在处理某个业务流程的中，每接收到一个响应页面就重新排队一次，从而提高了操作的便利性。
[0090]在一个应用场景中，如图7所示，图7展示了一次电子商务应用中抢购活动的业务流程的时序过程。该业务流程涉及的业务标识包括商品展示业务、用户信息查询业务、订单生成业务和支付业务。
[0091]其中，商品展示业务用于查询商品数据库的数据，并展示包含商品的图片、数量、价格的页面，用户可点击商品展示页面上与商品对应的购买链接进入购物车进行订单生成业务的操作；用户信息查询业务的用于查询用户的身份，从而展示或添加与用户身份相关的信息(例如会员打折等信息)；订单生成业务用于生成具体的交易订单，即通过购物车页面生成最终交易订单；支付业务则用于电子商务支付。
[0092]本应用场景中各个业务节点的交互过程则可具体为:
[0093]反向代理节点接收终端发起的业务请求，提取业务请求的资源定位符；获取资源定位符对应的业务标识，获取与业务标识对应的连接数及连接数限额；判断连接数是否小于所述连接数限额，若是，则将业务请求转发给与业务标识对应的业务节点，且业务标识包括商品展示业务、用户信息查询业务、订单生成业务和支付业务。
[0094]业务节点接收转发的业务请求，对其进行处理，生成相应的响应页面，并通过所述反向代理节点将所述响应数据返回给终端，且响应页面包含与业务标识对应的链接地址。
[0095]终端检测响应页面上与所述链接地址对应的触发指令(例如用户点击了响应页面中包含的链接地址)，生成相应的业务请求，并将其发送给反向代理节点。
[0096]需要说明的时，用户在某个业务节点上进行业务操作时，发起的业务请求不限于图7中所示的一次，且用户在实际网上购物过程中的操作过程也不限于图7中所示的时序过程。例如，用户将某个商品添加到购物车之后可返回商品展示页并继续向购物车中添加商品并进行购买，而不用进入支付后再重新购买。
[0097]如图8所示，用户在分别进行进入商店首页、登录账号、生成订单和在线支付之前均需要进行排队，但通常情况下，抢购系统的瓶颈在于支付业务上(支付业务通常涉及外部业务接口，例如，网银接口或第三方支付接口的调用，通常有并发限制)，采用上述方案可使得在支付业务存在瓶颈的情况下，用户可先经过较短时间的排队然后进入购物车，选好其希望购买的商品生成订单，然后再进行排队等待剩余的支付环节。而传统技术的排队系统中，用户排队进入抢购页面后，还需要先登录，再选择商品，然后生成订单，再完成支付，需要耗费较多的时间。而排队中的用户则需要等待该用户完成上述全部操作后才能进入系统。因此采用本方法的电商抢购系统，可使业务流程中某个环节的瓶颈不会影响到该业务流程中用户在其他环节的操作，从而提高了执行效率。
[0098]在一个实施例中，如图9所示，可将反向代理节点、业务节点和会话同步节点部署在不同的域名之下(如图9中的A为反向代理节点的域名，B和C为业务节点的域名，D为基于Node, js的会话同步节点)，在进入商店之前的流量控制页(统称为商店加载页，对应商店首页加载业务)也可部署接入到A域名下，A和B向D发起长连接请求，B向D发起状态更新请求以实现实时采集玩家流量，B和C前后台系统间的信息交互以实现玩家的商品购买交易，C也接入到A的流量限制系统中以保护整个交易过程系统可用，D向A动态调整流量限制配置以实现实时调整A和C的流量限制策略。
[0099]在本实施例对应的应用场景中，如图10所示，以腾讯游戏微商店的一次抢购活动为例，详细阐述该实时主动调整流量的抢购系统的工作流程:
[0100]在抢购活动开始的时刻，海量玩家进入商店的时候，为了保护整个抢购活动中的服务器不会被挤宕机，限流步骤如下所示:
[0101]1.进入加载商店页限流。所有玩家由系统引导进入A域名，通过流量限制的玩家进入B域名，即商店首页；否则玩家进入排队等待状态。
[0102]2.进入商店首页限流。在进入商店首页后，系统在C域名下查询玩家信息，通过流量限制的玩家返回玩家信息并进入商品选择页；否则玩家进入排队等待状态。
[0103]3.下订单限流。玩家选择好物品下订单的时候，通过流量限制的玩家成功下订单；否则玩家进入排队等待状态。
[0104]4.支付限流。成功下完订单的玩家在进行支付的时候，通过流量限制的玩家成功支付并完成物品发货，否则玩家进入排队等待状态。
[0105]如图11所示，在加载商店页限流和商店首页限流环节进行排队的用户可收到商店爆满的提示信息，并可通过点击“再挤挤”重新申请进入。如图12所示，在下订单限流环节进行排队的用户则可收到其在队列中具体的位置。
[0106]在以上限流步骤中，玩家在来到商店的时候，域名A都会向域名D发起一个长连接，然后在玩家每进入到下一个业务环节，域名B都会向域名D更新一次玩家状态，以实时统计每个限流步骤中的玩家数量和玩家状态。因此，根据当前抢购系统的总容量，反向代理节点即可以根据当前系统以上4个步骤中的玩家数量的比例来动态配置每一步的限流阀值，从而完成实时主动调整用户排队的体验。
[0107]在一个实施例中，如图13所示，一种处理业务请求的装置，包括请求接收模块102、