CN104636957A - 一种处理高并发数据请求的系统和方法 - Google Patents

Abstract

本发明属于电子商务技术领域，具体为一种处理高并发数据请求的系统和方法。本发明系统主体分为3个部分：负载均衡层、仲裁应用单元、商品扣减处理单元；负载均衡层用于将大量的客户请求平均分配给后端的仲裁应用，仲裁应用单元接收来自负载均衡层分发来的用户请求，对其进行资格判定，并将用户请求合并重组后发送到商品扣减处理单元进行商品的扣减处理；商品扣减处理单元，用于接收来自仲裁应用的商品的扣减请求，对秒杀商品进行库存数量扣减。本发明使用单线程、批量处理的方式，避免了多线程高并发给数据库系统带来的瓶颈，同时保留了强大的业务处理能力，系统资源的开销也减少到尽可能低的程度。

Description

一种处理高并发数据请求的系统和方法

技术领域

本发明属于电子商务技术领域，具体涉及一种处理高并发数据请求的系统和方法。

背景技术

秒杀业务具有商品种类少，短时间访问量巨大的特点，而且用户对于秒杀系统的响应时间有着相当严苛的要求。传统的电商体系架构只能通过增加应用服务器这种横向扩展的方式来满足巨大的用户访问量，但是由于需要扣减的商品种类单一，过大的秒杀并发请求会对数据库的个别商品记录上产生大量操作锁，从而在数据库产生严重的瓶颈，大大降低了用户的秒杀响应时间，甚至造成系统短时间瘫痪。

发明内容

本发明的目的在于提供一种有别于传统电商解决方案的处理高并发数据请求的系统和方法，在保留横向扩展服务器能力的基础上，最大限度减少在商品扣减的时候高并发对数据库带来的瓶颈，以满足用户严苛的响应要求。

 本发明在一次处理中，将多个相同的商品扣减请求合并成一个请求，再进行商品的扣减操作，然后根据实际扣减的商品数量按照先到先得的原则，标记每个请求是否成功扣减了对应数量的商品。

本发明提供的处理高并发数据请求的系统，其主体分为3个部分：负载均衡层、仲裁应用单元、商品扣减处理单元，系统结构如图3所示，其中：

负载均衡层，用于将大量的客户请求平均分配给后端的仲裁应用，并通过监控每个仲裁应用的访问流量，将用户请求分配到流量较少的仲裁应用上实现负载均衡。

仲裁应用单元，至少包含一个仲裁应用，仲裁应用由两部分组成：一个Web线程组和一个独立运行的仲裁线程；仲裁应用单元接收来自负载均衡层分发来的用户请求，对其进行资格判定，并将用户请求合并重组后发送到商品扣减处理单元进行商品的扣减处理。

仲裁应用单元中，Web线程组用来接收用户请求，对用户请求进行资格判定，然后将用户请求按照先后顺序存放到请求存储单元中的一个队列中；仲裁线程是一个单独运行的线程，每当用于存放用户请求的请求存储单元队列满的时候或者距离上次仲裁时间间隔达到一个最大值的时候，该线程便执行一次仲裁过程，它将当前请求存储单元队列中的所有请求的商品数量进行加合，重组成一个商品扣减请求发送给商品扣减处理单元，进行商品的扣减操作。

仲裁应用可以横向扩展，通过增加所述应用数量的方式增加系统可接收的最大用户请求数量。

商品扣减处理单元，由一个用来接收扣减请求的Web线程组和一个用来执行批量商品扣减的独立后台线程组成，用于接收来自仲裁应用的商品的扣减请求，对秒杀商品进行库存数量扣减。

商品扣减处理单元中，Web线程组接收从仲裁线程发出的商品扣减请求，将其按照先后顺序存放在请求存储单元队列中，并从这个队列中接收实际扣减结果。独立后台线程在队列已满或者距离上次处理时间间隔达到最大时间后，对请求存储单元中的商品扣减请求做一次批量处理，独立后台线程会把相同商品的扣减数量进行合并，向数据库发起一次商品扣减操作请求，独立后台线程根据实际扣减的商品数量按照先后顺序分配到每个扣减请求中。

处理高并发数据请求的系统还包括：数据库、请求存储单元、监控单元，其中：

数据库，主要用于存储商品信息。所述商品信息包括名称，库存量等。

请求存储单元，主要用于存储用户申请请求和商品扣减请求，采用队列的组织形式按照先后顺序进行存储。

监控单元，主要用于监控仲裁应用的仲裁线程和请求线程以及商品扣减处理单元的独立后台线程和请求线程的睡眠时间，一旦所述睡眠时间超过预先定义的阀值，则监控单元唤醒相关线程执行相应的操作。

本发明还涉及基于上述系统的处理高并发数据请求方法，其流程如图2 所示，具体步骤如下：

步骤101：仲裁应用接收到负载均衡层分发过来的用户请求后，从Web线程组中挑选一个空闲的线程执行操作，下称请求线程1，该线程查找请求存储单元中保留的商品库存标志位，根据标志位数值确定用户请求是否成功，若用户请求成功执行步骤102。

步骤102：请求线程1将用户请求存放到请求存储单元的请求队列中，仲裁应用启动的时候创建一个仲裁线程，该仲裁线程一直处于睡眠状态；当睡眠时间超过一个最大时间间隔后仲裁线程会被监控单元唤醒，或者当请求存储单元请求队列中存放的用户请求达到最大值后会被用户请求线程1唤醒；唤醒后的仲裁线程将当前请求队列中的所有商品扣减请求合并成一个扣减请求；经过合并重组后的商品扣减请求会由仲裁线程发送给后端的商品扣减处理单元进行商品的扣减操作。

步骤103：仲裁应用获得商品扣减处理单元返回的实际扣减结果后，仲裁线程根据这个实际扣减结果按照时间先后顺序标记请求队列中每个用户请求是否成功执行；至此完成一次仲裁操作，仲裁线程唤醒所有正在等待商品扣减结果的用户申请线程，然后重新进入睡眠状态等待下一次被唤醒。

步骤104：请求线程1进入睡眠状态，该睡眠状态会设定一个超时时间，一旦到指定时间该线程仍然没有被仲裁线程唤醒的话，该线程会被监控单元自动唤醒。

步骤105：处于睡眠状态的请求线程1在规定的时间内没有被仲裁线程唤醒，则会被监控单元自动唤醒执行用户请求超时提醒操作。

步骤106：处于睡眠状态的请求线程1被仲裁线程唤醒后，根据用户请求中记录的购买结果执行用户是否购买成功操作。

本发明使用单线程，批量处理的方式，避免了多线程高并发给数据库系统带来的瓶颈，同时保留了强大的业务处理能力，系统资源的开销也减少到尽可能低的程度。

附图说明

图1 为本发明的系统结构图。

图2 为用户请求的处理流程图。

图3 为仲裁应用后台线程的处理流程图。

图4 为商品扣减的处理流程图。

具体实施方式

本发明提供了一种有别于传统电商解决方案的处理高并发数据请求的方法和系统，在保留横向扩展服务器能力的基础上，最大限度减少在商品扣减的时候高并发对数据库带来的瓶颈，以满足用户严苛的响应要求。

图1 为本发明的系统结构图，整个系统由3个部分组成：

负载均衡层，主要功能负责将大量的客户请求平均分配给后端的仲裁应用。可采用Ngnix技术实现，Ngnix是一个高性能的http，其特点是占用请求存储单元少，性能稳定，并发能力强，是在绝大多数Linux/Unix系统上使用的高性能Web服务器。通过其提供的反向代理功能，可以为应用实现简单的负载均衡。

负载均衡层通过为Ngnix配置jvmroute模块，从而实现多个仲裁应用的负载均衡。jvmroute模块是Ngnix上用于搭建负载均衡的模块，它通过监控每个仲裁应用的访问流量，将用户请求分配到流量较少的仲裁应用上，以此达到负载均衡的目的。

仲裁应用单元，至少包含一个仲裁应用，所述仲裁应用单元接收来自负载均衡层分发来的用户请求，对其进行资格判定(例如：通过秒杀验证码)，并将用户请求合并重组后发送到商品扣减处理单元进行商品的扣减处理。

仲裁应用由两部分组成：一个Web线程组和一个独立运行的仲裁线程。Web线程组用来接收用户请求，对用户请求进行资格判定，然后将用户请求按照先后顺序存放到请求存储单元中的一个队列中。仲裁线程是一个单独运行的线程，它在整个仲裁应用启动的时候便创建完成。每当用于存放用户请求的请求存储单元队列满的时候或者距离上次仲裁时间间隔达到一个最大值的时候，该线程便执行一次仲裁过程，它会将当前请求存储单元队列中的所有请求的商品数量进行加合，重组成一个商品扣减请求发送给商品扣减处理单元，进行商品的扣减操作。

仲裁应用可以横向扩展，通过增加所述应用数量的方式增加系统可接收的最大用户请求数量。

商品扣减处理单元，接收来自仲裁应用的商品的扣减请求，对秒杀商品进行库存数量扣减。商品扣减处理单元由一个用来接收扣减请求的Web线程组和一个用来执行批量商品扣减的独立后台线程组成。Web线程组接收从仲裁线程发出的商品扣减请求，将其按照先后顺序存放在请求存储单元队列中，并从这个队列中接收实际扣减结果。独立后台线程在队列已满或者距离上次处理时间间隔达到最大时间后，对请求存储单元中的商品扣减请求做一次批量处理，独立后台线程会把相同商品的扣减数量进行合并，向数据库发起一次商品扣减操作请求，独立后台线程根据实际扣减的商品数量按照先后顺序分配到每个扣减请求中。

此外，系统还包括：

数据库，主要用于存储商品信息。所述商品信息包括名称，库存量等。

请求存储单元，主要用于存储用户申请请求和商品扣减请求，采用队列的组织形式按照先后顺序进行存储。

监控单元，主要用于监控仲裁应用的仲裁线程和请求线程以及商品扣减处理单元的独立后台线程和请求线程的睡眠时间，一旦所述睡眠时间超过预先定义的阀值，监控单元便会唤醒相关线程执行相应的操作。

图2 为用户请求的处理流程图，具体步骤为：

步骤101：仲裁应用接收到负载均衡层分发过来的用户请求后，会从Web线程组中挑选一个空闲的线程执行操作（下称请求线程1），该线程查找请求存储单元中保留的商品库存标志位，如果标志位为0，则返回用户“活动结束，商品已经秒完”，否则执行步骤102。

步骤102：请求线程1将用户请求存放到请求队列中，并执行步骤103。请求队列是一个请求存储单元数据结构，按照先后顺序存储用户信息，商品信息，购买数量以及购买结果，执行步骤103。

仲裁应用启动的时候创建一个仲裁线程，该仲裁线程会一直处于睡眠状态。当睡眠时间超过一个最大时间间隔后仲裁线程会被监控单元唤醒；或者当请求存储单元用户队列中存放的用户请求达到最大值后会被用户请求线程1唤醒。唤醒后的仲裁线程将当前请求队列中的所有商品扣减请求合并成一个扣减请求，例如请求队列中按照时间先后顺序依次存放：[用户1，商品1，数量1]，[用户2，商品1，数量1]，[用户3，商品1，数量1]，合并成请求[商品1，数量3]。经过合并重组后的商品扣减请求会由仲裁线程发送给后端的商品扣减处理单元进行商品的扣减操作。

仲裁应用获得商品扣减处理单元返回的实际扣减结果后，仲裁线程根据这个实际扣减结果按照时间先后顺序标记请求队列中每个用户请求是否成功执行。例如，商品扣减处理单元返回实际扣减2个商品，则上述3个用户请求的最终结果如下 ：[用户1，商品1，数量1，成功]，[用户2，商品1，数量1，成功]，[用户3，商品1，数量1，失败]，至此完成一次仲裁操作，仲裁线程唤醒所有正在等待商品扣减结果的用户申请线程，然后重新进入睡眠状态等待下一次被唤醒。

步骤103：请求线程1进入睡眠状态，该睡眠状态会设定一个超时时间，一旦到指定时间该线程仍然没有被仲裁线程唤醒的话，该线程会被监控单元自动唤醒。

步骤104：处于睡眠状态的请求线程1在规定的时间内（例如3秒）没有被仲裁线程唤醒，则会被监控单元自动唤醒，并返回用户“操作超时”。

步骤105：处于睡眠状态的请求线程1被仲裁线程唤醒后，根据用户请求中记录的购买结果，返回用户是否购买成功。

图3 为仲裁应用后台线程的处理流程图，具体步骤为：

步骤201：请求线程1在向申请队列存放用户申请的时候，会检查申请队列是否已满，如果队列已满，则请求线程1会唤醒仲裁线程准备执行一次仲裁操作；如果仲裁线程一直处于睡眠状态，监控单元会在最大时间间隔到达的时候将其唤醒执行一次仲裁操作。仲裁操作从步骤202开始执行。

步骤202：仲裁线程遍历当前的请求队列，将所有的请求的扣减数量进行加和生成一个商品扣减的请求。执行步骤203。

步骤203：仲裁线程将合并后的商品扣减请求提交给商品扣减处理单元，获得返回的实际扣减数量。

步骤204：仲裁线程根据实际扣减数量，按照先到先得的原则，标记请求队列中每个请求的成功标志位。执行步骤205。

步骤205：仲裁线程唤醒所有正在等待商品扣减结果的用户请求线程1。

步骤206：仲裁线程判断实际扣减数量是否小于请求数量，如果是则执行步骤207。

步骤207：仲裁线程将请求存储单元中的商品库存标志位置为0。

图4 为本发明商品扣减处理单元的工作流程图，具体步骤为：

步骤301：商品扣减处理单元在接收到从仲裁线程发送过来的商品扣减请求后，从Web线程组中挑选一个空闲的线程（下称请求线程2）。请求线程2将商品的扣减请求按照先后顺序存放进请求存储单元队列中，并执行步骤302。

步骤302：请求线程2进入睡眠状态，等待后台线程将其唤醒。

商品扣减处理单元和仲裁应用类似，设立了一个独立的后台线程，用来批量处理商品的扣减请求。

步骤401：后台线程通常是处于等待状态，请求线程2在存放扣减请求的时候，检查队列是否已满，如果队列已满则请求线程2唤醒后台线程；如果后台线程睡眠时间达到最大出力时间间隔仍然没有被唤醒，则操作系统会唤醒后台线程。后台线程被唤醒后执行步骤402。

步骤402：后台线程对扣减请求队列中的所有请求进行商品数量加和，获得需要扣减的商品总数量A1，执行步骤403。

步骤403：后台线程从商品库中查询获得商品当前库存值A2，执行步骤404。

步骤404：后台线程比较A1和A2，选择两者中较小的那个最为最终商品扣减的数量A，进行商品扣减操作。

步骤405：后台线程根据实际扣减的商品数量A，登记扣减请求队列中每笔扣减请求实际成功扣减的商品数量，并唤醒所有睡眠的请求线程2。处理完成后，后台线程进入睡眠状态，等待再次执行步骤401。

步骤303：请求线程2被唤醒后，返回实际扣减的商品数量，流程结束。

Claims (7)

1. 一种处理高并发数据请求的系统，其特征在于主体分为3个部分：负载均衡层、仲裁应用单元、商品扣减处理单元，其中：

所述负载均衡层，用于将大量的客户请求平均分配给后端的仲裁应用，并通过监控每个仲裁应用的访问流量，将用户请求分配到流量较少的仲裁应用上实现负载均衡；

所述仲裁应用单元，至少包含一个仲裁应用，仲裁应用由两部分组成：一个Web线程组和一个独立运行的仲裁线程；仲裁应用单元接收来自负载均衡层分发来的用户请求，对其进行资格判定，并将用户请求合并重组后发送到商品扣减处理单元进行商品的扣减处理；

仲裁应用可以横向扩展，即通过增加所述应用数量的方式增加系统可接收的最大用户请求数量；

所述商品扣减处理单元，由一个用来接收扣减请求的Web线程组和一个用来执行批量商品扣减的独立后台线程组成；主要用于接收来自仲裁应用的商品的扣减请求，对秒杀商品进行库存数量扣减。

2. 根据权利要求1所述的处理高并发数据请求的系统，其特征在于还包括数据库，所述数据库主要用于存储商品信息。

3. 根据权利要求1所述的处理高并发数据请求的系统，其特征在于还包括监控单元，所述监控单元主要用于监控仲裁应用的仲裁线程和请求线程以及商品扣减处理单元的独立后台线程和请求线程的睡眠时间，一旦所述睡眠时间超过预先定义的阀值，则监控单元唤醒相关线程执行相应的操作。

4. 根据权利要求1所述的处理高并发数据请求的系统，其特征在于还包括请求存储单元，所述请求存储单元，主要用于存储用户申请请求和商品扣减请求，采用队列的组织形式按照先后顺序进行存储。

5. 根据权利要求2所述的处理高并发数据请求的系统，其特征在于所述仲裁应用中，Web线程组用来接收用户请求，对用户请求进行资格判定，然后将用户请求按照先后顺序存放到请求存储单元中的一个队列中；仲裁线程是一个单独运行的线程，每当用于存放用户请求的请求存储单元队列满的时候或者距离上次仲裁时间间隔达到一个最大值的时候，该线程便执行一次仲裁过程，它将当前请求存储单元队列中的所有请求的商品数量进行加合，重组成一个商品扣减请求发送给商品扣减处理单元，进行商品的扣减操作。

6. 根据权利要求2或3所述的处理高并发数据请求的系统，其特征在于所述商品扣减处理单元中，Web线程组接收从仲裁线程发出的商品扣减请求，将其按照先后顺序存放在请求存储单元队列中，并从这个队列中接收实际扣减结果；独立后台线程在队列已满或者距离上次处理时间间隔达到最大时间后，对请求存储单元中的商品扣减请求做一次批量处理，独立后台线程会把相同商品的扣减数量进行合并，向数据库发起一次商品扣减操作请求，独立后台线程根据实际扣减的商品数量按照先后顺序分配到每个扣减请求中。

7. 一种基于如权利要求1-4所述系统的处理高并发数据请求方法，其特征在于具体步骤如下：

步骤101：仲裁应用接收到负载均衡层分发过来的用户请求后，从Web线程组中挑选一个空闲的线程执行操作，下称请求线程1，该线程查找请求存储单元中保留的商品库存标志位，根据标志位数值确定用户请求是否成功，若用户请求成功执行步骤102；

步骤102：请求线程1将用户请求存放到请求存储单元的请求队列中，仲裁应用启动的时候创建一个仲裁线程，该仲裁线程一直处于睡眠状态；当睡眠时间超过一个最大时间间隔后仲裁线程会被监控单元唤醒，或者当请求存储单元请求队列中存放的用户请求达到最大值后会被用户请求线程1唤醒；唤醒后的仲裁线程将当前请求队列中的所有商品扣减请求合并成一个扣减请求；经过合并重组后的商品扣减请求会由仲裁线程发送给后端的商品扣减处理单元进行商品的扣减操作；

步骤103：仲裁应用获得商品扣减处理单元返回的实际扣减结果后，仲裁线程根据这个实际扣减结果按照时间先后顺序标记请求队列中每个用户请求是否成功执行；至此完成一次仲裁操作，仲裁线程唤醒所有正在等待商品扣减结果的用户申请线程，然后重新进入睡眠状态等待下一次被唤醒；

步骤104：请求线程1进入睡眠状态，该睡眠状态会设定一个超时时间，一旦到指定时间该线程仍然没有被仲裁线程唤醒的话，该线程会被监控单元自动唤醒；

步骤105：处于睡眠状态的请求线程1在规定的时间内没有被仲裁线程唤醒，则会被监控单元自动唤醒执行用户请求超时提醒操作；

步骤106：处于睡眠状态的请求线程1被仲裁线程唤醒后，根据用户请求中记录的购买结果执行用户是否购买成功操作。