CN107464151A - 高并发业务的订单数据处理方法及装置 - Google Patents

Abstract

本申请公开了一种高并发业务的订单数据处理方法及装置。该方法包括：接收订单数据处理请求；根据预设的切流策略，确定将所述订单数据处理请求提交到第一订单处理单元或者第二订单处理单元进行处理；以及当所述订单数据处理请求被提交到所述第二订单处理单元进行处理时，根据发送所述订单数据处理请求的用户类型，将所述订单数据处理请求路由到不同数据库子系统中。该方法可以确保在数据库架构升级过程中业务服务不停机，提升了用户的满意度。此外，可有效提升订单的处理量及并发订单处理量。

Description

高并发业务的订单数据处理方法及装置

技术领域

本发明涉及电子商务技术，具体而言，涉及一种高并发业务的订单数据处理方法及装置。

背景技术

随着互联网技术的发展及互联网应用的普及，越来越多的用户喜欢通过电商平台进行网络购物，包括各种实体货物及话费充值等虚拟业务。

以京东的虚拟话费充值业务为例，目前日订单量高峰可达几百万单。特别在月初及月末充值高峰期间，日订单量相较于平时可增长50％～70％，并发量非常高。面对如此巨大的订单数据访问量，订单数据的存储、检索及数据库性能均面临着极大的挑战。

目前，针对高并发业务处理的数据库分库分表(Sharding)技术虽然可以提高访问数据的处理效率，但对于已运行多年的系统而言，在数据库分库分表改造过程中，也存在着一些问题。例如，线上遗留历史数据不一定均能满足Sharding的规则，存在迁移出错的可能；在数据迁移过程中，为了保证所有的线上数据迁移都能正确迁移到各分库，需要停止数据库服务，因此需暂定新订单的处理，导致用户满意度差等。

在所述背景技术部分公开的上述信息仅用于加强对本发明的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

有鉴于此，本发明提供一种高并发业务的订单数据处理方法及装置，能够有效提高高并发业务的订单数据处理效率。

本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

根据本发明的一方面，提供了一种高并发业务的订单数据处理方法，包括：接收订单数据处理请求；根据预设的切流策略，确定将所述订单数据处理请求提交到第一订单处理单元或者第二订单处理单元进行处理；以及当所述订单数据处理请求被提交到所述第二订单处理单元进行处理时，根据发送所述订单数据处理请求的用户类型，将所述订单数据处理请求路由到不同数据库子系统中。

根据本发明的一实施方式，根据发送所述订单数据处理请求的用户类型，将所述订单数据处理请求路由到不同数据库子系统中包括：当发送所述订单数据处理请求的用户类型为普通用户时，将所述订单数据处理请求路由到第一数据库子系统中；以及当发送所述订单数据处理请求的用户类型为企销用户时，将所述订单数据处理请求路由到第二数据库子系统中。

根据本发明的一实施方式，所述第一数据库子系统包括多个第一数据库和/或所述第二数据库子系统包括多个第二数据库，所述方法还包括：当所述订单数据处理请求被路由到所述第一数据库子系统时，根据所述订单数据处理请求的用户名，将所述订单数据处理请求路由到所述多个第一数据库的其中之一；和/或当所述订单数据处理请求被路由到所述第二数据库子系统时，根据所述订单数据处理请求的订单号，将所述订单数据处理请求路由到所述多个第二数据库的其中之一。

根据本发明的一实施方式，上述方法还包括：当检测到所述多个第一数据库和/或所述多个第二数据库的至少其中之一存储的订单数据发生变化时，产生订单数据变化消息，并将所述订单数据变化消息加入到消息队列中；以及当监听到所述消息队列中的所述订单数据变化消息时，通过异步任务驱动方式，将变化的订单数据同步到MongoDB数据库中。

根据本发明的一实施方式，上述方法还包括：使Worker服务器采用动态线程池设计，通过所述异步任务驱动方式，将来自不同数据源的变化的订单数据同步到所述MongoDB数据库中。

根据本发明的一实施方式，上述方法还包括：当将所述变化的订单数据同步到所述MongoDB数据库中时，同步所述变化的订单数据到MySQL订单聚合表中。

根据本发明的一实施方式，所述切流策略包括：所述订单数据处理请求是否为话费充值订单请求、所述订单数据处理请求是否为特定用户的订单请求及所述订单数据处理请求是否为特定商品的订单请求。

根据本发明的另一方面，提供了一种高并发业务的订单数据处理装置，包括：订单接收模块，用于接收订单数据处理请求；订单处理模块，用于根据预设的切流策略，确定将所述订单数据处理请求提交到第一订单处理单元或者第二订单处理单元进行处理；订单路由模块，用于当所述订单数据处理请求被提交到所述第二订单处理单元进行处理时，根据发送所述订单数据处理请求的用户类型，将所述订单数据处理请求路由到不同数据库子系统中。

根据本发明的一实施方式，所述订单路由模块包括：第一路由子模块，用于当发送所述订单数据处理请求的用户类型为普通用户时，将所述订单数据处理请求路由到第一数据库子系统中；以及第二路由子模块，用于当发送所述订单数据处理请求的用户类型为企销用户时，将所述订单数据处理请求路由到第二数据库子系统中。

根据本发明的一实施方式，所述第一数据库子系统包括多个第一数据库和/或所述第二数据库子系统包括多个第二数据库，所述第一路由子模块还用于当所述订单数据处理请求被路由到所述第一数据库子系统时，根据所述订单数据处理请求的用户名，将所述订单数据处理请求路由到所述多个第一数据库的其中之一；和/或所述第二路由子模块还用于当所述订单数据处理请求被路由到所述第二数据库子系统时，根据所述订单数据处理请求的订单号，将所述订单数据处理请求路由到所述多个第二数据库的其中之一。

根据本发明的一实施方式，上述装置还包括：订单变化检测模块，用于当检测到所述多个第一数据库和/或所述多个第二数据库的至少其中之一存储的订单数据发生变化时，产生订单数据变化消息，并将所述订单数据变化消息加入到消息队列中；以及订单数据同步模块，用于当监听到所述消息队列中的所述订单数据变化消息时，通过异步任务驱动方式，将变化的订单数据同步到MongoDB数据库中。

根据本发明的一实施方式，所述订单数据同步模块还用于使Worker服务器采用动态线程池设计，通过所述异步任务驱动方式，将来自不同数据源的变化的订单数据同步到所述MongoDB数据库中。

根据本发明的一实施方式，所述订单数据同步模块还用于当将所述变化的订单数据同步到所述MongoDB数据库中时，同步所述变化的订单数据到MySQL订单聚合表中。

根据本发明的一实施方式，所述切流策略包括：所述订单数据处理请求是否为话费充值订单请求、所述订单数据处理请求是否为特定用户的订单请求及所述订单数据处理请求是否为特定商品的订单请求。

根据本发明的高并发业务的订单数据处理方法，引入了切流策略，使得在数据库架构升级过程中，线上生产数据不迁移，从而保证了业务服务不停机，提高了用户的满意度。此外，通过将普通用户订单数据和企销用户订单数据完全独立存储，避免了两类订单数据库之间的相互影响，并有效提升了订单的处理量及并发订单处理量。经验证，采用本发明实施方式的高并发业务的订单数据处理方法后，日订单处理能力可以提升至1500万单/日，并发订单处理量可提升至300单/秒。

另外，根据一些实施例，本发明的高并发业务的订单数据处理方法，通过将订单数据同步到聚合查询MongoDB数据库中，从而解决订单数据的聚合查询问题，提升数据查询、检索速度。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本发明。

附图说明

通过参照附图详细描述其示例实施例，本发明的上述和其它目标、特征及优点将变得更加显而易见。

图1是根据一示例性实施方式示出的一种高并发业务的订单数据处理方法的流程图。

图2是根据一示例示出的第一数据库子系统和第二数据库子系统的框图。

图3是根据一示例性实施方式示出的另一种高并发业务的订单数据处理方法的流程图。

图4是根据一示例示出的聚合数据库示意图。

图5是根据一示例性实施方式示出的再一种高并发业务的订单数据处理方法的流程图。

图6是根据一示例性实施方式示出的一种高并发业务的订单数据处理装置的框图。

图7是根据一示例性实施方式示出的另一种高并发业务的订单数据处理装置的框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本发明的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本发明的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知结构、方法、装置、实现或者操作以避免喧宾夺主而使得本发明的各方面变得模糊。

图1是根据一示例性实施方式示出的一种高并发业务的订单数据处理方法的流程图。该方法可以应用于服务器中，该服务器可以是电商平台中用于订单数据处理的服务器，也可以是电商平台中用于订单数据处理的服务器群组。如图1所示，高并发业务的订单数据处理方法10包括：

在步骤S102中，接收订单数据处理请求。

该订单处理请求可以包括用户通过移动终端(智能手机、平板电脑)发起的订单数据处理请求，也可以包括用户通过电脑(如浏览器)发起的订单数据处理请求。

以虚拟话费充值业务为例，该订单数据处理请求包括话费充值请求、老订单查询请求等。

在步骤S104中，根据预设的切流策略，确定将该订单数据处理请求提交到第一订单处理单元或者第二订单处理单元进行处理。

其中第一订单处理单元不同于第二订单处理单元。如在改造数据库架构的过程中，为了保证升级的平滑过渡，对于已有系统的功能需要保留，以用于处理线上遗留的历史数据，从而保证相关业务流程处理在数据库架构升级过程期间依然可以正常进行。因此，可以通过设计切流策略，判断接收到的订单数据处理请求是属于需要交由系统已有功能(第一订单处理单元)处理的请求，还是需要交由系统新设计的功能(第二订单处理单元)处理的请求。其中系统新设计的功能可以满足高并发业务的处理需求。关于系统新设计的第二订单处理单元将在下文中具体说明。对于提交到第一订单处理单元进行处理的订单数据处理请求，在系统原有的数据库中进行数据访问操作(如订单数据的增、删、改、查操作)。需要说明的是，在数据库升级而导致数据切流过程中，因为同时保留了新老两套处理功能，因此有可能涉及到用户订单查询的问题。如用户查询订单列表的时候，必须满足用户能查询到历史订单及新订单。因此需要在业务处理上，先查询已有的生产库、再查询新的分库。

切流策略例如可以包括：是否为话费充值订单请求、是否为特定用户的订单请求及是否为特定商品的订单请求。如果该订单数据处理请求为话费充值订单请求，或者是预设的特定用户的订单请求，再或者是预设的特定商品的订单请求，则将该订单数据处理请求提交到第二订单处理单元进行处理；否则，将该订单数据处理请求提交到第一订单处理单元进行处理。

在步骤S106中，当该订单数据处理请求被提交到第二订单处理单元进行处理时，根据发送该订单数据处理请求的用户类型，将该订单数据处理请求路由到不同数据库子系统中。

仍以虚拟话费充值业务为例，系统中的用户通常包括两大类：普通用户及企销用户，因此可以根据这两大类用户类型，采用Sharding技术将系统中的数据库拆分为第一数据库子系统(如对应普通用户)与第二数据库子系统(如对应企销用户)。从而当有订单被提交到第二订单处理单元中时，根据发送该订单数据处理请求的用户类型，将订单数据处理请求路由到第一数据库子系统或第二数据库子系统中。例如，如果发送该订单数据处理请求的用户为普通用户，则将订单数据处理请求路由到第一数据库子系统；而如果发送该订单数据处理请求的用户为企销用户，则将订单数据处理请求路由到第二数据库子系统中。

进一步地，对于路由到第一数据库子系统和/或第二数据库子系统中的订单数据处理请求，还可以再次将其路由到第一数据库子系统或第二数据库子系统的各分库中。对于订单量非常高的电商平台系统，由于高并发业务特性，对于第一数据库子系统和/或第二数据库子系统，为了提升数据库处理性能，还可以进一步采用Sharding技术对订单数据进行分散存储，即进一步对第一数据库子系统和/或第二数据库子系统进行分库。如图2所示，第一数据库子系统DB_1中还可以包括多个数据库db_11～db_1m，第二数据库子系统中DB_2中还可以包括多个数据库db_21～db_2n。

在一些实施例中，第一数据库子系统DB_1中可以根据用户名进行分库。如将用户名为a～c的订单数据存储到数据库db_11中，将用户名为d～f的订单数据存储到数据库db_12中，……，将用户名为x～z的订单数据存储到数据库db_1m中。从而在路由订单数据处理请求时，如果发送该订单数据处理请求的用户的用户名为c，则将该订单数据处理请求路由到数据库db_11中；如果发送该订单数据处理请求的用户的用户名为y，则将该订单数据处理请求路由到数据库db_1m中；以此类推。而考虑到企销用户下单能力差别比较大，对于第二数据库子系统DB_2则可以根据订单号进行分库。如将订单号为1～10的订单数据存储到数据库db_21中，将订单号为11～20的订单数据存储到数据库db_22中，……，将订单号为91～100的订单数据存储到数据库db_2n中。从而在路由订单数据处理请求时，如果该订单数据处理请求的订单号为5，则将该订单数据处理请求路由到数据库db_21中；如果该订单数据处理请求的订单号为98，则将该订单数据处理请求路由到数据库db_2n中；以此类推。

以京东平台的订单量统计值为例，在订单量上，企销用户的订单量可占到日总订单量的60％以上。因此，上述将企销用户和普通用户的订单数据存储解耦，可以从业务处理逻辑和数据物理存储两个方面实现两类用户下单的独立性。在数据库服务器部署上将两类用户的数据库子系统分布到不同的物理机上，可以确保普通用户数据库子系统出故障后不会影响到企销用户的订单处理。

在上述的动态路由数据的设计中，例如可以采用Spring技术实现。Spring技术是一个开源框架，是为了解决企业应用程序开发复杂性而创建的。但本发明不以此为限，在实际应用中，也可以基于其他技术框架设计实现。

本发明实施方式的高并发业务的订单数据处理方法，引入了切流策略，使得在数据库架构升级过程中，线上生产数据不迁移，从而保证了业务服务不停机，提高了用户的满意度。此外，通过将普通用户订单数据和企销用户订单数据完全独立存储，避免了两类订单数据库之间的相互影响，并有效提升了订单的处理量及并发订单处理量。经验证，采用本发明实施方式的高并发业务的订单数据处理方法后，日订单处理能力可以提升至1500万单/日，并发订单处理量可提升至300单/秒。

应清楚地理解，本发明描述了如何形成和使用特定示例，但本发明的原理不限于这些示例的任何细节。相反，基于本发明公开的内容的教导，这些原理能够应用于许多其它实施方式。

图3是根据一示例性实施方式示出的另一种高并发业务的订单数据处理方法的流程图。该方法可以应用于服务器中，该服务器可以是电商平台中用于订单数据处理的服务器，也可以是电商平台中用于订单数据处理的服务器群组。如图3所示，高并发业务的订单数据处理方法20包括：

在步骤S202中，接收订单数据处理请求。

在步骤S204中，根据预设的切流策略，确定将该订单数据处理请求提交到第一订单处理单元或者第二订单处理单元进行处理。

上述步骤与高并发业务的订单数据处理方法10中的步骤相同，在此不再赘述。

在步骤S206中，当该订单数据处理请求被提交到第二订单处理单元进行处理时，根据该订单数据处理请求的订单号，将该订单数据处理请求路由到不同数据库中。

对于第二订单处理单元中的数据库系统，为了提升数据库处理性能，还可以进一步采用Sharding技术对订单数据进行分散存储，即进一步对第二订单处理单元中的数据库系统进行分库。可以采用根据订单号进行分库存储。例如，第二订单处理单元中的数据库系统包括数据库db1～dbn。其中数据点db1存储订单号为1～100的订单数据，数据库db2存储订单号为101～200的订单数据，……，数据库dbn存储订单号为901～1000的订单数据。在路由订单数据处理请求时，如果该订单数据处理请求的订单号为50，则将该订单数据处理请求路由到数据库db1中；如果该订单数据处理请求的订单号为988，则将该订单数据处理请求路由到数据库dbn中；以此类推。

同样地，该动态路由数据的设计也可以通过Spring技术实现，但本发明不以此为限。

本发明实施方式的高并发业务的订单数据处理方法，引入了切流策略，使得在数据库架构升级过程中，线上生产数据不迁移，从而保证了业务服务不停机，提高了用户的满意度。此外，直接通过订单号对进入新数据库系统的订单数据处理请求进行路由，可有效提升订单的处理量及并发订单的处理量。

在上述高并发业务的订单数据处理方法10及20中，使用Sharding技术进行了分库分表。分库分表之后的订单数据被分散到各个分库中，单个数据库的存储和检索压力减小了，为了提升数据查询速度，本发明还进一步提出再一种高并发业务的订单数据处理方法，通过聚合查询，可提高分库数据系统中的数据查询速度。如图4所示，引入非关系(NoSQL)MongoDB数据库，冗余存储一份各分库的订单，充分利用MongoDB的特性解决订单数据的聚合查询问题，提升数据查询、检索速度；并通过任务Worker异步驱动方式，使MongoDB中的数据与各分库中的数据保持实时同步。下面将具体说明该聚合查询的方法。

图5是根据一示例性实施方式示出的再一种高并发业务的订单数据处理方法的流程图。该方法可以应用于服务器中，该服务器可以是电商平台中用于订单数据处理的服务器，也可以是电商平台中用于订单数据处理的服务器群组。如图5所示，高并发业务的订单数据处理方法30包括：

在步骤S302中，当检测到某个订单数据发生变化时，产生订单数据变化消息，并将该消息加入到消息队列中。

如当用户对某个订单进行操作，使上述第一数据库子系统和/或第二数据库子系统中存储的订单数据发生变化时，通过消息中间件方式，产生订单数据变化消息，并将该消息加入到消息队列中。

例如，当用户对某个订单进行操作，而使充值前台应用服务器或充值SOA应用服务器或充值MAN服务器检测到订单数据变化时，产生订单数据变化消息，并将该消息发送到消息队列中。

在步骤S304中，当监听到消息队列中的订单数据变化消息时，将变化的订单数据同步到MongoDB数据库中。

当后台管理端监听到消息队列中的订单数据变化消息时，后台管理端通过Worker服务器执行逻辑异步同步订单数据任务，将订单数据同步到MongoDB数据库中。

充值Worker服务器从消息队列中获取订单数据变化消息，将变化的订单数据同步到MongoDB数据库中。

为了确保订单数据变化同步消息不丢失，可以通过埋点方式将订单数据变化插入到任务记录中。由于在本地库中插入了任务记录，只有订单数据被同步成功，该任务才被视为完成；否则，系统会重复执行相应同步任务，直到任务被同步完成。

由于采用了异步任务驱动的方式将订单数据同步到MongoDB数据库中，通过任务驱动，保证了订单数据的每一次变化都能被同步Worker服务器处理到。此外，采用消息中间件，每台Worker服务器监听订单同步任务消息队列，每次从消息队列中取得的同步任务所属的数据源可能不同，也即同一台Worker服务器在执行同步任务的时候会处理多个分库数据源的任务。为了保证多数据源任务执行的线程池相互独立，系统设计上采用了动态创建线程池实现多数据源的任务线程池解耦。动态线程池核心思想是将数据源与线程池对应起来，假设数据源有N个，每个数据源都有任务处理Worker服务器，则每台Worker服务器的任务线程池有N+1个。

在一些实施例中，为了防止聚合查询MongoDB数据库不可用，在降级处理上，还可以利用MySQL，在任务Worker服务器采用异步任务方式同步订单数据到MongoDB数据库的同时，再同步一份订单数据到MySQL的聚合订单表，当MongoDB数据库不可用时，可以使用MySQL的订单聚合表进行降级查询处理。

本发明实施方式的高并发业务的订单数据处理方法，通过将订单数据同步到聚合查询MongoDB数据库中，从而解决订单数据的聚合查询问题，提升数据查询、检索速度。

本领域技术人员可以理解实现上述实施方式的全部或部分步骤被实现为由CPU执行的计算机程序。在该计算机程序被CPU执行时，执行本发明提供的上述方法所限定的上述功能。所述的程序可以存储于一种计算机可读存储介质中，该存储介质可以是只读存储器，磁盘或光盘等。

此外，需要注意的是，上述附图仅是根据本发明示例性实施方式的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

下述为本发明装置实施例，可以用于执行本发明方法实施例。对于本发明装置实施例中未披露的细节，请参照本发明方法实施例。

图6是根据一示例性实施方式示出的一种高并发业务的订单数据处理装置的框图。该装置可以应用于服务器中，该服务器可以是电商平台中用于订单数据处理的服务器，也可以是电商平台中用于订单数据处理的服务器群组。如图6所示，高并发业务的订单数据处理装置40包括：订单接收模块402、订单处理模块404以及订单路由模块406。

订单接收模块402用于接收订单数据处理请求。

订单处理模块404用于根据预设的切流策略，确定将所述订单数据处理请求提交到第一订单处理单元或者第二订单处理单元进行处理。

订单路由模块406用于当所述订单数据处理请求被提交到所述第二订单处理单元进行处理时，根据发送所述订单数据处理请求的用户类型，将所述订单数据处理请求路由到不同数据库子系统中。

在一些实施例中，订单路由模块406包括：第一路由子模块4062和第二路由子模块4064。第一路由子模块4062用于当发送所述订单数据处理请求的用户类型为普通用户时，将所述订单数据处理请求路由到第一数据库子系统中。第二路由子模块4064用于当发送所述订单数据处理请求的用户类型为企销用户时，将所述订单数据处理请求路由到第二数据库子系统中。

在一些实施例中，所述第一数据库子系统包括多个第一数据库和/或所述第二数据库子系统包括多个第二数据库，第一路由子模块4062还用于当所述订单数据处理请求被路由到所述第一数据库子系统时，根据所述订单数据处理请求的用户名，将所述订单数据处理请求路由到所述多个第一数据库的其中之一；和/或第二路由子模块4064还用于当所述订单数据处理请求被路由到所述第二数据库子系统时，根据所述订单数据处理请求的订单号，将所述订单数据处理请求路由到所述多个第二数据库的其中之一。

在一些实施例中，所述切流策略包括：所述订单数据处理请求是否为话费充值订单请求、所述订单数据处理请求是否为特定用户的订单请求及所述订单数据处理请求是否为特定商品的订单请求。

本发明实施方式的高并发业务的订单数据处理装置，引入了切流策略，使得在数据库架构升级过程中，线上生产数据不迁移，从而保证了业务服务不停机，提高了用户的满意度。此外，通过将普通用户订单数据和企销用户订单数据完全独立存储，避免了两类订单数据库之间的相互影响，并有效提升了订单的处理量及并发订单处理量。经验证，采用本发明实施方式的高并发业务的订单数据处理方法后，日订单处理能力可以提升至1500万单/日，并发订单处理量可提升至300单/秒。

图7是根据一示例性实施方式示出的另一种高并发业务的订单数据处理装置的框图。该装置可以应用于服务器中，该服务器可以是电商平台中用于订单数据处理的服务器，也可以是电商平台中用于订单数据处理的服务器群组。与图6所示的高并发业务的订单数据处理装置40不同之处在于，如图7所示，高并发业务的订单数据处理装置50还包括：订单变化检测模块508及订单数据同步模块510。

订单变化检测模块508用于当检测到所述多个第一数据库和/或所述多个第二数据库的至少其中之一存储的订单数据发生变化时，产生订单数据变化消息，并将所述订单数据变化消息加入到消息队列中。

订单数据同步模块510用于当监听到所述消息队列中的所述订单数据变化消息时，通过异步任务驱动方式，将变化的订单数据同步到MongoDB数据库中。

在一些实施例中，订单数据同步模块510还用于使Worker服务器采用动态线程池设计，通过所述异步任务驱动方式，将来自不同数据源的变化的订单数据同步到所述MongoDB数据库中。

在一些实施例中，订单数据同步模块510还用于当将所述变化的订单数据同步到所述MongoDB数据库中时，同步所述变化的订单数据到MySQL订单聚合表中。

本发明实施方式的高并发业务的订单数据处理装置，通过将订单数据同步到聚合查询MongoDB数据库中，从而解决订单数据的聚合查询问题，提升数据查询、检索速度。

需要注意的是，上述附图中所示的框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本发明实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本发明实施方式的方法。

以上具体地示出和描述了本发明的示例性实施方式。应可理解的是，本发明不限于这里描述的详细结构、设置方式或实现方法；相反，本发明意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

Claims (14)

1.一种高并发业务的订单数据处理方法，其特征在于，包括：

接收订单数据处理请求；

根据预设的切流策略，确定将所述订单数据处理请求提交到第一订单处理单元或者第二订单处理单元进行处理；以及

当所述订单数据处理请求被提交到所述第二订单处理单元进行处理时，根据发送所述订单数据处理请求的用户类型，将所述订单数据处理请求路由到不同数据库子系统中。

2.根据权利要求1所述的方法，其特征在于，根据发送所述订单数据处理请求的用户类型，将所述订单数据处理请求路由到不同数据库子系统中包括：

当发送所述订单数据处理请求的用户类型为普通用户时，将所述订单数据处理请求路由到第一数据库子系统中；以及

当发送所述订单数据处理请求的用户类型为企销用户时，将所述订单数据处理请求路由到第二数据库子系统中。

3.根据权利要求2所述的方法，其特征在于，所述第一数据库子系统包括多个第一数据库和/或所述第二数据库子系统包括多个第二数据库，所述方法还包括：

当所述订单数据处理请求被路由到所述第一数据库子系统时，根据所述订单数据处理请求的用户名，将所述订单数据处理请求路由到所述多个第一数据库的其中之一；和/或

当所述订单数据处理请求被路由到所述第二数据库子系统时，根据所述订单数据处理请求的订单号，将所述订单数据处理请求路由到所述多个第二数据库的其中之一。

4.根据权利要求3所述的方法，其特征在于，还包括：

当检测到所述多个第一数据库和/或所述多个第二数据库的至少其中之一存储的订单数据发生变化时，产生订单数据变化消息，并将所述订单数据变化消息加入到消息队列中；以及

当监听到所述消息队列中的所述订单数据变化消息时，通过异步任务驱动方式，将变化的订单数据同步到MongoDB数据库中。

5.根据权利要求4所述的方法，其特征在于，还包括：使Worker服务器采用动态线程池设计，通过所述异步任务驱动方式，将来自不同数据源的变化的订单数据同步到所述MongoDB数据库中。

6.根据权利要求4所述的方法，其特征在于，还包括：当将所述变化的订单数据同步到所述MongoDB数据库中时，同步所述变化的订单数据到MySQL订单聚合表中。

7.根据权利要求1～6任一项所述的方法，其特征在于，所述切流策略包括：所述订单数据处理请求是否为话费充值订单请求、所述订单数据处理请求是否为特定用户的订单请求及所述订单数据处理请求是否为特定商品的订单请求。

8.一种高并发业务的订单数据处理装置，其特征在于，包括：

订单接收模块，用于接收订单数据处理请求；

订单处理模块，用于根据预设的切流策略，确定将所述订单数据处理请求提交到第一订单处理单元或者第二订单处理单元进行处理；以及

订单路由模块，用于当所述订单数据处理请求被提交到所述第二订单处理单元进行处理时，根据发送所述订单数据处理请求的用户类型，将所述订单数据处理请求路由到不同数据库子系统中。

9.根据权利要求8所述的装置，其特征在于，所述订单路由模块包括：

第一路由子模块，用于当发送所述订单数据处理请求的用户类型为普通用户时，将所述订单数据处理请求路由到第一数据库子系统中；以及

第二路由子模块，用于当发送所述订单数据处理请求的用户类型为企销用户时，将所述订单数据处理请求路由到第二数据库子系统中。

10.根据权利要求9所述的装置，其特征在于，所述第一数据库子系统包括多个第一数据库和/或所述第二数据库子系统包括多个第二数据库，所述第一路由子模块还用于当所述订单数据处理请求被路由到所述第一数据库子系统时，根据所述订单数据处理请求的用户名，将所述订单数据处理请求路由到所述多个第一数据库的其中之一；和/或所述第二路由子模块还用于当所述订单数据处理请求被路由到所述第二数据库子系统时，根据所述订单数据处理请求的订单号，将所述订单数据处理请求路由到所述多个第二数据库的其中之一。

11.根据权利要求10所述的装置，其特征在于，还包括：

订单变化检测模块，用于当检测到所述多个第一数据库和/或所述多个第二数据库的至少其中之一存储的订单数据发生变化时，产生订单数据变化消息，并将所述订单数据变化消息加入到消息队列中；以及

订单数据同步模块，用于当监听到所述消息队列中的所述订单数据变化消息时，通过异步任务驱动方式，将变化的订单数据同步到MongoDB数据库中。

12.根据权利要求11所述的装置，其特征在于，所述订单数据同步模块还用于使Worker服务器采用动态线程池设计，通过所述异步任务驱动方式，将来自不同数据源的变化的订单数据同步到所述MongoDB数据库中。

13.根据权利要求11所述的装置，其特征在于，所述订单数据同步模块还用于当将所述变化的订单数据同步到所述MongoDB数据库中时，同步所述变化的订单数据到MySQL订单聚合表中。

14.根据权利要求8～13任一项所述的装置，其特征在于，所述切流策略包括：所述订单数据处理请求是否为话费充值订单请求、所述订单数据处理请求是否为特定用户的订单请求及所述订单数据处理请求是否为特定商品的订单请求。