WO2019033605A1

WO2019033605A1 - Method and apparatus for asynchronous order processing, and storage medium and terminal

Info

Publication number: WO2019033605A1
Application number: PCT/CN2017/112761
Authority: WO
Inventors: 彭川宇
Original assignee: 平安科技（深圳）有限公司
Priority date: 2017-08-17
Filing date: 2017-11-24
Publication date: 2019-02-21
Also published as: CN107679931A

Abstract

The present application is applicable to the technical field of communications. Provided are a method and apparatus for asynchronous order processing, and a storage medium and a terminal. The method comprises: when an order transaction request sent by a front-end device is received, caching the order transaction request into a message queue, and sending a response message to the front-end device, so as to notify the front-end device that the order transaction request has been successfully received; reading the order transaction request from the message queue according to a first-in-first-out sequence, and executing a transaction operation corresponding to the order transaction request, so as to obtain a transaction result; and acquiring the transaction result, and calling back a uniform resource locator provided by the front-end device to return the transaction result to the front-end device, so as to notify the front-end device of the order transaction request being successfully executed and of a corresponding transaction result. The present application solves the problems that a back-end server in the existing order management system cannot bear high concurrency of front-end orders and that resource waste is generated when the high concurrency of front-end orders is dealt with through capacity expansion.

Description

Method, device, storage medium and terminal for asynchronous processing of orders

This patent application is based on the Chinese Patent Application No. 201710706714.8 filed on Aug. 17, 2017, entitled "Method, Apparatus, Storage Medium and Terminal for Asynchronous Order Processing", and requires priority.

Technical field

The present application belongs to the field of communications technologies, and in particular, to a method, an apparatus, a storage medium, and a terminal for asynchronous processing of an order.

Background technique

The order management system makes it easy for private equity funds to manage assets, such as independently deployed safe pay orders, life insurance orders, land orders, direct orders, and live orders. For the orders received by the order management system front-end equipment, the prior art adopts synchronous calling to process, that is, the back-end server of the order management system receives the next order for processing after completing an order transaction operation. When encountering large-volume order concurrency, the way of synchronous call will put a lot of pressure on the back-end server, which will often crush the back-end server and reduce the response speed of the back-end server to the front-end device, thus reducing the front-end. The throughput of the device to the order. The prior art uses new servers to cope with high concurrency. When the peak of concurrency has passed, the newly added server lacks “useful land”, which leads to waste of resources.

Summary of the invention

The embodiment of the present invention provides a method, a device, a storage medium, and a terminal for asynchronous processing of an order, so as to solve the problem that the back-end server in the existing order management system cannot withstand the high concurrency of the front-end device and the waste of resources when the capacity is expanded.

In a first aspect, a method for asynchronous processing of an order, the method comprising:

Receiving the order transaction request sent by the front-end device, buffering the order transaction request into the message queue, and sending a response message to the front-end device to notify the front-end device that the order transaction request has been successfully received;

Reading an order transaction request from the message queue in a first-in first-out order, executing a transaction operation corresponding to the order transaction request, and obtaining a transaction result;

Acquiring the transaction result, and returning the uniform resource locator provided by the front-end device to return the transaction result to the front-end device, to inform the front-end device that the order transaction request has been successfully executed and the corresponding transaction result.

Further, before the order transaction request is cached to the message queue, the method further includes:

Saving the order transaction request to the MongoDB database;

After obtaining the transaction result, the method further includes:

And returning status information corresponding to the order transaction request in the MongoDB database according to the transaction result.

Further, the reading the order transaction request from the message queue in a first-in first-out order, executing the transaction operation corresponding to the order transaction request, and obtaining the transaction result includes:

Start multithreading;

Reading an order transaction request from the message queue in a first-in first-out order, and allocating the read order transaction request to one of the multi-threads, and executing the order transaction request by the allocated thread Trading operation

Returning the transaction result to the front-end device by using the uniform resource locator provided by the callback front-end device includes:

After the transaction request is processed, the uniform resource locator provided by the front-end device is returned by each thread to return the transaction result of the processed order transaction request to the front-end device.

Further, after the order transaction request is read from the message queue in a first-in first-out order, and the transaction operation corresponding to the order transaction request is executed, the method further includes:

Obtaining revenue data generated during the execution of the transaction operation, and filtering the revenue data;

Starting to read and write dual threads, reading the filtered profit data through the read thread to write to the memory queue, and simultaneously reading the profit data from the memory queue through the write thread into the income file segment;

The revenue file segment is uploaded to the front end device whenever a revenue file segment is written.

In a second aspect, an apparatus for asynchronously processing an order, the apparatus comprising:

An order cache module, configured to: when receiving an order transaction request sent by the front-end device, buffer the order transaction request into a message queue, and send a response message to the front-end device to notify the front-end device of the order transaction The request has been successfully received;

An order processing module, configured to read an order transaction request from the message queue in a first-in first-out order, execute a transaction operation corresponding to the order transaction request, and obtain a transaction result;

a callback module, configured to obtain the transaction result, and the uniform resource locator provided by the callback front end device returns the transaction result to the front end device to notify the front end device that the order transaction request has been successfully executed and the corresponding transaction result.

Further, the device further includes:

a storage module, configured to save the order transaction request to a MongoDB database before caching the order transaction request to a message queue;

And an update module, configured to, after obtaining the transaction result, write back status information corresponding to the order transaction request in the MongoDB database according to the transaction result.

Further, the request processing module includes:

a startup unit for starting multithreading;

a multi-thread processing unit, configured to read an order transaction request from the message queue in a first-in first-out order, and allocate the read order transaction request to one of the multi-threads, and execute through the allocated thread The transaction operation corresponding to the order transaction request;

The callback module is also used to:

Further, the device further includes:

a filtering module, configured to obtain revenue data generated during execution of the transaction operation, and filter the revenue data;

a fragment generation module, configured to start reading and writing dual threads, and reading the filtered profit data by reading the thread to write to the memory queue, and simultaneously reading the profit data from the memory queue and writing the income data to the income file through the write thread in parallel In the fragment;

The segment uploading module is configured to upload the revenue file segment to the front end device whenever the profit file segment is written.

A third aspect is a computer readable storage medium having stored thereon computer readable instructions that, when executed by a processor, implement the following steps:

In a fourth aspect, the embodiment of the present application further provides a terminal, including a memory, a processor, and computer readable instructions stored on the memory and executable on the processor, when the processor executes the computer readable instruction Implement the following steps:

Compared with the prior art, the embodiment of the present application uses java to reconstruct the order management system. Among them, for the transaction Requesting, in a synchronous receiving manner, each time an order transaction request sent by the front-end device is received, the order transaction request is cached in a message queue, and a response message is sent to the front-end device to notify the front-end device The order transaction request has been successfully received, so that the front-end device can directly feed back the message to the user without waiting for the transaction result of the order management system, which is beneficial to improve the concurrent throughput of the front-end device; and for the transaction operation, the asynchronous processing method is adopted, according to the advanced first Executing an order transaction request from the message queue, executing a transaction operation corresponding to the order transaction request, and obtaining a transaction result; and finally returning a uniform resource locator provided by the front-end device to return the transaction result to the front-end device In order to inform the front-end device that the order transaction request has been successfully executed and the corresponding transaction result; thus, the back-end server can withstand the high concurrency of the front-end device, and does not need to be expanded, and solves the problem that the existing synchronous calling mode is encountered. Backend servers are unbearable and scalable when high concurrency Waste of raw resources.

DRAWINGS

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings to be used in the embodiments or the prior art description will be briefly described below. Obviously, the drawings in the following description are only It is a certain embodiment of the present application, and other drawings can be obtained according to the drawings without any creative work for those skilled in the art.

1 is a first implementation flowchart of a method for asynchronous processing of an order provided by an embodiment of the present application;

2 is a second implementation flowchart of a method for asynchronous processing of an order provided by an embodiment of the present application;

3 is a third implementation flowchart of a method for asynchronous processing of an order provided by an embodiment of the present application;

4 is a fourth implementation flowchart of a method for asynchronous processing of an order provided by an embodiment of the present application;

5 is a structural diagram of a device for asynchronous processing of an order provided by an embodiment of the present application;

FIG. 6 is a schematic diagram of a terminal provided by an embodiment of the present application.

Detailed ways

In order to make the objects, technical solutions, and advantages of the present application more comprehensible, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are merely illustrative of the application and are not intended to be limiting.

The existing order management system adopts the synchronous calling method. After an order is processed, the next order is received and processed. When a large number of orders are encountered, the synchronous calling method will put a lot of pressure on the back-end server, thus affecting the The efficiency of response to orders. In view of this, the embodiment of the present application uses java to reconstruct the original order management system, and the back-end server adopts the kafka architecture to improve the transaction operation to asynchronous processing. Here, kafka is a distributed based release / A system for subscribing to messages that can handle all action flow data in a consumer-sized website. The action flow data includes, but is not limited to, a page view amount, information on the viewed content, and a search situation. The Kafka cluster can include one or more servers that do not maintain the consumption state of the data, ensure high timeliness, high throughput, and directly use the disk for storage, linear reading, and fast response. The embodiment of the present application can effectively increase the throughput of front-end orders by adopting the kafka architecture in the back-end server.

FIG. 1 shows a first implementation flow of a method for asynchronous processing of an order provided by an embodiment of the present application. In the embodiment of the present application, the order is a transaction order generated by a Hang Seng order management system. The embodiment of the present application will describe an asynchronous processing procedure for a front-end order transaction request from the perspective of a back-end server, including but not limited to a computer, a server, and a notebook computer. Referring to FIG. 1, the method for asynchronous processing of the order includes:

In step S101, when receiving the order transaction request sent by the front-end device, the order transaction request is cached into the message queue, and a response message is sent to the front-end device to inform the front-end device of the order transaction request. Received successfully.

Here, the front-end device includes, but is not limited to, a smartphone, a tablet, a computer, and is responsible for sending a message to a back-end server and reading a message to a back-end server, pulling data and processing. In the embodiment of the present application, the front-end device receives an order transaction request submitted by a user in a Hang Seng order management system. The order transaction request includes, but is not limited to, a securities transaction request, a fund transaction request, and a transaction account number, a fund code, and a request time information are recorded in each order transaction request. The front end device then sends the order transaction request to the backend server.

The backend server receives the order transaction request, and caches the order transaction request into a message queue according to the request time information. Here, the message queue is used by the backend server to buffer the received order transaction request, so that the front end device can continuously receive the order transaction request, thereby improving the order throughput of the front end device. Further, after the order transaction request is cached, the backend server may further send a response message to the front end device to notify the front end device that the order transaction request has been successfully received, so that the front end device can be based on the The response message outputs to the user a prompt message that the order transaction request is successfully received without waiting for the processing result of the backend server, ensuring that the user experience of the front end device still seems to be synchronized.

In step S102, an order transaction request is read from the message queue in a first-in first-out order, and a transaction operation corresponding to the order transaction request is executed to obtain a transaction result.

In the embodiment of the present application, the order transaction request is cached in the message queue of the backend server memory according to the order of the request time, and the transaction request at the bottom of the stack is earlier than the request time corresponding to the order transaction request at the top of the stack. Therefore, the embodiment of the present application reads the order transaction request for processing in a first-in-first-out manner. Wherein, the first in first out (FIFO) is a method of processing the program request from the queue or the stack, so that the earliest order transaction request in the message queue is prioritized and then processed. The next earliest order transaction request, thus guaranteeing the backend server The order transaction request is still responded to in the order in which the front end device receives the order transaction request.

After reading the order transaction request, parsing the order transaction request, obtaining a transaction account number and a fund code, and performing a corresponding transaction operation according to the transaction account number and the fund code to obtain a transaction result. Illustratively, the transaction operation includes any process of securities transactions, such as computerized content such as account opening, commissioning, closing, delivery, and transfer. The transaction result is status information of the order transaction request after the transaction operation is completed, including but not limited to the transaction party account number, fund code, transaction status, transaction time, and transaction mode.

In step S103, the transaction result is obtained, and the uniform resource locator provided by the callback front-end device returns the transaction result to the front-end device to notify the front-end device that the order transaction request has been successfully executed and the corresponding transaction result.

Here, after completing the transaction operation of the order transaction request by step S102, the backend server obtains the transaction result, puts the transaction result into the body part of the HTTP response message, and calls back the uniform resource locator provided by the front end device to The transaction result is returned to the front end device. The front-end device may invoke the above-mentioned uniform resource locator to obtain the HTTP response message by using the HTTP protocol, and then display the transaction result on the browser, thereby completing the query operation of the transaction result of the order transaction request. Cache the order transaction request through the message queue, and then read and process it one by one, so that the back-end server can withstand the high concurrency of the front-end device, and does not need to be expanded, and solves the problem that the existing synchronous calling mode encounters high concurrency when the back-end server is encountered. Unbearable and expanding problems cause waste of resources.

Optionally, as described above, the backend server uses an Oracle database, and the corresponding transaction operation of the order transaction request is completed in the Oracle database. The prior art also stores the transaction result in the Oracle database, so that the read and write operations are completed in the Oracle database, and the processing of the order transaction request and the query result of the transaction result are not high. In order to solve the above problem, on the basis of the first implementation flow of the method for processing the asynchronous processing of the order provided in FIG. 1 , a second implementation flow of the method for asynchronous processing of the order provided by the embodiment of the present application is proposed, as shown in FIG. 2 .

In FIG. 2, the method for asynchronous processing of the order includes:

In step S201, when the order transaction request sent by the front-end device is received, the order transaction request is saved to the MongoDB database, and the order transaction request is cached in the message queue, and the response is sent to the front-end device. a message to inform the front end device that the order transaction request has been successfully received.

Here, the embodiment of the present application adds a MongoDB database. Before the order transaction request is cached to the message queue, the order transaction request is first saved in the MongoDB database to store the order transaction request through the MongoDB database. The MongoDB is a product between a relational database and a non-relational database.

In step S202, the order transaction request is read from the message queue in a first-in first-out order, the transaction operation corresponding to the order transaction request is executed, the transaction result is obtained, and the MongoDB database is written back according to the transaction result. State information corresponding to the order transaction request.

In the embodiment of the present application, the transaction operation remains in the Oracle database. After obtaining the transaction result after the transaction operation, the embodiment of the present application saves the transaction result to the MongoDB database, specifically, to write back the status information corresponding to the order transaction request in the MongoDB database according to the transaction result. When the front-end device queries the transaction result corresponding to the order transaction request, the back-end server can directly query the MongoDB database to obtain the transaction result without querying the Oracle database, thereby realizing the separation of the transaction operation and the query operation, which is beneficial to reducing the processing pressure of the Oracle database. , which in turn improves the response speed of the backend server to the transaction request.

In step S203, the transaction result is obtained, and the uniform resource locator provided by the callback front-end device returns the transaction result to the front-end device to notify the front-end device that the order transaction request has been successfully executed and the corresponding transaction result.

The step S203 is the same as the step S103 described in the embodiment of the present invention. For details, refer to the description of the foregoing embodiment, and details are not described herein again.

The embodiment of the present application adopts the method of sub-database, and combines the oracle database and the MongoDB database, and different databases perform different functions. Among them, the process flow and approval data involved in the asynchronous processing of the order are stored in the oracle database, the transaction operation is completed by the Oracle database, the transaction result is stored in the MongoDB database, and the transaction query is completed by the MongoDB database, and the read-write separation is realized; Query directly to the MongoDB database query, without querying the Oracle database, improve the response speed to the order transaction request, but also improve the query response speed of the transaction results.

Optionally, as described above, after receiving the order transaction request, the backend server first caches the order transaction request into the message queue, and then reads the order transaction request in a first-in first-out order for asynchronous processing. When there are too many order transaction requests in the message queue, the time required for the backend server to read the order transaction request one by one for processing is very large and the processing efficiency is low. In order to solve the above problem, on the basis of the first implementation flow of the method for processing the asynchronous processing of the order provided in FIG. 1 , the third implementation flow of the method for asynchronous processing of the order provided by the embodiment of the present application is proposed, as shown in FIG. 3 .

In FIG. 3, the order transaction request is read from the message queue in the first-in first-out order in step S102, and the transaction operation corresponding to the order transaction request is executed, and the transaction result is obtained:

In step S301, multithreading is started.

Here, any one of the multi-threads is used to execute a transaction operation corresponding to an order transaction request. The number of multithreads is based on actual processor performance and is not limited here.

In step S302, an order transaction request is read from the message queue in a first-in first-out order, and the read order transaction request is allocated to one of the multi-threads, and the executed thread executes the Order transaction request Corresponding transaction operation.

In the embodiment of the present application, the backend server determines whether there is an idle thread in real time; if yes, reads an order transaction request from the message queue, and allocates the order transaction request to the currently idle thread for processing, The thread processes the transaction request to improve the overall processing efficiency of the order transaction request; if not, it indicates that the current multiple threads are processing the order transaction request, and then waiting for the idle thread to appear. Here, you can use the status flags to record the status of each thread. Illustratively, if the thread is performing a transaction operation, the status flag is set to 1, indicating that the thread is busy; if the thread has completed the transaction operation, the status flag is set to 0, indicating that the thread is idle. The backend server determines if there are free threads by identifying the flag bits of the thread.

Optionally, after executing the transaction operation corresponding to the order transaction request, the thread may further write back the status information corresponding to the order transaction request in the MongoDB database according to the transaction result, and simultaneously execute the transaction. The result is recalled to the front-end device. In the embodiment of FIG. 1, the uniform resource locator provided by the callback front-end device in the step S103 may return the transaction result to the front-end device, and may further include:

In step S303, after the transaction request is processed, the unified resource locator provided by the front-end device is returned by each thread to return the transaction result of the processed order transaction request to the front-end device.

At this point, the thread completes a transaction request, and returns the transaction result corresponding to the order transaction request to the front-end device through the uniform resource locator provided by the front-end device. The embodiment of the present application asynchronously processes an order transaction request by starting a plurality of threads, thereby effectively improving the overall processing efficiency of the order transaction request.

Optionally, the backend server generates revenue data during the asynchronous processing of reading the order transaction request. The prior art is to uniformly generate transaction data into a revenue file, and then periodically upload the revenue file to a front-end device, including but not limited to a partner payment institution and a brokerage institution. However, different users and different order transaction requests may generate revenue data. According to statistics, there are more than four GB of revenue data every day, and the generated income file is very large, which results in the speed of the income file being uploaded to the front-end device. very slow. And front-end devices are not easy to parse such huge revenue files. In order to solve the above problem, on the basis of the first implementation flow of the method for processing the asynchronous processing of the order provided in FIG. 1, the fourth implementation flow of the method for asynchronous processing of the order provided by the embodiment of the present application is proposed, as shown in FIG. 4 .

In FIG. 4, the method for asynchronous processing of the order includes:

Steps S401 to S403, wherein the steps S401 to S403 are the same as the steps S101 to S103 described in the embodiment of the present invention. For details, refer to the description of the foregoing embodiment, and details are not described herein again.

In step S404, after performing the transaction operation corresponding to the transaction request, the revenue data generated during the execution of the transaction operation is acquired, and the revenue data is filtered.

Here, the embodiment of the present application sets a filtering rule in advance by writing a SQL statement. Illustratively, the filtering The rule may be to remove the revenue data with a return of zero or to remove the revenue data without the cumulative benefit. After executing the transaction operation corresponding to the order transaction request, the backend server acquires the revenue data, reads the SQL statement, and filters the revenue data according to the SQL statement to reduce the size of the generated income file; The filtered revenue data is cached into the specified memory to wait for writing into the revenue file fragment. Different from the prior art, the embodiment of the present application splits the income file into several segments for reading and writing, and the size of each segment is smaller than the revenue file.

In step S405, the read/write dual thread is started, and the filtered profit data is read into the memory queue by the read thread, and the profit data is read out from the memory queue by the write thread in parallel and written to the profit file fragment. in.

Here, the back-end server uses the read-write dual-threading method to write the revenue data into the revenue file fragment. The read thread reads a row of revenue data and writes it to the memory queue. The write thread synchronously reads the revenue data from the memory queue and writes the income file segment, and the read data and the write file are decoupled and separated, so that the revenue data is read. At the time, the revenue document fragment was almost finished. The generation time of the revenue file segment is equivalent to the reading time of the revenue data. Compared with the existing method of reading and writing synchronization, the time spent reading the data is the sum of the data time and the file time, which greatly speeds up the generation of the revenue file segment.

In step S406, the revenue file segment is uploaded to the front end device whenever a revenue file segment is written.

The backend server monitors in real time whether there is a revenue file fragment full, and if so, uploads the revenue file fragment to the front end device and then begins writing a revenue file fragment. Since the revenue file fragment is divided by the revenue file, the amount of data is less, which facilitates the upload operation of the backend server and facilitates the parsing operation of the front end device. After receiving the revenue file segment, the front-end device can process without waiting for the remaining revenue data. When all revenue data is uploaded through the revenue file segment, the front-end device has processed multiple revenue file fragments, which effectively speeds up the processing of the revenue file by the front-end device.

It should be understood that, in the foregoing embodiments, the size of the serial number of each step does not mean the order of execution order, and the order of execution of each step should be determined by its function and internal logic, and should not constitute any implementation process of the embodiment of the present application. limited.

It should be noted that those skilled in the art can understand that all or part of the steps of implementing the above embodiments may be completed by hardware, or may be instructed by computer readable instructions, and the computer readable instructions may be stored. In a computer readable storage medium, the storage medium may be a read only memory, a magnetic disk or an optical disk, or the like.

FIG. 5 is a structural diagram of an apparatus for asynchronous processing of an order provided by an embodiment of the present application. For convenience of description, only parts related to the embodiment of the present application are shown.

In the embodiment of the present application, the device for asynchronous processing of the order is used to implement the method for asynchronous processing of the order described in the foregoing embodiments of FIG. 1 to FIG. 4, which may be a software unit, a hardware unit or a combination of hardware and software built in the terminal. Unit. Place The terminal is a back-end server in the Hang Seng order management system, including but not limited to computers, servers, and notebook computers.

Referring to FIG. 5, the device for asynchronously processing an order includes:

The order cache module 51 is configured to: when receiving the order transaction request sent by the front-end device, buffer the order transaction request into the message queue, and send a response message to the front-end device to notify the front-end device of the order The transaction request has been successfully received;

An order processing module 52, configured to read an order transaction request from the message queue in a first-in first-out order, execute a transaction operation corresponding to the order transaction request, and obtain a transaction result;

a callback module 53 is configured to obtain the transaction result, and the uniform resource locator provided by the callback front-end device returns the transaction result to the front-end device to notify the front-end device that the order transaction request has been successfully executed and corresponding Transaction results.

Here, the backend server receives the order transaction request through the order cache module 51, and caches the order transaction request into the message queue according to the request time information, so that the front end device can continuously receive the order transaction request, thereby improving the front end. Order throughput of the device. Further, after the order transaction request is cached, the order cache module 51 may further send a response message to the front end device to inform the front end device that the order transaction request has been successfully received, so that the front end device can be based on The response message outputs to the user a prompt message that the order transaction request is successfully received without waiting for the processing result of the backend server, ensuring that the user experience of the front end device still appears to be synchronized. Further, after the order transaction request is cached to the message queue, it is read and processed asynchronously by the order processing module 52, so that the back-end server can withstand the high concurrency of the front-end device and does not need to be expanded. When the existing synchronous calling method encounters high concurrency, the back-end server is unbearable and the capacity is wasted.

Optionally, the device further includes:

The storage module 54 is configured to save the order transaction request to the MongoDB database before caching the order transaction request to the message queue;

The update module 55 is configured to, after obtaining the transaction result, write back the status information corresponding to the order transaction request in the MongoDB database according to the transaction result.

In the embodiment of the present application, the back-end server uses the Oracle database, the transaction operation corresponding to the order transaction request is completed in the Oracle database, and the order transaction request and its corresponding transaction result are stored in the MongoDB database. By adopting the method of sub-database, the embodiment of the present application realizes the separation of the transaction operation and the result query; the subsequent front-end device query can directly query the MongoDB database, and does not need to query the Oracle database, thereby reducing the pressure on the Oracle database and improving the The response speed of the order transaction request also increases the response speed of the query to the transaction result.

Optionally, the order processing module 52 includes:

The starting unit 521 is configured to start multithreading;

The multi-thread processing unit 522 is configured to read an order transaction request from the message queue in a first-in first-out order, and allocate the read order transaction request to one of the multi-threads, through the allocated thread Executing a transaction operation corresponding to the order transaction request;

The callback module 53 is further configured to:

The back-end server of the embodiment of the present application adopts asynchronous processing, and further asynchronously processes the order transaction request by starting multiple threads, thereby effectively improving the overall processing efficiency of the order transaction request.

Optionally, the device further includes:

The filtering module 56 is configured to obtain the revenue data generated during the execution of the transaction operation, and filter the revenue data;

The fragment generation module 57 is configured to start reading and writing dual threads, and the read profit data is read into the memory queue by reading the thread, and the profit data is read from the memory queue and written to the revenue through the write thread in parallel. In the file fragment;

The segment uploading module 58 is configured to upload the revenue file segment to the front end device whenever the revenue file segment is written.

Here, the embodiment of the present application splits the income file into several segments, and sets the size of each revenue file segment to be smaller than the revenue file. In the process of executing the transaction operation corresponding to the order transaction request, the generated revenue data is filled into the income file segment, and after being filled up, uploaded to the front-end device, and then begins to write a revenue file segment. Because the revenue file fragment is small, it facilitates the upload operation of the back-end server and facilitates the parsing operation of the front-end device, which effectively speeds up the processing speed of the front-end device on the revenue file. Further, when writing the profit file segment, the segment generation module 57 adopts the method of reading and writing dual threads, reading a row of revenue data by the read thread and writing to the specified queue, and the write thread synchronously reads from the specified queue. The income data is written into the income file fragment, and the read data and the write file are decoupled, so that when the income data is read, the income file fragment is almost finished. The generation time of the revenue file segment is equivalent to the reading time of the revenue data. Compared with the existing method of reading and writing synchronization, the time spent reading the data is the sum of the data time and the file time, which greatly speeds up the generation of the revenue file segment. .

It should be noted that the terminal in the embodiment of the present application may be used to implement all the technical solutions in the foregoing method embodiments. It will be clearly understood by those skilled in the art that, for convenience and brevity of description, only the division of each functional unit and module described above is exemplified. In practical applications, the above functions may be assigned to different functional units according to needs. The module is completed by dividing the internal structure of the device into different functional units or modules to perform all or part of the functions described above. Each functional unit and module in the embodiment can be integrated into one processing unit, Each unit may exist physically separately, or two or more units may be integrated into one unit. The integrated unit may be implemented in the form of hardware or in the form of a software functional unit. In addition, the specific names of the respective functional units and modules are only for the purpose of facilitating mutual differentiation, and are not intended to limit the scope of protection of the present application. For the specific working process of the foregoing units and modules, reference may be made to the corresponding processes in the foregoing method embodiments, and details are not described herein again.

In the above embodiments, the descriptions of the various embodiments are different, and the parts that are not detailed or described in the specific embodiments may be referred to the related descriptions of other embodiments.

FIG. 6 is a schematic diagram of a terminal according to an embodiment of the present application. As shown in FIG. 6, the terminal 6 of this embodiment includes a processor 60, a memory 61, and computer readable instructions 62 stored in the memory 61 and executable on the processor 60. The steps in the method embodiment of the above-mentioned order asynchronous processing when the processor 60 executes the computer readable instructions 62, such as steps S101 to S102 shown in FIG. 1 and steps S201 to S203 shown in FIG. 2, FIG. Steps S1031 to S1032 are shown, and steps S401 to S406 shown in FIG. 4 are shown. Alternatively, the functions of the modules/units in the apparatus embodiment for implementing the above-described order asynchronous processing when the processor 60 executes the computer readable instructions 62, such as the functions of the modules 51 to 58 shown in FIG.

Illustratively, the computer readable instructions 62 may be partitioned into one or more modules/units that are stored in the memory 61 and executed by the processor 60, To complete this application. The one or more modules/units may be a series of computer readable instruction segments capable of performing a particular function for describing the execution of the computer readable instructions 62 in the terminal 6. For example, the computer readable instructions 62 may be divided into an order cache module, an order processing module, and a callback module, and the specific functions of each module are as follows:

Further, the computer readable instructions 62 can also be segmented:

An update module, configured to, after obtaining the transaction result, write back the subscription in the MongoDB database according to the transaction result Status information corresponding to a single transaction request.

Further, the request processing module may further include:

a startup unit for starting multithreading;

The callback module is also used to:

Further, the computer readable instructions 62 can also be segmented:

The terminal 6 can be a computing device such as a desktop computer, a notebook, a palmtop computer, and a cloud server. The terminal may include, but is not limited to, a processor 60, a memory 61. It will be understood by those skilled in the art that FIG. 6 is merely an example of the terminal 6, and does not constitute a limitation of the terminal 6, and may include more or less components than those illustrated, or combine some components, or different components, such as The terminal may also include an input/output device, a network access device, a bus, and the like.

The processor 60 may be a central processing unit (CPU), or may be another general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc. The general purpose processor may be a microprocessor or the processor or any conventional processor or the like, which is a control center of the terminal, and connects various parts of the entire terminal using various interfaces and lines.

The memory 61 can be used to store the computer readable instructions and/or modules by running or executing computer readable instructions and/or modules stored in the memory, and recalling data stored in the memory Implementing various functions of the terminal. The memory may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application required for at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may be stored. Data created based on the use of the terminal, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory such as a hard disk, a memory, a plug-in hard disk, a smart memory card (Smart Media) Card, SMC), Secure Digital (SD), Flash Card, at least one disk storage device, flash memory device or other volatile solid-state storage device.

Those of ordinary skill in the art will appreciate that the elements and algorithm steps of the various examples described in connection with the embodiments disclosed herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the solution. A person skilled in the art can use different methods to implement the described functions for each particular application, but such implementation should not be considered to be beyond the scope of the present application.

In the embodiments provided by the present application, it should be understood that the disclosed apparatus/terminal and method may be implemented in other manners. For example, the device/terminal device embodiments described above are merely illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be another division manner, for example, multiple units. Or components may be combined or integrated into another system, or some features may be omitted or not performed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be in electrical, mechanical or other form.

The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

The integrated modules/units, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium. Based on such understanding, the present application implements all or part of the processes in the foregoing embodiments, and may also be implemented by computer readable instructions, which may be stored in a computer readable storage medium. The computer readable instructions, when executed by a processor, may implement the steps of the various method embodiments described above. Wherein, the computer readable instructions comprise computer readable instruction code, which may be in the form of source code, an object code form, an executable file or some intermediate form or the like. The computer readable storage medium may include any entity or device capable of carrying the computer readable instruction code, a recording medium, a USB flash drive, a removable hard disk, a magnetic disk, an optical disk, a computer memory, a read only memory (ROM, Read- Only Memory), Random Access Memory (RAM), electrical carrier signals, telecommunications signals, and software distribution media. It should be noted that the content contained in the computer readable storage medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in a jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, computer readable The storage medium does not include an electrical carrier signal and a telecommunication signal.

The above-mentioned embodiments are only used to explain the technical solutions of the present application, and are not limited thereto; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still implement the foregoing embodiments. The technical solutions described in the examples are modified or equivalently replaced with some of the technical features; and the modifications or substitutions do not deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in Within the scope of protection of this application.

Claims

A method for asynchronously processing an order, the method comprising:

Receiving the order transaction request sent by the front-end device, buffering the order transaction request into the message queue, and sending a response message to the front-end device to notify the front-end device that the order transaction request has been successfully received;

Reading an order transaction request from the message queue in a first-in first-out order, executing a transaction operation corresponding to the order transaction request, and obtaining a transaction result;

Acquiring the transaction result, and returning the uniform resource locator provided by the front-end device to return the transaction result to the front-end device, to inform the front-end device that the order transaction request has been successfully executed and the corresponding transaction result.
The method of processing an order asynchronous process according to claim 1, wherein before the buffering the order transaction request to the message queue, the method further comprises:

Saving the order transaction request to the MongoDB database;

After obtaining the transaction result, the method further includes:

And returning status information corresponding to the order transaction request in the MongoDB database according to the transaction result.
The method for asynchronous processing of an order according to claim 1, wherein said reading an order transaction request from said message queue in a first-in first-out order, executing a transaction operation corresponding to said order transaction request, and obtaining a transaction result include:

Start multithreading;

Reading an order transaction request from the message queue in a first-in first-out order, and allocating the read order transaction request to one of the multi-threads, and executing the order transaction request by the allocated thread Trading operation

Returning the transaction result to the front-end device by using the uniform resource locator provided by the callback front-end device includes:

After the transaction request is processed, the uniform resource locator provided by the front-end device is returned by each thread to return the transaction result of the processed order transaction request to the front-end device.
The method for asynchronous processing of an order according to claim 2, wherein said reading an order transaction request from said message queue in a first-in first-out order, executing a transaction operation corresponding to said order transaction request, and obtaining a transaction result include:

Start multithreading;

Reading an order transaction request from the message queue in a first-in first-out order, and allocating the read order transaction request to one of the multi-threads, and executing the order transaction request by the allocated thread Trading operation

Returning the transaction result to the front-end device by using the uniform resource locator provided by the callback front-end device includes:

After the transaction request is processed, the uniform resource locator provided by the front-end device is returned by each thread to return the transaction result of the processed order transaction request to the front-end device.
The method for asynchronous processing of an order according to claim 3 or 4, wherein after the order transaction request is read from the message queue in a first-in first-out order, and the transaction operation corresponding to the order transaction request is executed, The method also includes:

Obtaining revenue data generated during the execution of the transaction operation, and filtering the revenue data;

Starting to read and write dual threads, reading the filtered profit data through the read thread to write to the memory queue, and simultaneously reading the profit data from the memory queue through the write thread into the income file segment;

The revenue file segment is uploaded to the front end device whenever a revenue file segment is written.
An apparatus for asynchronously processing an order, wherein the apparatus comprises:

An order cache module, configured to: when receiving an order transaction request sent by the front-end device, buffer the order transaction request into a message queue, and send a response message to the front-end device to notify the front-end device of the order transaction The request has been successfully received;

An order processing module, configured to read an order transaction request from the message queue in a first-in first-out order, execute a transaction operation corresponding to the order transaction request, and obtain a transaction result;

a callback module, configured to obtain the transaction result, and the uniform resource locator provided by the callback front end device returns the transaction result to the front end device to notify the front end device that the order transaction request has been successfully executed and the corresponding transaction result.
The device for asynchronously processing an order according to claim 6, wherein the device further comprises:

a storage module, configured to save the order transaction request to a MongoDB database before caching the order transaction request to a message queue;

And an update module, configured to, after obtaining the transaction result, write back status information corresponding to the order transaction request in the MongoDB database according to the transaction result.
The apparatus for asynchronously processing an order according to claim 6, wherein the request processing module comprises:

a startup unit for starting multithreading;

a multi-thread processing unit, configured to read an order transaction request from the message queue in a first-in first-out order, and allocate the read order transaction request to one of the multi-threads, and execute through the allocated thread The transaction operation corresponding to the order transaction request;

The callback module is also used to:

After the transaction request is processed, each thread will call back the uniform resource locator provided by the front-end device to process the processed The transaction result of the order transaction request is returned to the front end device.
The apparatus for asynchronously processing an order according to claim 7, wherein the request processing module comprises:

a startup unit for starting multithreading;

a multi-thread processing unit, configured to read an order transaction request from the message queue in a first-in first-out order, and allocate the read order transaction request to one of the multi-threads, and execute through the allocated thread The transaction operation corresponding to the order transaction request;

The callback module is also used to:

After the transaction request is processed, the uniform resource locator provided by the front-end device is returned by each thread to return the transaction result of the processed order transaction request to the front-end device.
The device for asynchronously processing an order according to claim 8 or 9, wherein the device further comprises:

a filtering module, configured to obtain revenue data generated during execution of the transaction operation, and filter the revenue data;

a fragment generation module, configured to start reading and writing dual threads, and reading the filtered profit data by reading the thread to write to the memory queue, and simultaneously reading the profit data from the memory queue and writing the income data to the income file through the write thread in parallel In the fragment;

The segment uploading module is configured to upload the revenue file segment to the front end device whenever the profit file segment is written.
A computer readable storage medium having stored thereon computer readable instructions, wherein the computer readable instructions are executed by a processor to:

Receiving the order transaction request sent by the front-end device, buffering the order transaction request into the message queue, and sending a response message to the front-end device to notify the front-end device that the order transaction request has been successfully received;

Reading an order transaction request from the message queue in a first-in first-out order, executing a transaction operation corresponding to the order transaction request, and obtaining a transaction result;

Acquiring the transaction result, and returning the uniform resource locator provided by the front-end device to return the transaction result to the front-end device, to inform the front-end device that the order transaction request has been successfully executed and the corresponding transaction result.
The computer readable storage medium of claim 11, wherein the buffering the order transaction request to a message queue further comprises:

Saving the order transaction request to the MongoDB database;

After obtaining the transaction result, the method further includes:

And returning status information corresponding to the order transaction request in the MongoDB database according to the transaction result.
The computer readable storage medium according to claim 11, wherein said reading an order transaction request from said message queue in a first in first out order, executing a transaction operation corresponding to said order transaction request, and obtaining a transaction result , including:

Start multithreading;

Reading an order transaction request from the message queue in a first-in first-out order, and allocating the read order transaction request to one of the multi-threads, and executing the order transaction request by the allocated thread Trading operation

The uniform resource locator provided by the callback front-end device returns the transaction result to the front-end device, including:

After the transaction request is processed, the uniform resource locator provided by the front-end device is returned by each thread to return the transaction result of the processed order transaction request to the front-end device.
The computer readable storage medium according to claim 12, wherein said reading an order transaction request from said message queue in a first in first out order, executing a transaction operation corresponding to said order transaction request, and obtaining a transaction result ,include:

Start multithreading;

Reading an order transaction request from the message queue in a first-in first-out order, and allocating the read order transaction request to one of the multi-threads, and executing the order transaction request by the allocated thread Trading operation

The uniform resource locator provided by the callback front-end device returns the transaction result to the front-end device, including:

After the transaction request is processed, the uniform resource locator provided by the front-end device is returned by each thread to return the transaction result of the processed order transaction request to the front-end device.
The computer readable storage medium according to claim 13 or 14, wherein said reading an order transaction request from said message queue in a first in first out order, executing a transaction operation corresponding to said order transaction request, and thereafter Also includes:

Obtaining revenue data generated during the execution of the transaction operation, and filtering the revenue data;

Starting to read and write dual threads, reading the filtered profit data through the read thread to write to the memory queue, and simultaneously reading the profit data from the memory queue through the write thread into the income file segment;

The revenue file segment is uploaded to the front end device whenever a revenue file segment is written.
A terminal comprising a memory, a processor, and computer readable instructions stored on the memory and operable on the processor, wherein the processor, when executing the computer readable instructions, implements the following steps:

Receiving the order transaction request sent by the front-end device, buffering the order transaction request into the message queue, and sending a response message to the front-end device to notify the front-end device that the order transaction request has been successfully received;

Reading an order transaction request from the message queue in a first-in first-out order, executing a transaction operation corresponding to the order transaction request, and obtaining a transaction result;

Obtaining the transaction result, and returning the uniform resource locator provided by the front-end device to return the transaction result to the a front-end device to inform the front-end device that the order transaction request has been successfully executed and the corresponding transaction result.
The terminal according to claim 16, wherein said buffering said order transaction request to a message queue further comprises:

Saving the order transaction request to the MongoDB database;

After obtaining the transaction result, the method further includes:

And returning status information corresponding to the order transaction request in the MongoDB database according to the transaction result.
The terminal according to claim 16, wherein the reading an order transaction request from the message queue in a first-in first-out order, executing a transaction operation corresponding to the order transaction request, and obtaining a transaction result, including:

Start multithreading;

Reading an order transaction request from the message queue in a first-in first-out order, and allocating the read order transaction request to one of the multi-threads, and executing the order transaction request by the allocated thread Trading operation

The uniform resource locator provided by the callback front-end device returns the transaction result to the front-end device, including:

After the transaction request is processed, the uniform resource locator provided by the front-end device is returned by each thread to return the transaction result of the processed order transaction request to the front-end device.
The terminal according to claim 17, wherein the order transaction request is read from the message queue in a first-in-first-out order, and the transaction operation corresponding to the order transaction request is executed to obtain a transaction result, including:

Start multithreading;

Reading an order transaction request from the message queue in a first-in first-out order, and allocating the read order transaction request to one of the multi-threads, and executing the order transaction request by the allocated thread Trading operation

The uniform resource locator provided by the callback front-end device returns the transaction result to the front-end device, including:

After the transaction request is processed, the uniform resource locator provided by the front-end device is returned by each thread to return the transaction result of the processed order transaction request to the front-end device.
The terminal according to claim 18 or 19, wherein the order transaction request is read from the message queue in a first-in first-out order, and the transaction operation corresponding to the order transaction request is executed, and further includes:

Obtaining revenue data generated during the execution of the transaction operation, and filtering the revenue data;

Starting to read and write dual threads, reading the filtered profit data through the read thread to write to the memory queue, and simultaneously reading the profit data from the memory queue through the write thread into the income file segment;

The revenue file segment is uploaded to the front end device whenever a revenue file segment is written.