WO2020062793A1 - 基于消息队列的请求处理方法、装置、设备及存储介质 - Google Patents

基于消息队列的请求处理方法、装置、设备及存储介质 Download PDF

Info

Publication number
WO2020062793A1
WO2020062793A1 PCT/CN2019/077913 CN2019077913W WO2020062793A1 WO 2020062793 A1 WO2020062793 A1 WO 2020062793A1 CN 2019077913 W CN2019077913 W CN 2019077913W WO 2020062793 A1 WO2020062793 A1 WO 2020062793A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
server
requested
preset
servers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2019/077913
Other languages
English (en)
French (fr)
Inventor
王强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ping An Technology Shenzhen Co Ltd
Original Assignee
Ping An Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ping An Technology Shenzhen Co Ltd filed Critical Ping An Technology Shenzhen Co Ltd
Publication of WO2020062793A1 publication Critical patent/WO2020062793A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5011—Pool
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5018—Thread allocation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/548—Queue

Definitions

  • the present application relates to the field of Internet technologies, and in particular, to a method, an apparatus, a device, and a storage medium for request processing based on a message queue.
  • the structure of the traditional billing system can no longer meet the current business needs.
  • asynchronous processing is adopted for non-main flow functions, such as the uploading of credential images and the generation of application forms.
  • the asynchronous task processing method usually adopts data lock read when reading data from the database. With less traffic and fewer thread pools open, the traditional architecture is fine.
  • the business volume grows and more threads need to be opened to digest the task data, the way to lock and read the task data will cause the database lock to wait, which will cause a bottleneck in the database, threads waiting, and inefficient processing. Set the current business volume Problems such as failure to complete in time.
  • the message queue is used to synchronously notify the second server to process the message, and the server can be processed Separation and separation from the database to improve system operation efficiency.
  • a first aspect of the present application provides a method for processing a request based on a message queue.
  • the method includes:
  • the user request When a user request is received, the user request is encapsulated into a corresponding message according to a preset message format
  • a corresponding thread pool is established by the filtered second server to process the message.
  • a second aspect of the present application provides a request processing device based on a message queue, where the device includes:
  • An encapsulation module configured to encapsulate the user request into a corresponding message according to a preset message format when a user request is received;
  • a sending module configured to send the encapsulated message to a first server, where the message carries a location identification number, a requested service type, and a requested service quantity;
  • a storage module configured to store the message in the message queue of the first server through the first server according to the location identification number
  • the sending module is further configured to simultaneously synchronize the message to multiple second servers through the first server;
  • a screening module configured to screen, based on the current loads of the plurality of second servers, a second server whose current load is lower than a preset load threshold among the plurality of second servers;
  • a processing module is configured to establish a corresponding thread pool through the filtered second server to process the message according to the requested service type and the requested service quantity.
  • a third aspect of the present application provides a device including a processor and a memory, where the processor is configured to implement the message queue-based request processing method when executing computer-readable instructions stored in the memory.
  • a fourth aspect of the present application provides a non-volatile readable storage medium.
  • Computer-readable instructions are stored on the non-volatile readable storage medium, and the computer-readable instructions are implemented when executed by a processor. Request processing method based on message queue.
  • the message queue-based request processing method, device, device, and storage medium described in this application when receiving a user request, encapsulate the user request into a corresponding message according to a preset message format; and send the encapsulated message To the first server, the message carries a location identification number, a requested service type, and a requested number of services; and according to the location identification number, the message is stored in the first server by the first server.
  • the messages are synchronized to multiple second servers through the first server at the same time; and based on the current loads of the multiple second servers, it is filtered out in the multiple second servers that the current load is lower than A second server with a preset load threshold; according to the requested service type and the requested number of services, a corresponding thread pool is established by the filtered second server to process the message.
  • This application introduces the message queue in the first server, and uses the message queue to synchronously notify the second server to process the message, which can separate the server, separate from the database, and improve the efficiency of system operation.
  • the corresponding threads are created according to the pending messages in the message queue, and the size of the thread pool is dynamically configured to separate the producer from the consumer, which can effectively prevent the system from being paralyzed due to excessive data request pressure during high concurrency.
  • the first server compares the length of the message queue with a preset maximum threshold, and chooses to perform different operations according to the comparison result. This can quickly return the corresponding results to the user, save the user's waiting time, and improve the use of the user. Experience.
  • FIG. 1 is a flowchart of a message queue-based request processing method according to a first embodiment of the present application.
  • FIG. 2 is a functional module diagram of a message queue-based request processing apparatus according to a second embodiment of the present application.
  • FIG. 3 is a schematic diagram of a device provided in Embodiment 3 of the present application.
  • the message queue-based request processing method in the embodiment of the present application is applied in a hardware environment composed of a device and a server connected to the device through a network, and is jointly executed by the server and the device.
  • Networks include, but are not limited to: wide area networks, metropolitan area networks, or local area networks.
  • the device may be a computing device such as a desktop computer, a notebook, a palmtop computer, and a cloud server.
  • the server may include a first server and a second server, wherein the first server may be a message queue server.
  • the message queue server refers to a computer that provides message queues, routing, and directory services for client computers.
  • the second server may be a server that processes messages.
  • the device is connected to the first server and the second server through a network communication.
  • the device receives a user's request, it sends a message to the first server, and the first server stores the message in its own message queue.
  • the first server also synchronously sends the message to the second server, and the second server performs a corresponding operation according to the message. That is, the message queue is used to synchronously notify the second server to process the message, thereby separating the first server from the second server, and separating from the device's own database, thereby improving the efficiency of system operation.
  • the message queue-based request processing function provided by the method of the present application may be directly integrated on the electronic device, or a client for implementing the method of the present application may be installed.
  • the method provided in this application can also be run on a device such as a server in the form of Software Development Kit (SDK), and provide the interface of the request processing function based on message queue in the form of SDK, server or other The device can implement the request processing function based on the message queue through the provided interface.
  • SDK Software Development Kit
  • FIG. 1 is a flowchart of a message queue-based request processing method according to a first embodiment of the present application. According to different requirements, the execution order in this flowchart can be changed, and some steps can be omitted.
  • a user may send a request through a device, where the device refers to an electronic device having data processing capabilities, such as a client computer.
  • User requests can include, but are not limited to: registration, login, uploading credentials, or applying for insurance.
  • the system After the system receives the user request, the system encapsulates the user request into a corresponding message according to a preset message format. For example, after receiving the user's registration request, the system encapsulates the registration request into a corresponding registration message according to a preset message format; after receiving the user's login request, the system encapsulates the login request according to a preset message format Into the corresponding login message; after receiving the user's request for uploading a certificate, the system encapsulates the request for uploading a certificate into a corresponding message for uploading a certificate according to a preset message format; after receiving the user's request for insurance, the system The format encapsulates the insurance application request into a corresponding insurance application message.
  • encapsulating the user request into a corresponding message according to a preset message format may include:
  • the encapsulated http request or https request is encapsulated into a corresponding message according to the http request protocol.
  • the preset message format may include information such as a message type, a message version, a message length, and a message entity.
  • the user requests can be unified, which is convenient for system management and processing.
  • S12 Send the encapsulated message to the first server, where the message carries a location identification number, a requested service type, and a requested number of services.
  • the first server may be a message queue server.
  • the message queue server refers to a computer that provides message queues, routing, and directory services for client computers.
  • the encapsulated message may also carry a location identification number and parameter information.
  • the location identification number is used to indicate the location information of the stored message queue. For example, when the location identification number is 1, it indicates that the message is stored in a first message queue of the first server. When the location identification number is 2, it indicates that the message is stored in a second message queue of the first server.
  • the parameter information may include: a type of the requested service, a quantity of the requested service, and the like.
  • the requested service type refers to a requested service type, and the requested service quantity refers to a thread pool that needs to be established when processing a service corresponding to the requested service type.
  • S13 Store the message in the message queue of the first server through the first server according to the location identification number, and simultaneously synchronize the message to multiple second servers through the first server.
  • the message when the first server receives a message, the message is stored in a message queue of the first server according to the location identification number.
  • the location identification number indicates the location information of the stored message queue, so the message can be directly stored in the message queue corresponding to the location identification number according to the location identification number.
  • the first server when the first server receives a registration message, the first server stores the message in a first message queue according to the location identification number "1" carried in the registration message; the first server receives When logging in the message, the message is stored in the second message queue according to the location identification number "2" carried in the registration message; when the first server receives the uploading credential message, it is based on the registration message
  • the carried location identification number "3" stores the message in a third message queue; when the first server receives the insurance message, the first server stores the message according to the location identification number "4" carried in the insurance message.
  • the message is stored in a fourth message queue.
  • the first server may synchronously send the received message to a plurality of second servers.
  • the first server may also synchronize the messages stored in the message queue to multiple second servers every preset time period. That is, the messages stored in the message queue during the previous preset time period are synchronized to multiple second servers in the current preset time period.
  • the preset time period may be 2 hours or 1 day. Exemplarily, assuming that the preset time period is 1 day, the first server synchronizes the messages stored in the message queue on the first day to multiple second servers on the second day, and the first server synchronizes the first The messages stored in the message queue for 2 days are synchronized to a plurality of second servers.
  • the plurality of second servers may be servers that process messages.
  • the first server may further include:
  • a second preset operation is performed and the message is synchronized to a second server.
  • the first preset operation may be one or a combination of the following:
  • the second preset operation may be: in response to a user request, returning a result of a successful message reception to the user.
  • the first server compares the length of the message queue with a preset maximum threshold, and chooses to perform different operations according to the comparison result. This can quickly return the corresponding results to the user, save the user's waiting time, and improve the user's use Experience.
  • multiple second servers may be set up in a cluster manner.
  • the first server sends a message to the second server
  • the current load of the plurality of second servers is obtained, and then the second server whose current load is lower than a preset load threshold is selected from the plurality of second servers.
  • the preset load threshold is a preset load threshold, which refers to the optimal load strength that the second server can handle.
  • the load balancing device of the cluster When the message is sent to the second server through the first server, the load balancing device of the cluster is first used to select a second server with a low load balance to process the corresponding request according to the load situation of each second server. For the second server whose current load balancing is high, the message is not processed. Messages can be automatically distributed to a second server with a low load, which facilitates load balancing of the second server.
  • the processing of the message by establishing a corresponding thread pool by the second server according to the requested service type and the requested service quantity includes:
  • the second server may be pre-configured with a configuration table corresponding to the message and a corresponding requested service type.
  • the configuration table may include information such as a system service name, a system service physical route, a system service subsequent process condition code, and a condition code corresponding to the subsequent service required to complete the data request. Parsing the message is to retrieve the configuration table, interpret the content to determine the specific service content, and determine the system service name, the system service physical route, the subsequent process condition code, and the condition code corresponding to the subsequent service.
  • the second server responds to the http request corresponding to the message and performs a corresponding operation.
  • the second server establishes a corresponding thread pool to process the message according to the requested number of services.
  • One message queue corresponds to one thread pool, and each thread pool consumes the waiting time in the corresponding message queue.
  • Processed messages different thread pools do not interfere with each other. For example, thread pool 1 is only responsible for consuming pending messages in the first message queue, and thread pool 2 is only responsible for consuming pending messages in the second message queue.
  • Establishing a corresponding thread pool according to the number of requested services can implement different concurrency control according to the number of requested services in the message, thereby effectively saving resources and further improving the efficiency of message processing.
  • processing the message through the thread pool according to the service type may include one or a combination of the following:
  • the filtered second server When identifying that the requested service type in the message is registration, the filtered second server records the registration information corresponding to the user request in a preset database.
  • the second server that is filtered out matches the user name and password input corresponding to the user request with the user name in the preset database And password to match, and after the match is successful, the login interface is displayed.
  • the filtered second server When identifying that the requested service type in the message is uploading a credential, the filtered second server reads the credential in the preset database and completes the uploading operation.
  • the filtered second server When identifying that the requested service type in the message is insurance, the filtered second server reads the corresponding content in the preset database and generates an insurance policy.
  • the preset database is a pre-set read-only database.
  • the read-only database refers to a database with only read permission.
  • the read-only database can hold a large amount of data and can prevent the data from being tampered with.
  • a configuration policy may be set in the first server in advance, and different messages are encapsulated into different requests and then sent to the second server.
  • a redis anti-duplication mechanism can also be introduced in the second server. The redis anti-duplication mechanism is an existing technology, and will not be repeated here.
  • the anti-duplication mechanism is that when the second service executes a message, it first queries whether the primary key of the message corresponding to redis has been successfully executed. If the primary key of the message corresponding to redis is successfully executed, it does not pass the second server according to the message Perform a corresponding operation; if there is no query record of the message primary key corresponding to redis being executed, perform the corresponding operation according to the message by the second server, and write the corresponding message primary key to redis after the execution is successful.
  • the message queue-based request processing method described in the embodiments of the present application when a user request is received, the user request is encapsulated into a corresponding message according to a preset message format; the encapsulated message is Send to the first server, the message carries a location identification number, the type of service requested, and the number of services requested; and according to the location identification number, the message is stored in the first server by the first server
  • the messages are simultaneously synchronized to the plurality of second servers through the first server; and based on the current loads of the plurality of second servers, the current load is selected from the plurality of second servers.
  • This application introduces the message queue in the first server, and uses the message queue to synchronously notify the second server to process the message, which can separate the server, separate from the database, and improve the efficiency of system operation.
  • the corresponding threads are created according to the pending messages in the message queue, and the size of the thread pool is dynamically configured to separate the producer from the consumer, which can effectively prevent the system from being paralyzed due to excessive data request pressure during high concurrency. The problem occurred.
  • the first server compares the length of the message queue with a preset maximum threshold, and chooses to perform different operations according to the comparison result. This can quickly return the corresponding results to the user, save the user's waiting time, and improve the use of the user. Experience.
  • FIG. 2 is a functional module diagram of a preferred embodiment of a request processing device based on a message queue in the present application.
  • the message queue-based request processing device 20 runs in a server.
  • the message queue-based request processing apparatus 20 may include a plurality of function modules composed of program code segments.
  • the program code of each program segment in the message queue-based request processing device 20 may be stored in a memory and executed by at least one processor to execute (see FIG. 1 and related description for details) a message queue-based request Method of processing.
  • the message queue-based request processing apparatus 20 may be divided into a plurality of functional modules according to functions performed by the request processing apparatus 20.
  • the functional modules may include: a packaging module 201, a sending module 202, a storage module 203, a determination module 204, an execution module 205, a screening module 206, and a processing module 207.
  • the module referred to in the present application refers to a series of computer-readable instruction segments that can be executed by at least one processor and can perform fixed functions, which are stored in a memory. In some embodiments, functions of each module will be described in detail in subsequent embodiments.
  • the encapsulation module 201 is configured to encapsulate a user request into a corresponding message according to a preset message format when a user request is received.
  • a user may send a request through a device, where the device refers to an electronic device having data processing capabilities, such as a client computer.
  • User requests can include, but are not limited to: registration, login, uploading credentials, or applying for insurance.
  • the system After the system receives the user request, the system encapsulates the user request into a corresponding message according to a preset message format. For example, after receiving the user's registration request, the system encapsulates the registration request into a corresponding registration message according to a preset message format; after receiving the user's login request, the system encapsulates the login request according to a preset message format Into the corresponding login message; after receiving the user's request for uploading a certificate, the system encapsulates the request for uploading a certificate into a corresponding message for uploading a certificate according to a preset message format; after receiving the user's request for insurance, the system according to a preset message The format encapsulates the insurance application request into a corresponding insurance application message.
  • encapsulating the user request into a corresponding message according to a preset message format may include:
  • the encapsulated http request or https request is encapsulated into a corresponding message according to the http request protocol.
  • the preset message format may include information such as a message type, a message version, a message length, and a message entity.
  • the user requests can be unified, which is convenient for system management and processing.
  • the sending module 202 is configured to send the encapsulated message to the first server, where the message carries a location identification number, a requested service type, and a requested service quantity.
  • the first server may be a message queue server.
  • the message queue server refers to a computer that provides message queues, routing, and directory services for client computers.
  • the encapsulated message may also carry a location identification number and parameter information.
  • the location identification number is used to indicate the location information of the stored message queue. For example, when the location identification number is 1, it indicates that the message is stored in a first message queue of the first server. When the location identification number is 2, it indicates that the message is stored in a second message queue of the first server.
  • the parameter information may include: a type of the requested service, a quantity of the requested service, and the like.
  • the requested service type refers to a requested service type, and the requested service quantity refers to a thread pool that needs to be established when processing a service corresponding to the requested service type.
  • the storage module 203 is configured to store the message in the message queue of the first server through the first server according to the location identification number.
  • the sending module 202 is further configured to synchronize the message to multiple second servers through the first server.
  • the message when the first server receives a message, the message is stored in a message queue of the first server according to the location identification number.
  • the location identification number indicates the location information of the stored message queue, so the message can be directly stored in the message queue corresponding to the location identification number according to the location identification number.
  • the first server when the first server receives a registration message, the first server stores the message in a first message queue according to the location identification number "1" carried in the registration message; the first server receives When logging in the message, the message is stored in the second message queue according to the location identification number "2" carried in the registration message; when the first server receives the uploading credential message, it is based on the registration message The carried location identification number "3" stores the message in a third message queue; when the first server receives the insurance message, the first server The message is stored in a fourth message queue.
  • the first server may synchronously send the received message to a plurality of second servers.
  • the first server may also synchronize the messages stored in the message queue to multiple second servers every preset time period. That is, the messages stored in the message queue during the previous preset time period are synchronized to multiple second servers in the current preset time period.
  • the preset time period may be 2 hours or 1 day. Exemplarily, assuming that the preset time period is 1 day, the first server synchronizes the messages stored in the message queue on the first day to multiple second servers on the second day, and the first server synchronizes the first The messages stored in the message queue for 2 days are synchronized to a plurality of second servers.
  • the plurality of second servers may be servers that process messages.
  • the message queue-based request processing apparatus 20 may further include:
  • the determining module 204 is configured to determine whether the length of the message queue exceeds a preset maximum threshold.
  • An execution module 205 is configured to perform a first preset operation when the determining module 204 determines that the length of the message queue exceeds the preset maximum threshold;
  • the execution module 205 is further configured to perform a second preset operation and synchronize the message to a second server when the determination module 204 determines that the length of the message queue does not exceed the preset maximum threshold.
  • the first preset operation may be one or a combination of the following:
  • the second preset operation may be: in response to a user request, returning a result of a successful message reception to the user.
  • the first server compares the length of the message queue with a preset maximum threshold, and chooses to perform different operations according to the comparison result. This can quickly return the corresponding results to the user, save the user's waiting time, and improve the user's use. Experience.
  • a screening module 206 is configured to screen, based on the current loads of the plurality of second servers, a second server whose current load is lower than a preset load threshold among the plurality of second servers.
  • multiple second servers may be set up in a cluster manner.
  • the first server sends a message to the second server
  • the current load of the plurality of second servers is obtained, and then the second server whose current load is lower than a preset load threshold is selected from the plurality of second servers.
  • the preset load threshold is a preset load threshold, which refers to the optimal load strength that the second server can handle.
  • the load balancing device of the cluster When sending a message to the second server through the first server, the load balancing device of the cluster is first used to select a second server with a low load balance to process the corresponding request according to the load situation of each second server. For the second server whose current load balancing is high, the message is not processed. Messages can be automatically distributed to a second server with a low load, which facilitates load balancing of the second server.
  • the processing module 207 is configured to establish a corresponding thread pool through the filtered second server to process the message according to the requested service type and the requested service quantity.
  • the processing module 207 establishes a corresponding thread pool through the second server to process the message according to the requested service type and the requested service quantity, including:
  • the second server may be pre-configured with a configuration table corresponding to the message and a corresponding requested service type.
  • the configuration table may include information such as a system service name, a system service physical route, a system service subsequent process condition code, and a condition code corresponding to the subsequent service required to complete the data request. Parsing the message is to retrieve the configuration table, interpret the content to determine the specific service content, and determine the system service name, the system service physical route, the subsequent process condition code, and the condition code corresponding to the subsequent service.
  • the second server establishes a corresponding thread pool to process the message according to the requested number of services.
  • One message queue corresponds to one thread pool, and each thread pool consumes the waiting time in the corresponding message queue.
  • Processed messages different thread pools do not interfere with each other. For example, thread pool 1 is only responsible for consuming pending messages in the first message queue, and thread pool 2 is only responsible for consuming pending messages in the second message queue.
  • Establishing a corresponding thread pool according to the number of requested services can implement different concurrency control according to the number of requested services in the message, thereby effectively saving resources and further improving the efficiency of message processing.
  • processing the message through the thread pool according to the service type may include one or a combination of the following:
  • the filtered second server When identifying that the requested service type in the message is registration, the filtered second server records the registration information corresponding to the user request in a preset database.
  • the second server that is filtered out matches the user name and password input corresponding to the user request with the user name in the preset database And password to match, and after the match is successful, the login interface is displayed.
  • the filtered second server When identifying that the requested service type in the message is uploading a credential, the filtered second server reads the credential in the preset database and completes the uploading operation.
  • the filtered second server When identifying that the requested service type in the message is insurance, the filtered second server reads the corresponding content in the preset database and generates an insurance policy.
  • the preset database is a pre-set read-only database.
  • the read-only database refers to a database with only read permission.
  • the read-only database can hold a large amount of data and can prevent the data from being tampered with.
  • a configuration policy may be set in the first server in advance, and different messages are encapsulated into different requests and then sent to the second server.
  • a redis anti-duplication mechanism can also be introduced in the second server. The redis anti-duplication mechanism is an existing technology, and will not be repeated here.
  • the anti-duplication mechanism is that when the second service executes a message, it first queries whether the primary key of the message corresponding to redis has been successfully executed. If the primary key of the message corresponding to redis is successfully executed, it does not pass the second server according to the message Perform a corresponding operation; if there is no query record of the message primary key corresponding to redis being executed, perform the corresponding operation according to the message by the second server, and write the corresponding message primary key to redis after the execution is successful.
  • the message queue-based request processing device described in the embodiment of the present application when receiving a user request, encapsulates the user request into a corresponding message according to a preset message format; the encapsulated message Send to the first server, the message carries a location identification number, the type of service requested, and the number of services requested; and according to the location identification number, the message is stored in the first server by the first server
  • the messages are simultaneously synchronized to the plurality of second servers through the first server; and based on the current loads of the plurality of second servers, the current load is selected from the plurality of second servers.
  • This application introduces the message queue in the first server, and uses the message queue to synchronously notify the second server to process the message, which can separate the server, separate from the database, and improve the efficiency of system operation.
  • the corresponding threads are created according to the pending messages in the message queue, and the size of the thread pool is dynamically configured to separate the producer from the consumer, which can effectively prevent the system from being paralyzed due to excessive data request pressure during high concurrency. The problem occurred.
  • the first server compares the length of the message queue with a preset maximum threshold, and chooses to perform different operations according to the comparison result. This can quickly return the corresponding results to the user, save the user's waiting time, and improve the use of the user. Experience.
  • the above integrated unit implemented in the form of a software functional module may be stored in a non-volatile readable storage medium.
  • the above software function module is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a dual-screen device, or a network device) or a processor to execute the various embodiments described in this application. Part of the method.
  • FIG. 3 is a schematic diagram of a device provided in Embodiment 3 of the present application.
  • the device 3 includes a memory 31, at least one processor 32, computer-readable instructions 33 stored in the memory 31 and executable on the at least one processor 32, and at least one communication bus 34.
  • the steps in the embodiment of the method for processing a request based on a message queue are implemented.
  • the computer-readable instructions 33 may be divided into one or more modules / units, and the one or more modules / units are stored in the memory 31 and processed by the at least one processor 32 carried out.
  • the one or more modules / units may be a series of computer-readable instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer-readable instructions 33 in the device 3.
  • the device 3 may be a computing device such as a desktop computer, a notebook, a palmtop computer, and a cloud server.
  • a computing device such as a desktop computer, a notebook, a palmtop computer, and a cloud server.
  • the schematic diagram 3 is only an example of the device 3, and does not constitute a limitation on the device 3. It may include more or fewer parts than shown in the figure, or combine some parts or different parts.
  • the device 3 may further include an input-output device, a network access device, and a bus.
  • the at least one processor 32 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), and application-specific integrated circuits (ASICs). ), Ready-made programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • the processor 32 may be a microprocessor, or the processor 32 may be any conventional processor.
  • the processor 32 is a control center of the device 3, and uses various interfaces and lines to connect each of the entire device 3. section.
  • the memory 31 may be configured to store the computer-readable instructions 33 and / or modules / units, and the processor 32 may execute or execute the computer-readable instructions and / or modules / units stored in the memory 31, and Recalling the data stored in the memory 31, various functions of the device 3 are realized.
  • the memory 31 may mainly include a storage program area and a storage data area, where the storage program area may store an operating system, application programs required for at least one function (such as a sound playback function, an image playback function, etc.), etc .; the storage data area may Data (such as audio data, phone book, etc.) created according to the use of the device 3 are stored.
  • the memory 31 may include a high-speed random access memory, and may also include a non-volatile memory, such as a hard disk, an internal memory, a plug-in hard disk, a Smart Media Card (SMC), and a Secure Digital (SD). Card, flash memory card (Flash card), at least one disk storage device, flash memory device, or other volatile solid-state storage device.
  • a non-volatile memory such as a hard disk, an internal memory, a plug-in hard disk, a Smart Media Card (SMC), and a Secure Digital (SD).
  • SSD Secure Digital
  • flash memory card Flash card
  • flash memory device at least one disk storage device, flash memory device, or other volatile solid-state storage device.
  • the user request When a user request is received, the user request is encapsulated into a corresponding message according to a preset message format
  • a corresponding thread pool is established by the filtered second server to process the message.
  • the encapsulating the user request into a corresponding message according to a preset message format includes:
  • the encapsulated http request or the https request is encapsulated as a corresponding message according to the http request protocol.
  • the processor 32 is further configured to:
  • the processor 32 is further configured to:
  • the first preset operation is a combination of one or more of the following:
  • the second preset operation is: in response to a user request, returning a message to the user with a successful result of receiving the message.
  • processing of the message by establishing a corresponding thread pool by the second server according to the requested service type and the requested service quantity includes:
  • the processor 32 is further configured to:
  • the second server If there is no query record of the execution of the message primary key corresponding to redis, the second server performs a corresponding operation according to the message, and writes the corresponding message primary key into redis after the execution is successful.
  • the modules / units integrated in the device 3 When the modules / units integrated in the device 3 are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile readable storage medium. Based on this understanding, this application implements all or part of the processes in the methods of the above embodiments, and can also be completed by computer-readable instructions instructing related hardware.
  • the computer-readable instructions can be stored in a non-volatile memory. In the read storage medium, when the computer-readable instructions are executed by a processor, the steps of the foregoing method embodiments can be implemented.
  • the computer-readable instructions include computer-readable instruction codes, and the computer-readable instruction codes may be in a source code form, an object code form, an executable file, or some intermediate form.
  • the non-volatile readable medium may include: any entity or device capable of carrying the computer-readable instruction code, a recording medium, a U disk, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM, Read-Only Memory), Random Access Memory (RAM, Random Access Memory), electric carrier signals, telecommunication signals, and software distribution media.
  • ROM Read-Only Memory
  • RAM Random Access Memory
  • electric carrier signals telecommunication signals
  • telecommunication signals and software distribution media.
  • the content contained in the non-volatile readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdictions. For example, in some jurisdictions, according to legislation and patent practices, non- Volatile readable media does not include electrical carrier signals and telecommunication signals.
  • server and method may be implemented in other ways.
  • the server embodiments described above are only schematic.
  • the division of the units is only a logical function division. In actual implementation, there may be another division manner.
  • each functional unit in each embodiment of the present application may be integrated in the same processing unit, or each unit may exist separately physically, or two or more units may be integrated in the same unit.
  • the integrated unit can be implemented in the form of hardware, or in the form of hardware plus software functional modules.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

一种基于消息队列的请求处理方法、装置、设备及存储介质。该方法包括：当接收到用户请求时，将用户请求封装成相应的消息后发送至第一服务器；根据消息中的位置标识号，通过第一服务器将消息存储于消息队列中，同时通过第一服务器将消息同步至多个第二服务器；根据所述多个第二服务器当前的负载，筛选出当前的负载低于预设负载阈值的第二服务器；通过所筛选出的第二服务器建立相应的线程池处理消息。基于云传输技术，通过引入第一服务器中的消息队列，使用消息队列同步通知第二服务器对消息进行处理，能够进行服务器分离，脱离数据库，提升系统运行的效率。

Description

基于消息队列的请求处理方法、装置、设备及存储介质
本申请要求于2018年09月29日提交中国专利局，申请号为201811151515.6发明名称为“基于消息队列的请求处理方法、装置、设备及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及互联网技术领域，具体涉及一种基于消息队列的请求处理方法、装置、设备及存储介质。
背景技术
随着公司业务量越来越大，传统的出单系统的架构已经不能满足当前的业务需求。传统的架构中，针对非主流程的功能，例如证件影像上传，投保书生成等功能，均采取异步任务的处理方式。而且为了防止数据脏读，异步任务的处理方式从数据库中读取数据时通常采取数据加锁读取。在业务量少，开启的线程池少的情况下，传统的架构没有问题。但是一旦业务量增长，需要开启更多的线程来消化任务数据时，加锁读取任务数据的方式会造成数据库锁等待，从而导致数据库出现瓶颈、线程出现等待、处理效率低下，设置当前业务量无法及时完成等问题的发生。
发明内容
鉴于以上内容，有必要提出一种基于消息队列的请求处理方法、装置、设备及存储介质，通过引入第一服务器中的消息队列，使用消息队列同步通知第二服务器对消息进行处理，能够进行服务器分离，脱离数据库，提升系统运行效率。
本申请的第一方面提供一种基于消息队列的请求处理方法，所述方法包括：
当接收到用户请求时，根据预设报文格式将所述用户请求封装成相应的消息；
将封装后的消息发送至第一服务器，所述消息中携带有位置标识号、请求的服务类型及请求的服务数量；
根据所述位置标识号，通过所述第一服务器将所述消息存储于所述第一服务器的消息队列中，同时通过所述第一服务器将所述消息同步至多个第二服务器；
根据所述多个第二服务器当前的负载，在所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器；
根据所述请求的服务类型及请求的服务数量，通过所筛选出的第 二服务器建立相应的线程池对所述消息进行处理。
本申请的第二方面提供一种基于消息队列的请求处理装置，所述装置包括：
封装模块，用于当接收到用户请求时，根据预设报文格式将所述用户请求封装成相应的消息；
发送模块，用于将封装后的消息发送至第一服务器，所述消息中携带有位置标识号、请求的服务类型及请求的服务数量；
存储模块，用于根据所述位置标识号，通过所述第一服务器将所述消息存储于所述第一服务器的消息队列中；
所述发送模块，还用于同时通过所述第一服务器将所述消息同步至多个第二服务器；
筛选模块，用于根据所述多个第二服务器当前的负载，在所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器；
处理模块，用于根据所述请求的服务类型及请求的服务数量，通过所筛选出的第二服务器建立相应的线程池对所述消息进行处理。
本申请的第三方面提供一种设备，所述设备包括处理器和存储器，所述处理器用于执行所述存储器中存储的计算机可读指令时实现所述基于消息队列的请求处理方法。
本申请的第四方面提供一种非易失性可读存储介质，所述非易失性可读存储介质上存储有计算机可读指令，所述计算机可读指令被处理器执行时实现所述基于消息队列的请求处理方法。
本申请所述的基于消息队列的请求处理方法、装置、设备及存储介质，当接收到用户请求时，根据预设报文格式将所述用户请求封装成相应的消息；将封装后的消息发送至第一服务器，所述消息中携带有位置标识号、请求的服务类型及请求的服务数量；根据所述位置标识号，通过所述第一服务器将所述消息存储于所述第一服务器的消息队列中，同时通过所述第一服务器将所述消息同步至多个第二服务器；根据所述多个第二服务器当前的负载，在所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器；根据所述请求的服务类型及请求的服务数量，通过所筛选出的第二服务器建立相应的线程池对所述消息进行处理。本申请通过引入第一服务器中的消息队列，使用消息队列同步通知第二服务器对消息进行处理，能够进行服务器分离，脱离数据库，提升系统运行的效率。另外，根据消息队列中的待处理的消息创建相应的线程，并动态配置线程池的大小，做到了生产者和消费者相分离，能够有效的防止高并发时数据请求压力过大导致系统瘫痪的问题的发生。同时第一服务器对消息队列的长度与预设最大阈值之间进行比较，根据比较的结果选择执行不同的操作，如此可快速的向用户返回相应的结果，节省用户的等待时间，提升用户的使用体验。
附图说明
图1是本申请实施例一提供的基于消息队列的请求处理方法的流程图。
图2是本申请实施例二提供的基于消息队列的请求处理装置的功能模块图。
图3是本申请实施例三提供的设备的示意图。
如下具体实施方式将结合上述附图进一步说明本申请。
具体实施方式
本申请实施例的基于消息队列的请求处理方法应用在由设备和通过网络与所述设备进行连接的服务器所构成的硬件环境中，由服务器和设备共同执行。网络包括但不限于：广域网、城域网或局域网。
所述设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。
所述服务器可以包括：第一服务器及第二服务器，其中，第一服务器可以是消息队列服务器。所述消息队列服务器是指为客户端计算机提供消息队列、路由选择和目录服务的计算机。所述第二服务器可以是处理消息的服务器。
所述设备与第一服务器及第二服务器通过网络通讯连接，设备接收到用户的请求时，发送消息给第一服务器，由第一服务器将所述消息存储于自身的消息队列中，同时第一服务器还同步将所述消息发送至第二服务器，由第二服务器根据所述消息执行相应的操作。即使用消息队列同步通知第二服务器对消息进行处理，从而将第一服务器和第二服务器进行了分离，并脱离了设备自身的数据库，提升了系统运行的效率。所述对于需要进行基于消息队列的请求处理方法的电子设备，可以直接在电子设备上集成本申请的方法所提供的基于消息队列的请求处理功能，或者安装用于实现本申请的方法的客户端。再如，本申请所提供的方法还可以以软件开发工具包(Software Development Kit，SDK)的形式运行在服务器等设备上，以SDK的形式提供基于消息队列的请求处理功能的接口，服务器或其他设备通过提供的接口即可实现基于消息队列的请求处理功能。
实施例一
图1是本申请实施例一提供的基于消息队列的请求处理方法的流程图。根据不同的需求，该流程图中的执行顺序可以改变，某些步骤可以省略。
S11：当接收到用户请求时，根据预设报文格式将所述用户请求封装成相应的消息。
本实施例中，用户可以通过设备发送请求，所述设备是指具有数据处理能力的电子设备，例如客户端计算机。
用户请求可以包括，但不限于：注册，登录，上传证件或投保等。系统接收到所述用户请求后，根据预设报文格式将所述用户请求封装成相应的消息。例如，系统接收到用户的注册请求后，根据预设报文格式将所述注册请求封装成相应的注册消息；系统接收到用户的登录请求后，根据预设报文格式将所述登录请求封装成相应的登录消息；系统接收到用户的上传证件请求后，根据预设报文格式将所述上传证件请求封装成相应的上传证件消息；系统接收到用户的投保请求后，根据预设报文格式将所述投保请求封装成相应的投保消息。
本实施例中，根据预设报文格式将所述用户请求封装成相应的消息可以包括：
根据所述预设报文格式将所述用户请求封装为http请求或者https请求；
根据http请求协议将所封装的http请求或者https请求封装为相应的消息。
所述预设报文格式可以包括：报文类型、报文版本、报文长度及报文实体等信息。
通过接收用户请求并将用户请求按照预设报文格式进行封装可以使得用户请求变得统一，便于系统管理与处理。
S12：将封装后的消息发送至所述第一服务器，所述消息中携带有位置标识号、请求的服务类型及请求的服务数量。
所述第一服务器可以是消息队列服务器。所述消息队列服务器是指为客户端计算机提供消息队列、路由选择和目录服务的计算机。
本实施例中，封装后的消息中还可以携带有位置标识号和参数信息等。所述位置标识号用以表明存储的消息队列的位置信息。例如，位置标识号为1时，表明将所述消息存储于所述第一服务器的第一消息队列中。位置标识号为2时，表明将所述消息存储于所述第一服务器的第二消息队列中。所述参数信息可以包括：所述请求的服务类型及所述请求的服务数量等。所述请求的服务类型是指请求的业务类型，所述请求的服务数量是指处理所请求的业务类型对应的业务时需要建立的线程池。
S13：根据所述位置标识号，通过所述第一服务器将所述消息存储于所述第一服务器的消息队列中，同时通过所述第一服务器将所述消息同步至多个第二服务器。
本实施例中，所述第一服务器接收到消息时，根据所述位置标识号将所述消息存储于第一服务器的消息队列中。所述位置标识号表明存储的消息队列的位置信息，因而可以直接根据所述位置标识号将所述消息存储于对应所述位置标识号的消息队列中。
示例性的，所述第一服务器接收到注册消息时，根据所述注册消息中携带的位置标识号“1”，将所述消息存储于的第一消息队列中；所述第一服务器接收到登录消息时，根据所述注册消息中携带的位置 标识号“2”，将所述消息存储于的第二消息队列中；所述第一服务器接收到上传证件消息时，根据所述注册消息中携带的位置标识号“3”，将所述消息存储于的第三消息队列中；所述第一服务器接收到投保消息时，根据所述投保消息中携带的位置标识号“4”，将所述消息存储于的第四消息队列中。
第一服务器可以在将所述消息存储于自身的消息队列时，同步将所接收到的所述消息发送至多个第二服务器。
第一服务器还可以每隔预设时间段，将存储于所述消息队列中的消息同步至多个第二服务器。即在当前预设时间段将上一个预设时间段周期内的存储于所述消息队列中的消息同步至多个第二服务器。所述预设时间段，可以是2小时，或者1天。示例性的，假设预设时间段为1天，则第一服务器在第2天将第1天存储于所述消息队列中的消息同步至多个第二服务器，第一服务器在第3天将第2天存储于所述消息队列中的消息同步至多个第二服务器。
本实施例中，所述多个第二服务器可以是处理消息的服务器。
优选的，所述第一服务器接收到所述消息后，还可以包括：
判断消息队列的长度是否超过预设最大阈值；
当确定所述消息队列的长度超过所述预设最大阈值时，执行第一预设操作；
当确定所述消息队列的长度没有超过所述预设最大阈值时，执行第二预设操作且将所述消息同步至第二服务器。
本实施例中，所述第一预设操作可以为以下一种或多种的组合：
1)抛弃用户请求；
2)跳转到错误页面；
3)向用户返回消息接收失败的结果。
本实施例中，所述第二预设操作可以为：响应用户请求，向用户返回消息接收成功的结果。
通过第一服务器对消息队列的长度与预设最大阈值之间进行比较，根据比较的结果选择执行不同的操作，如此可快速的向用户返回相应的结果，节省用户的等待时间，提升用户的使用体验。
S14：根据所述多个第二服务器当前的负载，在所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器。
本实施例中，多个第二服务器可以通过集群的方式进行搭建。第一服务器将消息发送到第二服务器时，在获取多个第二服务器当前的负载，然后从所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器。
预设负载阈值为预先设置的负载临界值，是指第二服务器所能处理的最佳负载强度。
在通过第一服务器将消息发送至第二服务器时，先通过集群的负载均衡设备，根据每台第二服务器的负载情况，选择负载均衡低的第 二服务器处理相应请求。对于当前负载均衡高的第二服务器，不处理所述消息。可以将消息自动分配给负载低的第二服务器，便于第二服务器负载均衡。
S15：根据所述请求的服务类型及请求的服务数量，通过所筛选出的第二服务器建立相应的线程池对所述消息进行处理。
本实施例中，所述根据所述请求的服务类型及请求的服务数量，通过所述第二服务器建立相应的线程池对所述消息进行处理包括：
对所述消息进行解析；
识别解析后的消息对应的请求的服务类型及请求的服务数量；
根据所述请求的服务数量建立相应的线程池；
根据所述服务类型通过所述线程池对所述消息进行处理。
本实施例中，所述第二服务器中可以预先配置有与所述消息相对应的配置表及对应的请求的服务类型。所述配置表可以包括：完成数据请求所需要的系统服务名、系统服务物理路由、系统服务后续流程条件码、条件码对应后续服务等信息。对所述消息进行解析就是通过检索配置表，解释其中内容，以确定具体服务内容，并确定系统服务名、系统服务物理路由、后续流程条件码、条件码对应后续服务等。
本实施例中，所述第二服务器响应所述消息对应的http请求并执行相应的操作。
本实施例中，所述第二服务器根据所述请求的服务数量建立相应的线程池对所述消息进行处理，一个消息队列对应一个线程池，每个线程池固定消费对应的消息队列中的待处理的消息，不同的线程池之间相互不干扰。例如，线程池1只负责消费第一消息队列中的待处理的消息，线程池2只负责消费第二消息队列中的待处理的消息。
根据所述请求的服务数量建立相应的线程池，能够实现根据所述消息中的请求服务的数量执行不同的并发控制，从而有效的节约资源，进一步提升消息处理的效率。
本实施例中，所述根据所述服务类型通过所述线程池对所述消息进行处理可以包括以下一种或者多种的组合：
1)当识别所述消息中的所述请求的服务类型为注册时，所筛选出的所述第二服务器将所述用户请求对应填写的注册信息记录于预设数据库中。
2)当识别所述消息中的所述请求的服务类型为登录时，所筛选出的所述第二服务器将所述用户请求对应输入的用户名及密码与所述预设数据库中的用户名及密码进行匹配，并在匹配成功后显示登录界面。
3)当识别所述消息中的所述请求的服务类型为上传证件时，所筛选出的所述第二服务器读取所述预设数据库中的证件并完成上传操作。
4)当识别所述消息中的所述请求的服务类型为投保时，所筛选 出的所述第二服务器读取所述预设数据库中的相应内容并生成保单。
需要说明的是，上述所列举的请求的服务类型仅为举例，并不限制本申请，任何适合的服务类型均可引用于此。
本实施例中，所述预设数据库为预先设置的只读数据库，所述只读数据库是指仅有读取权限的数据库，只读数据库能够保持大量的数据，且可以防止数据被篡改。
本实施例中，可以在第一服务器中预先设置配置策略，将不同的消息封装为不同的请求后发送到第二服务器。为防止第一服务器重复发送消息，导致第二服务器多次执行，还可以在第二服务器中引入redis防重复机制。所述redis防重复机制为现有技术，本文在此不再赘述。
所述防重复机制是第二服务在执行消息时，先查询redis对应的消息主键是否有成功执行，如果查询到redis对应的消息主键已成功执行，则不通过所述第二服务器根据所述消息执行相应的操作；如果没有查询到redis对应的消息主键被执行的记录，则通过所述第二服务器根据所述消息执行相应的操作，并在执行成功后将对应的消息主键写入redis。
综上所述，本申请实施例中所述的基于消息队列的请求处理方法，当接收到用户请求时，根据预设报文格式将所述用户请求封装成相应的消息；将封装后的消息发送至第一服务器，所述消息中携带有位置标识号、请求的服务类型及请求的服务数量；根据所述位置标识号，通过所述第一服务器将所述消息存储于所述第一服务器的消息队列中，同时通过所述第一服务器将所述消息同步至多个第二服务器；根据所述多个第二服务器当前的负载，在所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器；根据所述请求的服务类型及请求的服务数量，通过所筛选出的第二服务器建立相应的线程池对所述消息进行处理。本申请通过引入第一服务器中的消息队列，使用消息队列同步通知第二服务器对消息进行处理，能够进行服务器分离，脱离数据库，提升系统运行的效率。另外，根据消息队列中的待处理的消息创建相应的线程，并动态配置线程池的大小，做到了生产者和消费者相分离，能够有效的防止高并发时数据请求压力过大导致系统瘫痪的问题的发生。同时第一服务器对消息队列的长度与预设最大阈值之间进行比较，根据比较的结果选择执行不同的操作，如此可快速的向用户返回相应的结果，节省用户的等待时间，提升用户的使用体验。
以上所述，仅是本申请的具体实施方式，但本申请的保护范围并不局限于此，对于本领域的普通技术人员来说，在不脱离本申请创造构思的前提下，还可以做出改进，但这些均属于本申请的保护范围。
下面结合第2至3图，分别对实现上述基于消息队列的请求处理方法的设备的功能模块及硬件结构进行介绍。
实施例二
图2为本申请基于消息队列的请求处理装置较佳实施例中的功能模块图。
在一些实施例中，所述基于消息队列的请求处理装置20运行于服务器中。所述基于消息队列的请求处理装置20可以包括多个由程序代码段所组成的功能模块。所述基于消息队列的请求处理装置20中的各个程序段的程序代码可以存储于存储器中，并由至少一个处理器所执行，以执行(详见图1及其相关描述)基于消息队列的请求处理的方法。
本实施例中，所述基于消息队列的请求处理装置20根据其所执行的功能，可以被划分为多个功能模块。所述功能模块可以包括：封装模块201、发送模块202、存储模块203、判断模块204、执行模块205、筛选模块206及处理模块207。本申请所称的模块是指一种能够被至少一个处理器所执行并且能够完成固定功能的一系列计算机可读指令段，其存储在存储器中。在一些实施例中，关于各模块的功能将在后续的实施例中详述。
封装模块201，用于当接收到用户请求时，根据预设报文格式将所述用户请求封装成相应的消息。
本实施例中，用户可以通过设备发送请求，所述设备是指具有数据处理能力的电子设备，例如客户端计算机。
用户请求可以包括，但不限于：注册，登录，上传证件或投保等。系统接收到所述用户请求后，根据预设报文格式将所述用户请求封装成相应的消息。例如，系统接收到用户的注册请求后，根据预设报文格式将所述注册请求封装成相应的注册消息；系统接收到用户的登录请求后，根据预设报文格式将所述登录请求封装成相应的登录消息；系统接收到用户的上传证件请求后，根据预设报文格式将所述上传证件请求封装成相应的上传证件消息；系统接收到用户的投保请求后，根据预设报文格式将所述投保请求封装成相应的投保消息。
本实施例中，根据预设报文格式将所述用户请求封装成相应的消息可以包括：
根据所述预设报文格式将所述用户请求封装为http请求或者https请求；
根据http请求协议将所封装的http请求或者https请求封装为相应的消息。
所述预设报文格式可以包括：报文类型、报文版本、报文长度及报文实体等信息。
通过接收用户请求并将用户请求按照预设报文格式进行封装可以使得用户请求变得统一，便于系统管理与处理。
发送模块202，用于将封装后的消息发送至所述第一服务器，所 述消息中携带有位置标识号、请求的服务类型及请求的服务数量。
所述第一服务器可以是消息队列服务器。所述消息队列服务器是指为客户端计算机提供消息队列、路由选择和目录服务的计算机。
本实施例中，封装后的消息中还可以携带有位置标识号和参数信息等。所述位置标识号用以表明存储的消息队列的位置信息。例如，位置标识号为1时，表明将所述消息存储于所述第一服务器的第一消息队列中。位置标识号为2时，表明将所述消息存储于所述第一服务器的第二消息队列中。所述参数信息可以包括：所述请求的服务类型及所述请求的服务数量等。所述请求的服务类型是指请求的业务类型，所述请求的服务数量是指处理所请求的业务类型对应的业务时需要建立的线程池。
存储模块203，用于根据所述位置标识号，通过所述第一服务器将所述消息存储于所述第一服务器的消息队列中。同时所述发送模块202还用于通过所述第一服务器将所述消息同步至多个第二服务器。
本实施例中，所述第一服务器接收到消息时，根据所述位置标识号将所述消息存储于第一服务器的消息队列中。所述位置标识号表明存储的消息队列的位置信息，因而可以直接根据所述位置标识号将所述消息存储于对应所述位置标识号的消息队列中。
示例性的，所述第一服务器接收到注册消息时，根据所述注册消息中携带的位置标识号“1”，将所述消息存储于的第一消息队列中；所述第一服务器接收到登录消息时，根据所述注册消息中携带的位置标识号“2”，将所述消息存储于的第二消息队列中；所述第一服务器接收到上传证件消息时，根据所述注册消息中携带的位置标识号“3”，将所述消息存储于的第三消息队列中；所述第一服务器接收到投保消息时，根据所述投保消息中携带的位置标识号“4”，将所述消息存储于的第四消息队列中。
第一服务器可以在将所述消息存储于自身的消息队列时，同步将所接收到的所述消息发送至多个第二服务器。
第一服务器还可以每隔预设时间段，将存储于所述消息队列中的消息同步至多个第二服务器。即在当前预设时间段将上一个预设时间段周期内的存储于所述消息队列中的消息同步至多个第二服务器。所述预设时间段，可以是2小时，或者1天。示例性的，假设预设时间段为1天，则第一服务器在第2天将第1天存储于所述消息队列中的消息同步至多个第二服务器，第一服务器在第3天将第2天存储于所述消息队列中的消息同步至多个第二服务器。
本实施例中，所述多个第二服务器可以是处理消息的服务器。
优选的，所述第一服务器接收到所述消息后，所述基于消息队列的请求处理装置20还可以包括：
判断模块204，用于判断消息队列的长度是否超过预设最大阈值。
执行模块205，用于当所述判断模块204确定所述消息队列的长 度超过所述预设最大阈值时，执行第一预设操作；
执行模块205，还用于当所述判断模块204确定所述消息队列的长度没有超过所述预设最大阈值时，执行第二预设操作且将所述消息同步至第二服务器。
本实施例中，所述第一预设操作可以为以下一种或多种的组合：
1)抛弃用户请求；
2)跳转到错误页面；
3)向用户返回消息接收失败的结果。
本实施例中，所述第二预设操作可以为：响应用户请求，向用户返回消息接收成功的结果。
通过第一服务器对消息队列的长度与预设最大阈值之间进行比较，根据比较的结果选择执行不同的操作，如此可快速的向用户返回相应的结果，节省用户的等待时间，提升用户的使用体验。
筛选模块206，用于根据所述多个第二服务器当前的负载，在所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器。
本实施例中，多个第二服务器可以通过集群的方式进行搭建。第一服务器将消息发送到第二服务器时，在获取多个第二服务器当前的负载，然后从所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器。
预设负载阈值为预先设置的负载临界值，是指第二服务器所能处理的最佳负载强度。
在通过第一服务器将消息发送至第二服务器时，先通过集群的负载均衡设备，根据每台第二服务器的负载情况，选择负载均衡低的第二服务器处理相应请求。对于当前负载均衡高的第二服务器，不处理所述消息。可以将消息自动分配给负载低的第二服务器，便于第二服务器负载均衡。
处理模块207，用于根据所述请求的服务类型及请求的服务数量，通过所筛选出的第二服务器建立相应的线程池对所述消息进行处理。
本实施例中，所述处理模块207根据所述请求的服务类型及请求的服务数量，通过所述第二服务器建立相应的线程池对所述消息进行处理包括：
对所述消息进行解析；
识别解析后的消息对应的请求的服务类型及请求的服务数量；
根据所述请求的服务数量建立相应的线程池；
根据所述服务类型通过所述线程池对所述消息进行处理。
本实施例中，所述第二服务器中可以预先配置有与所述消息相对应的配置表及对应的请求的服务类型。所述配置表可以包括：完成数据请求所需要的系统服务名、系统服务物理路由、系统服务后续流程条件码、条件码对应后续服务等信息。对所述消息进行解析就是通过 检索配置表，解释其中内容，以确定具体服务内容，并确定系统服务名、系统服务物理路由、后续流程条件码、条件码对应后续服务等。
本实施例中，所述第二服务器根据所述请求的服务数量建立相应的线程池对所述消息进行处理，一个消息队列对应一个线程池，每个线程池固定消费对应的消息队列中的待处理的消息，不同的线程池之间相互不干扰。例如，线程池1只负责消费第一消息队列中的待处理的消息，线程池2只负责消费第二消息队列中的待处理的消息。
根据所述请求的服务数量建立相应的线程池，能够实现根据所述消息中的请求服务的数量执行不同的并发控制，从而有效的节约资源，进一步提升消息处理的效率。
本实施例中，所述根据所述服务类型通过所述线程池对所述消息进行处理可以包括以下一种或者多种的组合：
1)当识别所述消息中的所述请求的服务类型为注册时，所筛选出的所述第二服务器将所述用户请求对应填写的注册信息记录于预设数据库中。
2)当识别所述消息中的所述请求的服务类型为登录时，所筛选出的所述第二服务器将所述用户请求对应输入的用户名及密码与所述预设数据库中的用户名及密码进行匹配，并在匹配成功后显示登录界面。
3)当识别所述消息中的所述请求的服务类型为上传证件时，所筛选出的所述第二服务器读取所述预设数据库中的证件并完成上传操作。
4)当识别所述消息中的所述请求的服务类型为投保时，所筛选出的所述第二服务器读取所述预设数据库中的相应内容并生成保单。
需要说明的是，上述所列举的请求的服务类型仅为举例，并不限制本申请，任何适合的服务类型均可引用于此。
本实施例中，所述预设数据库为预先设置的只读数据库，所述只读数据库是指仅有读取权限的数据库，只读数据库能够保持大量的数据，且可以防止数据被篡改。
本实施例中，可以在第一服务器中预先设置配置策略，将不同的消息封装为不同的请求后发送到第二服务器。为防止第一服务器重复发送消息，导致第二服务器多次执行，还可以在第二服务器中引入redis防重复机制。所述redis防重复机制为现有技术，本文在此不再赘述。
所述防重复机制是第二服务在执行消息时，先查询redis对应的消息主键是否有成功执行，如果查询到redis对应的消息主键已成功执行，则不通过所述第二服务器根据所述消息执行相应的操作；如果没有查询到redis对应的消息主键被执行的记录，则通过所述第二服务器根据所述消息执行相应的操作，并在执行成功后将对应的消息主键写入redis。
综上所述，本申请实施例中所述的基于消息队列的请求处理装置，当接收到用户请求时，根据预设报文格式将所述用户请求封装成相应的消息；将封装后的消息发送至第一服务器，所述消息中携带有位置标识号、请求的服务类型及请求的服务数量；根据所述位置标识号，通过所述第一服务器将所述消息存储于所述第一服务器的消息队列中，同时通过所述第一服务器将所述消息同步至多个第二服务器；根据所述多个第二服务器当前的负载，在所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器；根据所述请求的服务类型及请求的服务数量，通过所筛选出的第二服务器建立相应的线程池对所述消息进行处理。本申请通过引入第一服务器中的消息队列，使用消息队列同步通知第二服务器对消息进行处理，能够进行服务器分离，脱离数据库，提升系统运行的效率。另外，根据消息队列中的待处理的消息创建相应的线程，并动态配置线程池的大小，做到了生产者和消费者相分离，能够有效的防止高并发时数据请求压力过大导致系统瘫痪的问题的发生。同时第一服务器对消息队列的长度与预设最大阈值之间进行比较，根据比较的结果选择执行不同的操作，如此可快速的向用户返回相应的结果，节省用户的等待时间，提升用户的使用体验。
上述以软件功能模块的形式实现的集成的单元，可以存储在一个非易失性可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，双屏设备，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分。
实施例三
图3为本申请实施例三提供的设备的示意图。
所述设备3包括：存储器31、至少一个处理器32、存储在所述存储器31中并可在所述至少一个处理器32上运行的计算机可读指令33及至少一条通讯总线34。
所述至少一个处理器32执行所述计算机可读指令33时实现上述基于消息队列的请求处理方法实施例中的步骤。
示例性的，所述计算机可读指令33可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器31中，并由所述至少一个处理器32执行。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机可读指令段，该指令段用于描述所述计算机可读指令33在所述设备3中的执行过程。
所述设备3可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。本领域技术人员可以理解，所述示意图3仅仅是设备3的示例，并不构成对设备3的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述设备3还可以 包括输入输出设备、网络接入设备、总线等。
所述至少一个处理器32可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。该处理器32可以是微处理器或者该处理器32也可以是任何常规的处理器等，所述处理器32是所述设备3的控制中心，利用各种接口和线路连接整个设备3的各个部分。
所述存储器31可用于存储所述计算机可读指令33和/或模块/单元，所述处理器32通过运行或执行存储在所述存储器31内的计算机可读指令和/或模块/单元，以及调用存储在存储器31内的数据，实现所述设备3的各种功能。所述存储器31可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据设备3的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器31可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
具体的，所述存储器31中存储的计算机可读指令被处理器32执行时，实现以下功能：
当接收到用户请求时，根据预设报文格式将所述用户请求封装成相应的消息；
将封装后的消息发送至第一服务器，所述消息中携带有位置标识号、请求的服务类型及请求的服务数量；
根据所述位置标识号，通过所述第一服务器将所述消息存储于所述第一服务器的消息队列中，同时通过所述第一服务器将所述消息同步至多个第二服务器；
根据所述多个第二服务器当前的负载，在所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器；
根据所述请求的服务类型及请求的服务数量，通过所筛选出的第二服务器建立相应的线程池对所述消息进行处理。
进一步的，所述根据预设报文格式将所述用户请求封装成相应的消息包括：
根据所述预设报文格式将所述用户请求封装为http请求或者https请求；
根据http请求协议将所封装的所述http请求或者所述https请求封装为相应的消息。
在所述第一服务器接收到所述消息后，所述处理器32还用于：
判断消息队列的长度是否超过预设最大阈值；
当确定所述消息队列的长度超过所述预设最大阈值时，执行第一预设操作。
进一步的，当确定所述消息队列的长度没有超过所述预设最大阈值时，所述处理器32还用于：
执行第二预设操作且将所述消息同步至所述第二服务器。
进一步的，所述第一预设操作为以下一种或多种的组合：
抛弃用户请求；
跳转到错误页面；
向用户返回消息接收失败的结果。
所述第二预设操作为：响应用户请求，向用户返回消息接收成功的结果。
进一步的，所述根据所述请求的服务类型及请求的服务数量，通过所述第二服务器建立相应的线程池对所述消息进行处理包括：
对所述消息进行解析；
识别解析后的消息对应的请求的服务类型及请求的服务数量；
根据所述请求的服务数量建立相应的线程池；
根据所述服务类型通过所述线程池对所述消息进行处理。
进一步的，在所述第二服务器接收到所述消息后，所述处理器32还用于：
查询redis对应的消息主键是否有成功执行；
如果查询到redis对应的消息主键已成功执行，则不通过所述第二服务器根据所述消息执行相应的操作；
如果没有查询到redis对应的消息主键被执行的记录，则通过所述第二服务器根据所述消息执行相应的操作，并在执行成功后将对应的消息主键写入redis。
所述设备3集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个非易失性可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机可读指令来指令相关的硬件来完成，所述的计算机可读指令可存储于一非易失性可读存储介质中，该计算机可读指令在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机可读指令包括计算机可读指令代码，所述计算机可读指令代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述非易失性可读介质可以包括：能够携带所述计算机可读指令代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述非易失性可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减， 例如在某些司法管辖区，根据立法和专利实践，非易失性可读介质不包括电载波信号和电信信号。
在本申请所提供的几个实施例中，应该理解到，所揭露的服务器和方法，可以通过其它的方式实现。例如，以上所描述的服务器实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
另外，在本申请各个实施例中的各功能单元可以集成在相同处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在相同单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。
对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或，单数不排除复数。系统权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。
最后应说明的是，以上实施例仅用以说明本申请的技术方案而非限制，尽管参照较佳实施例对本申请进行了详细说明，本领域的普通技术人员应当理解，可以对本申请的技术方案进行修改或等同替换，而不脱离本申请技术方案的精神范围。

Claims (20)

  1. 一种基于消息队列的请求处理方法，其特征在于，所述方法包括：
    当接收到用户请求时，根据预设报文格式将所述用户请求封装成相应的消息；
    将封装后的消息发送至第一服务器，所述消息中携带有位置标识号、请求的服务类型及请求的服务数量；
    根据所述位置标识号，通过所述第一服务器将所述消息存储于所述第一服务器的消息队列中，同时通过所述第一服务器将所述消息同步至多个第二服务器；
    根据所述多个第二服务器当前的负载，在所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器；
    根据所述请求的服务类型及请求的服务数量，通过所筛选出的第二服务器建立相应的线程池对所述消息进行处理。
  2. 如权利要求1所述的方法，其特征在于，所述根据预设报文格式将所述用户请求封装成相应的消息包括：
    根据所述预设报文格式将所述用户请求封装为http请求或者https请求；
    根据http请求协议将所封装的所述http请求或者所述https请求封装为相应的消息。
  3. 如权利要求1所述的方法，其特征在于，在所述第一服务器接收到所述消息后，所述方法还包括：
    判断消息队列的长度是否超过预设最大阈值；
    当确定所述消息队列的长度超过所述预设最大阈值时，执行第一预设操作。
  4. 如权利要求3所述的方法，其特征在于，当确定所述消息队列的长度没有超过所述预设最大阈值时，所述方法还包括：
    执行第二预设操作且将所述消息同步至所述第二服务器。
  5. 如权利要求4所述的方法，其特征在于，
    所述第一预设操作为以下一种或多种的组合：
    抛弃用户请求；
    跳转到错误页面；
    向用户返回消息接收失败的结果。
    所述第二预设操作为：响应用户请求，向用户返回消息接收成功的结果。
  6. 如权利要求1所述的方法，其特征在于，所述根据所述请求的服务类型及请求的服务数量，通过所述第二服务器建立相应的线程池对所述消息进行处理包括：
    对所述消息进行解析；
    识别解析后的消息对应的请求的服务类型及请求的服务数量；
    根据所述请求的服务数量建立相应的线程池；
    根据所述服务类型通过所述线程池对所述消息进行处理。
  7. 如权利要求1所述的方法，其特征在于，在所述第二服务器接收到所述消息后，所述方法还包括：
    查询redis对应的消息主键是否有成功执行；
    如果查询到redis对应的消息主键已成功执行，则不通过所述第二服务器根据所述消息执行相应的操作；
    如果没有查询到redis对应的消息主键被执行的记录，则通过所述第二服务器根据所述消息执行相应的操作，并在执行成功后将对应的消息主键写入redis。
  8. 一种基于消息队列的请求处理装置，其特征在于，所述装置包括：
    封装模块，用于当接收到用户请求时，根据预设报文格式将所述用户请求封装成相应的消息；
    发送模块，用于将封装后的消息发送至第一服务器，所述消息中携带有位置标识号、请求的服务类型及请求的服务数量；
    存储模块，用于根据所述位置标识号，通过所述第一服务器将所述消息存储于所述第一服务器的消息队列中；
    所述发送模块，还用于同时通过所述第一服务器将所述消息同步至多个第二服务器；
    筛选模块，用于根据所述多个第二服务器当前的负载，在所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器；
    处理模块，用于根据所述请求的服务类型及请求的服务数量，通过所筛选出的第二服务器建立相应的线程池对所述消息进行处理。
  9. 一种设备，其特征在于，所述设备包括处理器和存储器，所述处理器用于执行所述存储器中存储的计算机可读指令时实现以下步骤：
    当接收到用户请求时，根据预设报文格式将所述用户请求封装成相应的消息；
    将封装后的消息发送至第一服务器，所述消息中携带有位置标识号、请求的服务类型及请求的服务数量；
    根据所述位置标识号，通过所述第一服务器将所述消息存储于所述第一服务器的消息队列中，同时通过所述第一服务器将所述消息同步至多个第二服务器；
    根据所述多个第二服务器当前的负载，在所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器；
    根据所述请求的服务类型及请求的服务数量，通过所筛选出的第二服务器建立相应的线程池对所述消息进行处理。
  10. 如权利要求9所述的设备，其特征在于，所述处理器在所述第一服务器接收到所述消息后，还用于执行所述计算机可读指令以实现以下步骤：
    判断消息队列的长度是否超过预设最大阈值；
    当确定所述消息队列的长度超过所述预设最大阈值时，执行第一预设操作。
  11. 如权利要求10所述的设备，其特征在于，当确定所述消息队列的长度没有超过所述预设最大阈值时，所述处理器还用于执行所述计算机可读指令以实现以下步骤：
    执行第二预设操作且将所述消息同步至所述第二服务器。
  12. 如权利要求11所述的设备，其特征在于，
    所述第一预设操作为以下一种或多种的组合：
    抛弃用户请求；
    跳转到错误页面；
    向用户返回消息接收失败的结果。
    所述第二预设操作为：响应用户请求，向用户返回消息接收成功的结果。
  13. 如权利要求9所述的设备，其特征在于，所述处理器在所述根据所述请求的服务类型及请求的服务数量，通过所述第二服务器建立相应的线程池对所述消息进行处理时，执行所述计算机可读指令以实现以下步骤：
    对所述消息进行解析；
    识别解析后的消息对应的请求的服务类型及请求的服务数量；
    根据所述请求的服务数量建立相应的线程池；
    根据所述服务类型通过所述线程池对所述消息进行处理。
  14. 如权利要求9所述的设备，其特征在于，在所述第二服务器接收到所述消息后，所述处理器还用于执行所述计算机可读指令以实现如下步骤：
    查询redis对应的消息主键是否有成功执行；
    如果查询到redis对应的消息主键已成功执行，则不通过所述第二服务器根据所述消息执行相应的操作；
    如果没有查询到redis对应的消息主键被执行的记录，则通过所述第二服务器根据所述消息执行相应的操作，并在执行成功后将对应的消息主键写入redis。
  15. 一种非易失性可读存储介质，所述非易失性可读存储介质上存储有计算机可读指令，其特征在于，所述计算机可读指令被处理器执行时实现以下步骤：
    当接收到用户请求时，根据预设报文格式将所述用户请求封装成相应的消息；
    将封装后的消息发送至第一服务器，所述消息中携带有位置标识 号、请求的服务类型及请求的服务数量；
    根据所述位置标识号，通过所述第一服务器将所述消息存储于所述第一服务器的消息队列中，同时通过所述第一服务器将所述消息同步至多个第二服务器；
    根据所述多个第二服务器当前的负载，在所述多个第二服务器中筛选出当前的负载低于预设负载阈值的第二服务器；
    根据所述请求的服务类型及请求的服务数量，通过所筛选出的第二服务器建立相应的线程池对所述消息进行处理。
  16. 如权利要求15所述的存储介质，其特征在于，在所述第一服务器接收到所述消息后，所述计算机可读指令被所述处理器执行时还用以实现以下步骤：
    判断消息队列的长度是否超过预设最大阈值；
    当确定所述消息队列的长度超过所述预设最大阈值时，执行第一预设操作。
  17. 如权利要求16所述的存储介质，其特征在于，当确定所述消息队列的长度没有超过所述预设最大阈值时，所述计算机可读指令被所述处理器执行时还用以实现以下步骤：
    执行第二预设操作且将所述消息同步至所述第二服务器。
  18. 如权利要求17所述的存储介质，其特征在于，
    所述第一预设操作为以下一种或多种的组合：
    抛弃用户请求；
    跳转到错误页面；
    向用户返回消息接收失败的结果。
    所述第二预设操作为：响应用户请求，向用户返回消息接收成功的结果。
  19. 如权利要求15所述的存储介质，其特征在于，所述根据所述请求的服务类型及请求的服务数量，通过所述第二服务器建立相应的线程池对所述消息进行处理时，所述计算机可读指令被所述处理器执行时用以实现以下步骤：
    对所述消息进行解析；
    识别解析后的消息对应的请求的服务类型及请求的服务数量；
    根据所述请求的服务数量建立相应的线程池；
    根据所述服务类型通过所述线程池对所述消息进行处理。
  20. 如权利要求15所述的存储介质，其特征在于，在所述第二服务器接收到所述消息后，所述计算机可读指令被所述处理器执行时还用以实现如下步骤：
    查询redis对应的消息主键是否有成功执行；
    如果查询到redis对应的消息主键已成功执行，则不通过所述第二服务器根据所述消息执行相应的操作；
    如果没有查询到redis对应的消息主键被执行的记录，则通过所 述第二服务器根据所述消息执行相应的操作，并在执行成功后将对应的消息主键写入redis。
PCT/CN2019/077913 2018-09-29 2019-03-13 基于消息队列的请求处理方法、装置、设备及存储介质 Ceased WO2020062793A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811151515.6A CN109271265B (zh) 2018-09-29 2018-09-29 基于消息队列的请求处理方法、装置、设备及存储介质
CN201811151515.6 2018-09-29

Publications (1)

Publication Number Publication Date
WO2020062793A1 true WO2020062793A1 (zh) 2020-04-02

Family

ID=65195874

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/077913 Ceased WO2020062793A1 (zh) 2018-09-29 2019-03-13 基于消息队列的请求处理方法、装置、设备及存储介质

Country Status (2)

Country Link
CN (1) CN109271265B (zh)
WO (1) WO2020062793A1 (zh)

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111666145A (zh) * 2020-06-24 2020-09-15 深圳壹账通智能科技有限公司 消息队列的消息处理方法、系统和计算机设备
CN112486701A (zh) * 2020-11-26 2021-03-12 中国人寿保险股份有限公司 一种消息异步处理方法及其设备
CN112527524A (zh) * 2020-12-09 2021-03-19 北京百度网讯科技有限公司 动态限流方法、装置以及电子设备
CN112905358A (zh) * 2021-02-05 2021-06-04 中国工商银行股份有限公司 分布式系统的软件分发方法、装置及系统
CN113419875A (zh) * 2021-06-29 2021-09-21 北京小米移动软件有限公司 数据扫描方法及装置、电子设备、存储介质
CN114003784A (zh) * 2021-10-28 2022-02-01 平安银行股份有限公司 请求录制方法、装置、设备及存储介质
CN114048108A (zh) * 2022-01-12 2022-02-15 中科星图智慧科技有限公司 多源异构数据的自动化治理方法及装置
CN114168348A (zh) * 2021-12-17 2022-03-11 中国建设银行股份有限公司 一种调度方法、装置及存储介质
CN114238427A (zh) * 2021-12-27 2022-03-25 佛山众陶联供应链服务有限公司 一种高实时统计交易数据的导出方法和系统
CN114338381A (zh) * 2021-12-29 2022-04-12 中国邮政储蓄银行股份有限公司 消息的单元化处理方法、消息网关与消息的处理系统
CN114461414A (zh) * 2021-12-13 2022-05-10 上海虎瑾信息技术有限公司 基于消息队列的延时消息处理方法、装置、终端和存储介质
CN114547091A (zh) * 2022-03-04 2022-05-27 未鲲(上海)科技服务有限公司 消息消费的测试方法、系统、计算机设备和可读存储介质
CN114691383A (zh) * 2020-12-31 2022-07-01 京东科技控股股份有限公司 数据处理方法、装置、设备及存储介质
CN114827171A (zh) * 2022-03-23 2022-07-29 青岛中科曙光科技服务有限公司 信息同步方法、装置、计算机设备和存储介质
CN114860475A (zh) * 2022-04-20 2022-08-05 中国银行股份有限公司 一种异步消息处理方法及装置
CN115221242A (zh) * 2022-06-30 2022-10-21 济南浪潮数据技术有限公司 一种数据同步方法、装置及计算机可读存储介质
CN115373811A (zh) * 2021-05-17 2022-11-22 腾讯科技（深圳）有限公司 业务相关数据上报系统、方法及装置
CN115767448A (zh) * 2022-12-07 2023-03-07 京东科技信息技术有限公司 一种消息发送方法、装置、设备和存储介质
CN115834505A (zh) * 2022-11-03 2023-03-21 山石网科通信技术股份有限公司 数据包的处理方法及装置、存储介质和处理器
CN116166507A (zh) * 2023-03-14 2023-05-26 平安壹钱包电子商务有限公司 一种埋点数据上报方法、系统、计算机设备及介质
CN116360970A (zh) * 2021-12-28 2023-06-30 比亚迪股份有限公司 一种请求处理方法、请求处理装置及电子设备
CN116743319A (zh) * 2023-06-07 2023-09-12 阿里云计算有限公司 消息处理方法、电子设备及存储介质
CN117271596A (zh) * 2022-06-15 2023-12-22 北京京东拓先科技有限公司 一种消息处理的方法和装置

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109271265B (zh) * 2018-09-29 2023-09-15 平安科技（深圳）有限公司 基于消息队列的请求处理方法、装置、设备及存储介质
CN112019689B (zh) * 2019-05-29 2025-03-25 北京奇虎科技有限公司 来电秀业务处理系统及方法
CN112015805B (zh) * 2019-05-29 2022-12-13 中移(苏州)软件技术有限公司 一种用户消息同步方法、装置、服务器及计算机存储介质
CN112702250A (zh) * 2019-10-22 2021-04-23 上海淘票儿信息科技有限公司 云桥、云上业务系统及云下系统
CN111161085B (zh) * 2019-11-28 2023-08-22 泰康保险集团股份有限公司 业务请求处理方法、装置、电子设备及计算机可读介质
CN111143093B (zh) * 2019-12-31 2024-04-19 中国银行股份有限公司 异步消息分布式处理方法、装置、设备及存储介质
CN111277626B (zh) * 2020-01-07 2023-08-22 平安科技（深圳）有限公司 服务器升级方法、装置、电子设备及介质
CN111309466B (zh) * 2020-02-22 2022-07-12 苏州浪潮智能科技有限公司 一种基于云平台多线程调度的方法、系统、设备及介质
CN111309500A (zh) * 2020-02-26 2020-06-19 中国联合网络通信集团有限公司 业务处理方法、装置、设备及存储介质
CN111427700B (zh) * 2020-03-03 2023-05-05 云知声智能科技股份有限公司 一种物联网消息服务方法及服务器
CN111400059B (zh) * 2020-03-09 2023-11-14 五八有限公司 一种数据处理方法以及数据处理装置
CN111652605A (zh) * 2020-06-08 2020-09-11 山东汇贸电子口岸有限公司 公有云业务创建云服务套餐的创建系统及创建方法
CN111885105A (zh) * 2020-06-16 2020-11-03 广州三七互娱科技有限公司 任务执行方法、装置、系统、计算机设备和存储介质
CN112333177A (zh) * 2020-10-29 2021-02-05 杭州迪普科技股份有限公司 扫描报告生成方法及装置
CN112311812A (zh) * 2020-11-20 2021-02-02 北京百家科技集团有限公司 一种服务系统、方法、装置、计算机设备及存储介质
CN114610504B (zh) * 2020-12-09 2025-03-28 腾讯科技（深圳）有限公司 消息处理方法、装置、电子设备及存储介质
CN112685190A (zh) * 2020-12-30 2021-04-20 平安普惠企业管理有限公司 基于消息队列的同步调用方法、系统及计算机设备
CN112380040B (zh) * 2021-01-18 2021-05-07 北京美摄网络科技有限公司 一种消息处理的方法、装置、电子设备及存储介质
CN112836838B (zh) * 2021-02-10 2022-03-11 北京声智科技有限公司 预约请求处理方法、装置、设备及存储介质
CN113032123B (zh) * 2021-04-02 2024-05-14 深圳市大富网络技术有限公司 一种远程npl运行环境的线程调度方法、系统及相关装置
CN113259430B (zh) * 2021-05-11 2023-01-31 京东科技控股股份有限公司 一种消息调用方法和装置、电子设备及存储介质
CN113342764A (zh) * 2021-06-12 2021-09-03 四川虹美智能科技有限公司 不同云端服务器之间的数据同步方法及装置
CN113422739B (zh) * 2021-06-21 2022-09-06 上海哔哩哔哩科技有限公司 数据传输方法、发送端及数据传输系统
CN114020464B (zh) * 2021-11-05 2022-11-01 江苏安超云软件有限公司 一种动态处理虚拟化资源的方法、装置及存储介质
CN114119229A (zh) * 2021-11-25 2022-03-01 中国建设银行股份有限公司 金融产品的电子资源提醒方法及装置
CN114584566A (zh) * 2022-02-16 2022-06-03 深圳金融电子结算中心有限公司 基于消息队列的数据处理方法、装置、设备及存储介质
CN114881236A (zh) * 2022-06-02 2022-08-09 广联达科技股份有限公司 一种模型推理系统、方法及设备
CN118069755B (zh) * 2024-04-25 2024-08-09 浪潮云信息技术股份公司 数据库超大事件信息同步方法及装置、介质、设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102880475A (zh) * 2012-10-23 2013-01-16 上海普元信息技术股份有限公司 计算机软件系统中基于云计算的实时事件处理系统及方法
US20170124663A1 (en) * 2015-10-30 2017-05-04 Intuit Inc. Escrow personalization system
CN107301091A (zh) * 2016-04-14 2017-10-27 北京京东尚科信息技术有限公司 资源分配方法和装置
CN109271265A (zh) * 2018-09-29 2019-01-25 平安科技（深圳）有限公司 基于消息队列的请求处理方法、装置、设备及存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5758184A (en) * 1995-04-24 1998-05-26 Microsoft Corporation System for performing asynchronous file operations requested by runnable threads by processing completion messages with different queue thread and checking for completion by runnable threads
EP1708094A1 (de) * 2005-03-31 2006-10-04 Ubs Ag Rechnernetzwerksystem zum Aufbauen, Synchronisieren und/oder Betreiben einer zweiten Datenbank aus/mit einer ersten Datenbank sowie Vorgehensweisen hierfür
US8159961B1 (en) * 2007-03-30 2012-04-17 Amazon Technologies, Inc. Load balancing utilizing adaptive thresholding
CN108134830A (zh) * 2017-12-20 2018-06-08 马上消费金融股份有限公司 基于消息队列的负载均衡方法、系统、装置及存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102880475A (zh) * 2012-10-23 2013-01-16 上海普元信息技术股份有限公司 计算机软件系统中基于云计算的实时事件处理系统及方法
US20170124663A1 (en) * 2015-10-30 2017-05-04 Intuit Inc. Escrow personalization system
CN107301091A (zh) * 2016-04-14 2017-10-27 北京京东尚科信息技术有限公司 资源分配方法和装置
CN109271265A (zh) * 2018-09-29 2019-01-25 平安科技（深圳）有限公司 基于消息队列的请求处理方法、装置、设备及存储介质

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111666145A (zh) * 2020-06-24 2020-09-15 深圳壹账通智能科技有限公司 消息队列的消息处理方法、系统和计算机设备
CN112486701A (zh) * 2020-11-26 2021-03-12 中国人寿保险股份有限公司 一种消息异步处理方法及其设备
CN112527524A (zh) * 2020-12-09 2021-03-19 北京百度网讯科技有限公司 动态限流方法、装置以及电子设备
CN114691383A (zh) * 2020-12-31 2022-07-01 京东科技控股股份有限公司 数据处理方法、装置、设备及存储介质
CN112905358A (zh) * 2021-02-05 2021-06-04 中国工商银行股份有限公司 分布式系统的软件分发方法、装置及系统
CN115373811A (zh) * 2021-05-17 2022-11-22 腾讯科技（深圳）有限公司 业务相关数据上报系统、方法及装置
CN113419875A (zh) * 2021-06-29 2021-09-21 北京小米移动软件有限公司 数据扫描方法及装置、电子设备、存储介质
CN114003784A (zh) * 2021-10-28 2022-02-01 平安银行股份有限公司 请求录制方法、装置、设备及存储介质
CN114461414A (zh) * 2021-12-13 2022-05-10 上海虎瑾信息技术有限公司 基于消息队列的延时消息处理方法、装置、终端和存储介质
CN114168348A (zh) * 2021-12-17 2022-03-11 中国建设银行股份有限公司 一种调度方法、装置及存储介质
CN114238427A (zh) * 2021-12-27 2022-03-25 佛山众陶联供应链服务有限公司 一种高实时统计交易数据的导出方法和系统
CN116360970A (zh) * 2021-12-28 2023-06-30 比亚迪股份有限公司 一种请求处理方法、请求处理装置及电子设备
CN114338381A (zh) * 2021-12-29 2022-04-12 中国邮政储蓄银行股份有限公司 消息的单元化处理方法、消息网关与消息的处理系统
CN114048108A (zh) * 2022-01-12 2022-02-15 中科星图智慧科技有限公司 多源异构数据的自动化治理方法及装置
CN114547091A (zh) * 2022-03-04 2022-05-27 未鲲(上海)科技服务有限公司 消息消费的测试方法、系统、计算机设备和可读存储介质
CN114827171A (zh) * 2022-03-23 2022-07-29 青岛中科曙光科技服务有限公司 信息同步方法、装置、计算机设备和存储介质
CN114827171B (zh) * 2022-03-23 2023-12-15 青岛中科曙光科技服务有限公司 信息同步方法、装置、计算机设备和存储介质
CN114860475A (zh) * 2022-04-20 2022-08-05 中国银行股份有限公司 一种异步消息处理方法及装置
CN117271596A (zh) * 2022-06-15 2023-12-22 北京京东拓先科技有限公司 一种消息处理的方法和装置
CN115221242A (zh) * 2022-06-30 2022-10-21 济南浪潮数据技术有限公司 一种数据同步方法、装置及计算机可读存储介质
CN115834505A (zh) * 2022-11-03 2023-03-21 山石网科通信技术股份有限公司 数据包的处理方法及装置、存储介质和处理器
CN115767448A (zh) * 2022-12-07 2023-03-07 京东科技信息技术有限公司 一种消息发送方法、装置、设备和存储介质
CN116166507A (zh) * 2023-03-14 2023-05-26 平安壹钱包电子商务有限公司 一种埋点数据上报方法、系统、计算机设备及介质
CN116743319A (zh) * 2023-06-07 2023-09-12 阿里云计算有限公司 消息处理方法、电子设备及存储介质

Also Published As

Publication number Publication date
CN109271265B (zh) 2023-09-15
CN109271265A (zh) 2019-01-25

Similar Documents

Publication Publication Date Title
WO2020062793A1 (zh) 基于消息队列的请求处理方法、装置、设备及存储介质
CN111736775B (zh) 多源存储方法、装置、计算机系统及存储介质
CN110278231A (zh) 一种数据订阅分发方法及系统
WO2019201039A1 (zh) 一种更新应用程序的方法、系统及应用服务器
US10860604B1 (en) Scalable tracking for database udpates according to a secondary index
CN110710168A (zh) 跨隔离的网络堆栈的智能线程管理
WO2020119476A1 (zh) 联盟链信息发布控制方法及终端设备
WO2021169275A1 (zh) Sdn 网络设备访问方法、装置、计算机设备及存储介质
AU2015266790B2 (en) Providing router information according to a programmatic interface
US12159176B2 (en) Protecting instances of resources of a container orchestration platform from unintentional deletion
CN109271259B (zh) 企业服务总线系统、数据处理方法、终端及存储介质
CN111770122B (zh) 服务通信代理scp注册方法、服务调用方法及网络设备
WO2019196239A1 (zh) 一种线程接口的管理方法、终端设备及计算机可读存储介质
CN116627333A (zh) 日志缓存方法、装置、电子设备及计算机可读存储介质
CN113722114B (zh) 一种数据服务的处理方法、装置、计算设备及存储介质
CN111224814B (zh) 报文处理方法及设备
CN117742931A (zh) 大数据集群部署方案的确定方法、装置、集群和存储介质
CN115203228B (zh) 数据处理方法、装置、介质以及电子设备
WO2019134238A1 (zh) 辅助功能的执行方法、装置、存储介质及终端
CN110535724B (zh) 应用程序网络读写限制方法、装置、电子设备及存储介质
US20260006445A1 (en) Function Orchestration Method, Device and Storage Medium
CN118093219A (zh) 一种消息处理方法、装置、设备及存储介质
US11663058B1 (en) Preemptive filtering of events of an event bus with a deterministic filter
CN116186427A (zh) 时序数据查询方法及存储方法、装置、设备、存储介质
US9674282B2 (en) Synchronizing SLM statuses of a plurality of appliances in a cluster

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19867119

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19867119

Country of ref document: EP

Kind code of ref document: A1