WO2019000995A1 - System and method for data call between associated systems - Google Patents

Abstract

The present application provides a method for data call between associated systems. The method comprises: creating a plurality of threads according to the number of servers configured by a first system; when the first system receives a great number of access requests sent by a client, assigning the received access requests to the plurality of threads; and calling the plurality of threads to execute the assigned access requests, accessing a second system via a network, feeding back data obtained by the second system to the first system, and feeding back the data to the client by the first system. According to the method, a great number of access requests made at the same time are limited, and the technical problem of overload of the first system and of the second system caused by occupation of a great number of threads of the first system and unlimited remote call of the second system by the great number of threads because the great number of threads remotely call the data of the second system without limit after the first system receives the great number of access requests can be resolved. The present invention also provides a server and a computer-readable storage medium.

Description

Data calling system and method between related systems

This application claims the priority of the Chinese Patent Application filed on June 25, 2017, the Chinese Patent Office, the application number is 201710490402.8, and the invention is entitled "Data Calling System and Method between Related Systems", the entire contents of which are incorporated by reference. in.

Technical field

The present application relates to the field of data calling, and in particular, to a data calling system and method between related systems.

Background technique

In a complex application scenario, frequent real-time data interaction between two or more associated systems is required, which easily causes the associated system to be overwhelmed by an unlimited number of remotely invoked data. For example, a large number of process nodes in a business system need to invoke the data of a workflow system to perform the flow of the process, and the process flow is required to be highly time-sensitive. The general practice is that the working node of the business system directly calls the workflow system remotely, which is easy to cause the workflow system to be called by a large number of remote calls without restriction until it is crushed or even crashed.

At present, the industry-based workflow-based data processing method is to refine the minimum elements of the process definition to nodes; the definition of the process definition and the task acquisition permission are divided into two independent modules, which are no longer dependent on each other; The module, the query operation for most tasks is provided by the module, which reduces the pressure on the DB; the historical data distribution BAM module is added, and the historical data is distributed to the first systems for storage and maintenance according to the system to which the task belongs. Although this method can flexibly define the process mode, support the inter-process communication, and can quickly respond to the adjustment of the service authority, the working node of the first system does not solve the large number of remotely calling the data of the second system, resulting in the second system being unrestricted. The problem of being remotely invoked and being crushed.

Summary of the invention

The present application provides a data invoking system and method between related systems, the main purpose of which is to solve the problem that a large number of threads of the first system are remotely called due to a large number of threads of the first system, resulting in a large number of threads being occupied by the first system, and the second system. A technical problem caused by a large number of threads remotely calling without restriction, causing the first system and the second system to be compressed.

To achieve the above objective, the present application provides a method for invoking data between associated systems, the method comprising the following steps:

Create multiple threads according to the number of servers configured in the first system;

When the first system receives a large number of access requests sent by the client, the received access request is allocated to the plurality of threads; and

Invoking the plurality of threads to execute the allocated access request, accessing the second system through the network, and feeding back the data acquired from the second system to the first system, and the first system feeds back to the client. Preferably, the step of creating a plurality of threads according to the number of servers configured by the first system comprises:

Determining the number of servers configured in the first system; and

A corresponding plurality of threads are created according to the number of servers configured by the first system.

In addition, to achieve the above object, the present application further provides a server, the server including a storage device, a processor, a display, and a data call between the associated systems stored on the storage device and operable on the processor The system, when the processor executes the data invoking system between the associated systems, the following steps may be implemented:

Create multiple threads according to the number of servers configured in the first system;

When the first system receives a large number of access requests sent by the client, the received access request is allocated to the plurality of threads; and

Invoking the plurality of threads to execute the allocated access request, accessing the second system through the network, and feeding back the data acquired from the second system to the first system, and the first system feeds back to the client.

In addition, the present application further provides a computer readable storage medium storing a data invoking system between associated systems, where the data invoking system between the interrelated systems is executed by at least one processor The following steps:

Create multiple threads according to the number of servers configured in the first system;

When the first system receives a large number of access requests sent by the client, the received access request is allocated to the plurality of threads; and

Invoking the plurality of threads to execute the allocated access request, accessing the second system through the network, and feeding back the data acquired from the second system to the first system, and the first system feeds back to the client.

Compared with the prior art, the data calling system and method between the associated systems provided by the present application can simultaneously set a data calling system between the first system and the second system, and utilize the data calling system between the related systems. The access request occurs to limit the flow. When the first system receives the large-volume access request, the first system calls a large number of threads to remotely call the data of the second system in an unlimited manner, so that a large number of threads of the first system are occupied. The second system is remotely called by a large number of threads without restriction, thereby causing the first system and the second system to be overwhelmed.

DRAWINGS

1 is an application environment diagram of a preferred embodiment of a data invoking system between associated systems of the present application.

2 is a block diagram of a program of a preferred embodiment of a data invoking system between associated systems of the present application.

3 is a hardware architecture diagram of a preferred embodiment of a data invocation system between associated systems of the present application.

4 is a flow chart of a preferred embodiment of a method for invoking data between associated systems of the present application.

FIG. 5 is a detailed flowchart of step S10 in the preferred embodiment of the data invoking method between the associated systems of the present application.

FIG. 6 is a detailed flowchart of step S20 in the preferred embodiment of the data invoking method between the associated systems of the present application.

Reference mark:

1, 4	server
2	The internet
3	Client
11, 21	Storage device
12	processor
13	monitor
10	Data calling system between associated systems
110	Thread creation module
120	Request allocation module
130	Request execution module
121	Arithmetic module

122	Task allocation module

The implementation, functional features and advantages of the present application will be further described with reference to the accompanying drawings.

Detailed ways

It is understood that the specific embodiments described herein are merely illustrative of the application and are not intended to be limiting.

As shown in FIG. 1, it is an application environment diagram of a preferred embodiment of the data invoking system 10 between the related systems of the present application.

In this embodiment, the data invoking system 10 between the associated systems is installed between two or more associated systems, such as the first system A and the second system B. The first system A and the second system B are each configured with one or more servers 1. Data interaction between the first system A and the second system B is possible. The data invoking system is applied to one or more servers 1 configured by the first system A, and the one or more servers 1 are connected to one or more clients 3 via the network 2.

In this embodiment, the first system A may be a service system, such as a business system of a financial service organization, and the second system B may be a workflow system, such as a system for managing various workflow nodes of the financial service organization. . In other embodiments, the first system A may also be a business system of other organizations.

The one or more servers 1 configured by the first system A are connected to the storage device 11. The storage device 11 stores information of all customers of the financial service institution, such as customer identity information, account information, and insurance purchase information. The storage device 11 to which the one or more servers 1 are connected may be a local storage device or a storage device connected through the network 2.

The one or more servers 4 configured by the second system B are connected to the storage device 21. The storage device 21 stores data such as the status of all policy flow nodes of the financial service institution. The storage device 21 connected to the one or more servers 2 may be a local storage device or a storage device connected through the network 2.

The data invoking system 10 between the associated systems may be configured in a storage space provided by one or more servers 1 configured by the first system A. The storage space may be located in one of the one or more servers 1 of the first system A, or may be composed of storage space fragments of different servers 1 of one or more servers 1 of the first system A. a storage space.

Preferably, the data invoking system 10 between the associated systems can also be configured on a single server 1.

The network 2 can be a local area network (LAN), a wide area network (WAN), and a metropolitan area network (MAN), and can be a wired network or a fiber network. Optical Fiber Network) can also be a wireless network.

Client 3 can be a desktop computer, a notebook, a tablet, a smart phone, an e-book reader, a MP3 (Moving Picture Experts Group Audio Layer III) player, MP4 (Moving Picture Experts) Group Audio Layer IV, dynamic video expert compresses standard audio layer 4) A terminal device that can communicate with server 1 via network 2, such as a player or a portable computer.

As shown in FIG. 2, it is a program module diagram of a preferred embodiment of the data invoking system 10 between the associated systems of the present application.

In this embodiment, the associated system is a first system A and a second system B, and a data invoking system 10 between the associated systems is disposed between the first system A and the second system B, where the One system A is a business system, and the second system B is a workflow system. The data invoking system 10 between the associated systems includes a thread creation module 110, a request allocation module 120, and a request execution module 130.

The thread creation module 110 is configured to create a plurality of threads according to the number of servers 1 configured by the first system A. The thread creation module 110 creates a corresponding plurality of threads according to the number of servers 1 configured by the first system A, and the number of the multiple threads is an integer multiple of the number of servers 1 configured by the first system A. For example, if the number of servers 1 configured by the business system is five, the thread creation module 110 creates a plurality of threads, which may be five, ten, fifteen, and the like.

Specifically, the thread creation module 110 is further configured to determine the number of servers 1 configured by the first system A. Taking the service system as an example, in the process of creating a service system, for the number of servers 1 configured in the service system, the engineer will consider the maximum number of concurrent transactions that the service system may face in the future, and configure the number of servers 1 accordingly. If the number of concurrent concurrency of the service system is large, the number of servers 1 configured by the corresponding service system will increase accordingly. Of course, the number of servers 1 does not increase indefinitely due to the increase in the number of concurrent. Therefore, the thread creation module 110 may query the number of servers 1 configured by the service system from the configuration file of the service system, or query the number of servers 1 configured by the service system from related records of the service system.

The request allocation module 120 is configured to allocate the received access request to the plurality of threads when the first system A receives a large number of access requests sent by the client 3. Taking the business system as an example, the number of servers 1 configured by the business system is 5, and the thread creation module 110 creates 10 threads, and the 10 threads are sequentially numbered: 0 thread, thread 1 thread, thread 2, ... Thread No. 9, when the service system receives a large number of access requests from the client 3, the request allocation module 120 allocates a large number of access requests to the 10 threads as evenly as possible.

Further, the request allocation module 120 includes an operation module 121 and a task assignment module 122.

The operation module 121 is configured to perform a remainder (MOD) operation on the number of access requests received by the first system A and the number of the plurality of threads. For example, when the service system receives 25 access requests from the client 3, the operation module 121 performs a remainder operation on the number of access requests 25 received and the number of threads 10, and the result of the remainder of 25 and 10 is 5.

The task assignment module 122 is configured to allocate an access request to the plurality of threads according to the operation result. If the result of the operation is 0, the task assignment module 122 distributes the plurality of access requests equally to the plurality of threads. If the operation result is a, and a ≠ 0, then after subtracting a from the number of received access requests, it is evenly distributed to the plurality of threads, and then the remaining a access requests are sequentially assigned to number 0 to Thread (a-1) until the end of the division.

For example, the operation module 121 receives the number of access requests received by the service system into 20, the number of threads is 10, and the result of performing the remainder operation is 0. Then, the task assignment module 122 averages 20 access requests. Assigned to 10 threads, each thread averages 2 data requests.

If the operation module 121 receives 25 access requests from the service system, the number of threads is 10, and the result of performing the remainder operation is 5, then the 25 access requests received are subtracted from the remaining 5 After the access request, there are 20 access requests. The task assignment module 122 first distributes the 20 access requests to 10 threads, and the remaining 5 threads are sequentially assigned to the 0th thread, the 1st thread, and the 2nd thread. , thread 3 and thread 4.

Specifically, the task assignment module 122 also allocates a new access request according to the current access request processing status of each thread. For example, the business system receives 12 new access requests, and the processing requirements of the unfinished access requests of each thread are as follows: thread 1: 1; thread 3: 1; access requests assigned by other threads have been completed. deal with. Then, the number of new access requests received by the service system is 12, the number of threads is 10. The result of the operation module 121 performing the remainder operation is 2, and then the 12 access requests received are subtracted from the remaining 2 There are 10 access requests after the access request, and the task assignment module 122 first distributes the 10 access requests to 10 threads, and since the thread 1 has an unprocessed access request, the remaining 2 threads are left. It is assigned to thread 0 and thread 2 in turn.

The request execution module 130 is configured to invoke the multiple threads to perform an access request obtained by the second thread, and access the second system B through the network 2, and feed back the data acquired from the second system B to the first system A, by the first system. A feedback to client 3. Taking the life insurance industry as an example, the life insurance process includes the following nodes: insurance - underwriting - underwriting. Each life insurance business personnel accesses the business system through the client 3 and performs related operations, and the workflow system manages the various process nodes of the life insurance. If the life insurance business personnel wants to query the current processing situation of the life insurance order number xx from the business system, after the business system receives the access request, the request execution module 130 calls the thread to access the workflow system through the network 2, The data related to the life insurance order with the number xx is read, and the result is fed back to the business system, and the life insurance business personnel of the client 3 are informed that the life insurance order of the single number is currently under-warranty. For another example, the life insurance business personnel check the life insurance order with the number xx to ensure that the order information is accurate and can enter the next node—the underwriting node. Then, the life insurance business personnel perform corresponding operations on the business system. The request execution module 130 sends the signal to the workflow system, causes the life insurance order processing status to enter the next node, and then feeds back the processing result of the life insurance order to the business system, informing the life insurance business personnel of the client 3 that the order has been Enter the underwriting node.

As shown in FIG. 3, it is a hardware architecture diagram of a preferred embodiment of the data invoking system 10 between the associated systems of the present application.

In the present embodiment, the data invoking system 10 between the associated systems is applied to the server 1, which includes, but is not limited to, the storage device 11, the processor 12, and the display 13.

The storage device 11 stores program code of the data invoking system 10 between the associated systems, and the storage device 11 may include at least one type of storage medium including a flash memory, a hard disk, a multimedia card, a card type memory (for example, SD) Or DX memory, etc.), random access memory (RAM), static random access memory (SRAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), programmable read only memory (PROM) , magnetic storage, magnetic disks, optical disks, and so on.

The processor 12 may be a central processing unit (CPU), a microprocessor or other data processing chip, and a program for reading and running the stored data between the associated systems of the associated system from the storage device 11 .

The display 13 can be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an OLED (Organic Light-Emitting Diode) touch sensor, or the like. Display 13 is used to display a visualized user interface.

Preferably, the server 1 may further include a user interface, and the user interface may include a display, an input unit such as a keyboard, and optionally, the user interface may further include a standard wired interface and a wireless interface.

Figure 3 shows only the server 1 with the components 11-13 and the data invoking system 10 between the associated systems, but it should be understood that not all of the illustrated components may be implemented, and that more or fewer implementations may be implemented instead. Component.

As shown in FIG. 4, it is a flowchart of a preferred embodiment of a data invocation method between associated systems of the present application.

In this embodiment, the data calling method between the associated systems includes: steps S10, S20, and step S30.

In step S10, a plurality of threads are created according to the number of servers 1 configured by the first system A. A data invoking system 10 is set up between the first system A and the second system B. The thread creation module 110 creates a corresponding plurality of threads according to the number of servers 1 configured by the first system A. The number of the plurality of threads is an integer multiple of the number of servers 1 configured by the first system A.

Specifically, as shown in FIG. 5, step S10 includes steps S11 and S12.

In step S11, the number of servers 1 configured by the first system A is determined. Taking the service system as an example, in the process of creating a service system, for the number of servers 1 configured in the service system, the engineer will consider the maximum number of concurrent transactions that the service system may face in the future, and configure the number of servers 1 accordingly. If the number of concurrent concurrency of the service system is large, the number of servers 1 configured by the corresponding service system will increase accordingly. Of course, the number of servers 1 does not increase indefinitely due to the increase in the number of concurrent. Therefore, the thread creation module 110 may query the number of servers 1 configured by the service system from the configuration file of the service system, or query the number of servers 1 configured by the service system from related records of the service system.

Step S12: Create a corresponding plurality of threads according to the number of servers 1 configured by the first system A. The number of the plurality of threads is an integer multiple of the number of servers 1 configured by the first system A. For example, if the number of servers 1 configured by the first system A is five, the thread creation module 110 creates a plurality of threads, which may be five, ten, fifteen, and the like.

Step S20: When the first system A receives a large number of access requests from the client 3, the access request is received to the plurality of threads. Taking the business system as an example, the number of servers 1 configured by the business system is 5, and the thread creation module 110 creates 10 threads, and the 10 threads are sequentially numbered: 0 thread, thread 1 thread, thread 2, ... Thread No. 9, when the service system receives a large number of access requests from the client 3, the request allocation module 120 allocates a large number of access requests to the 10 threads as evenly as possible.

Further, as shown in FIG. 6, step S20 includes steps S21 and S22.

In step S21, the operation module 121 performs a remainder (MOD) operation on the number of access requests issued by the client 3 received by the first system A and the number of the plurality of threads. For example, when the service system receives 25 access requests from the client 3, the operation module 121 performs a remainder operation on the number of access requests 25 received and the number of threads 10, and the result of the remainder of 25 and 10 is 5.

In step S22, the task assignment module 122 allocates an access request to the plurality of threads according to the operation result. If the result of the operation is 0, the task assignment module 122 distributes the plurality of access requests equally to the plurality of threads. If the operation result is a, and a ≠ 0, then after subtracting a from the number of received access requests, it is evenly distributed to the plurality of threads, and then the remaining a access requests are sequentially assigned to number 0 to Thread (a-1) until the end of the division.

For example, the operation module 121 receives the number of access requests received by the service system into 20, the number of threads is 10, and the result of performing the remainder operation is 0. Then, the task assignment module 122 averages 20 access requests. Assigned to 10 threads, each thread averages 2 data requests.

For another example, if the operation module 121 receives the number of access requests received by the first system A into 25, the number of threads is 10, and the result of performing the remainder operation is 5, then the 25 access requests received are subtracted. There are 20 access requests after the remaining 5 access requests, and the task assignment module 122 first distributes the 20 access requests to 10 threads, and the remaining 5 threads are sequentially assigned to the 0th thread and the 1st. Thread, thread 2, thread 3, and thread 4.

Specifically, step S22 also allocates a new access request according to the current access request processing status of each thread. For example, the business system receives 12 new access requests, and the processing requirements of the unfinished access requests of each thread are as follows: thread 1: 1; thread 3: 1; access requests assigned by other threads have been completed. deal with. Then, the number of new access requests received by the service system is 12, the number of threads is 10. The result of the operation module 121 performing the remainder operation is 2, and then the 12 access requests received are subtracted from the remainder. After two access requests, there are 10 access requests. The task assignment module 122 first distributes the 10 access requests to 10 threads, and since the thread 1 has an unprocessed access request, the remaining 2 will be left. The threads are assigned to the 0th thread and the 2nd thread in turn.

In step S30, the request execution module 130 calls the multiple threads to perform the allocated access request, accesses the second system B through the network 2, and feeds back the data acquired from the second system B to the first system A. The first system A feeds back to the client 3. Taking the life insurance industry as an example, the life insurance process includes the following nodes: insurance - underwriting - underwriting. Each life insurance business personnel accesses the business system through the client 3 and performs related operations, and the workflow system manages the various process nodes of the life insurance. If the life insurance business personnel wants to query the current processing situation of the life insurance order number xx from the business system, after the business system receives the access request, the request execution module 130 calls the thread to access the workflow system through the network 2, The data related to the life insurance order with the number xx is read, and the result is fed back to the business system, and the life insurance business personnel of the client 3 are informed that the life insurance order of the single number is currently under-warranty. For another example, the life insurance business personnel check the life insurance order with the number xx to ensure that the order information is accurate and can enter the next node—the underwriting node. Then, the life insurance business personnel perform corresponding operations on the business system. The request execution module 130 sends the signal to the workflow system, causes the life insurance order processing status to enter the next node, and then feeds back the processing result of the life insurance order to the business system, informing the life insurance business personnel of the client 3 that the order has been Enter the underwriting node.

Moreover, the application further includes a computer readable storage medium storing a data invoking system 10 between associated systems.

In this embodiment, the data invoking system 10 between the associated systems is executed by at least one processor 12 to implement steps S10, S20, and S30.

In step S10, a plurality of threads are created according to the number of servers 1 configured by the first system A. A data invoking system 10 is set up between the first system A and the second system B. The thread creation module 110 creates a corresponding plurality of threads according to the number of servers 1 configured by the first system A. The number of the plurality of threads is an integer multiple of the number of servers 1 configured by the first system A.

Specifically, step S10 includes: step S11 and step S12.

In step S11, the number of servers 1 configured by the first system A is determined. Taking the service system as an example, in the process of creating a service system, for the number of servers 1 configured in the service system, the engineer will consider the maximum number of concurrent operations that the service system may face in the future, and configure the number of servers 1 in this way. If the number of concurrent concurrency of the service system is large, the number of servers 1 configured by the corresponding service system will increase accordingly. Of course, the number of servers 1 does not increase indefinitely due to the increase in the number of concurrent. Therefore, the thread creation module 110 may query the number of servers 1 configured by the service system from the configuration file of the service system, or query the number of servers 1 configured by the service system from related records of the service system.

Step S12: Create a corresponding plurality of threads according to the number of servers 1 configured by the first system A. The number of the plurality of threads is an integer multiple of the number of servers 1 configured by the first system A. For example, if the number of servers 1 configured by the first system A is five, the thread creation module 110 creates a plurality of threads, which may be five, ten, fifteen, and the like.

Step S20: When the first system A receives a large number of access requests from the client 3, the access request is received to the plurality of threads. Taking the business system as an example, the number of servers 1 configured by the business system is 5, and the thread creation module 110 creates 10 threads, and the 10 threads are sequentially numbered: 0 thread, thread 1 thread, thread 2, ... Thread No. 9, when the service system receives a large number of access requests from the client 3, the request allocation module 120 allocates a large number of access requests to the 10 threads as evenly as possible.

Further, step S20 includes: step S21 and step S22.

In step S21, the operation module 121 performs a remainder (MOD) operation on the number of access requests issued by the client 3 received by the first system A and the number of the plurality of threads. For example, when the service system receives 25 access requests from the client 3, the operation module 121 performs a remainder operation on the number of access requests 25 received and the number of threads 10, and the result of the remainder of 25 and 10 is 5.

In step S22, the task assignment module 122 allocates an access request to the plurality of threads according to the operation result. If the result of the operation is 0, the task assignment module 122 distributes the plurality of access requests equally to the plurality of threads. If the operation result is a, and a ≠ 0, then after subtracting a from the number of received access requests, it is evenly distributed to the plurality of threads, and then the remaining a access requests are sequentially assigned to number 0 to Thread (a-1) until the end of the division.

For example, the operation module 121 receives the number of access requests received by the service system into 20, the number of threads is 10, and the result of performing the remainder operation is 0. Then, the task assignment module 122 averages 20 access requests. Assigned to 10 threads, each thread averages 2 data requests.

For another example, if the operation module 121 receives the number of access requests received by the first system A into 25, the number of threads is 10, and the result of performing the remainder operation is 5, then the 25 access requests received are subtracted. There are 20 access requests after the remaining 5 access requests, and the task assignment module 122 first distributes the 20 access requests to 10 threads, and the remaining 5 threads are sequentially assigned to the 0th thread and the 1st. Thread, thread 2, thread 3, and thread 4.

Specifically, step S22 also allocates a new access request according to the current access request processing status of each thread. For example, the business system receives 12 new access requests, and the processing requirements of the unfinished access requests of each thread are as follows: thread 1: 1; thread 3: 1; access requests assigned by other threads have been completed. deal with. Then, the number of new access requests received by the service system is 12, the number of threads is 10. The result of the operation module 121 performing the remainder operation is 2, and then the 12 access requests received are subtracted from the remainder. After two access requests, there are 10 access requests. The task assignment module 122 first distributes the 10 access requests to 10 threads, and since the thread 1 has an unprocessed access request, the remaining 2 will be left. The threads are assigned to the 0th thread and the 2nd thread in turn.

In step S30, the request execution module 130 calls the multiple threads to perform the allocated access request, accesses the second system B through the network 2, and feeds back the data acquired from the second system B to the first system A. The first system A feeds back to the client 3. Taking the life insurance industry as an example, the life insurance process includes the following nodes: insurance - underwriting - underwriting. Each life insurance business personnel accesses the business system through the client 3 and performs related operations, and the workflow system manages the various process nodes of the life insurance. If the life insurance business personnel wants to query the current processing situation of the life insurance order number xx from the business system, after the business system receives the access request, the request execution module 130 calls the thread to access the workflow system through the network 2, The data related to the life insurance order with the number xx is read, and the result is fed back to the business system, and the life insurance business personnel of the client 3 are informed that the life insurance order of the single number is currently under-warranty. For another example, the life insurance business personnel check the life insurance order with the number xx to ensure that the order information is accurate and can enter the next node—the underwriting node. Then, the life insurance business personnel perform corresponding operations on the business system. The request execution module 130 sends the signal to the workflow system, causes the life insurance order processing status to enter the next node, and then feeds back the processing result of the life insurance order to the business system, informing the life insurance business personnel of the client 3 that the order has been Enter the underwriting node.

It is to be understood that the term "comprises", "comprising", or any other variants thereof, is intended to encompass a non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes those elements. It also includes other elements that are not explicitly listed, or elements that are inherent to such a process, method, article, or device. An element that is defined by the phrase "comprising a ..." does not exclude the presence of additional equivalent elements in the process, method, item, or device that comprises the element.

The "one embodiment" and "another embodiment" mentioned in the embodiment may be the same embodiment or different embodiments.

It should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and are not intended to be limiting, although the present application is described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technology of the present application can be applied. Modifications or equivalents are made without departing from the spirit and scope of the technical solutions of the present application.

Claims (20)

1. A method for invoking data between associated systems, the method comprising:

   Create multiple threads according to the number of servers configured in the first system;

   When the first system receives a large number of access requests sent by the client, the received access request is allocated to the plurality of threads; and

   Invoking the plurality of threads to execute the allocated access request, accessing the second system through the network, and feeding back the data acquired from the second system to the first system, and the first system feeds back to the client.
2. The method for invoking data between the associated systems according to claim 1, wherein the step of creating a plurality of threads according to the number of servers configured by the first system comprises:

   Determining the number of servers configured in the first system; and

   A corresponding plurality of threads are created according to the number of servers configured by the first system.
3. The method for invoking data between the associated systems according to claim 1, wherein when the first system receives a large number of access requests sent by the client, the received access request is allocated to the plurality of The steps of the thread include:

   Performing a remainder operation on the number of access requests sent by the client received by the first system and the number of the plurality of threads;

   An access request is allocated to the plurality of threads according to the result of the operation.
4. The method for invoking data between the associated systems according to claim 2, wherein when the first system receives a large number of access requests sent by the client, the received access request is allocated to the plurality of The steps of the thread include:

   Performing a remainder operation on the number of access requests sent by the client received by the first system and the number of the plurality of threads;

   An access request is allocated to the plurality of threads according to the result of the operation.
5. The method for invoking data between associated systems according to claim 1, wherein the number of the plurality of threads is an integer multiple of the number of servers configured by the first system.
6. The method for invoking data between associated systems according to claim 2, wherein the number of the plurality of threads is an integer multiple of the number of servers configured by the first system.
7. The method for invoking data between associated systems according to claim 3 or 4, wherein the number of the plurality of threads is an integer multiple of the number of servers configured by the first system.
8. A server comprising: a storage device, a processor, a display, and a data invoking system stored between the associated systems on the storage device and operative on the processor, the processor executing the association When the data between the systems calls the system, the following steps can be implemented:

   Create multiple threads according to the number of servers configured in the first system;

   When the first system receives a large number of access requests sent by the client, the received access request is allocated to the plurality of threads; and

   Invoking the plurality of threads to execute the allocated access request, accessing the second system through the network, and feeding back the data acquired from the second system to the first system, and the first system feeds back to the client.
9. The server according to claim 8, wherein the step of creating a plurality of threads according to the number of servers configured by the first system comprises:

   Determining the number of servers configured in the first system; and

   A corresponding plurality of threads are created according to the number of servers configured by the first system.
10. The server according to claim 8, wherein when the first system receives a large number of access requests sent by the client, the step of assigning the received access requests to the plurality of threads comprises:

    Performing a remainder operation on the number of access requests sent by the client received by the first system and the number of the plurality of threads;

    An access request is allocated to the plurality of threads according to the result of the operation.
11. The server according to claim 9, wherein when the first system receives a large number of access requests sent by the client, the step of assigning the received access request to the plurality of threads comprises:

    Performing a remainder operation on the number of access requests sent by the client received by the first system and the number of the plurality of threads;

    An access request is allocated to the plurality of threads according to the result of the operation.
12. The server of claim 8, wherein the number of the plurality of threads is an integer multiple of the number of servers configured by the first system.
13. The server of claim 9, wherein the number of the plurality of threads is an integer multiple of the number of servers configured by the first system.
14. A server according to claim 10 or 11, wherein the number of said plurality of threads is an integer multiple of the number of servers configured by said first system.
15. A computer readable storage medium, characterized in that the computer readable storage medium stores a data invoking system, the data invoking system being executable by at least one processor to implement the following steps:

    Create multiple threads according to the number of servers configured in the first system;

    When the first system receives a large number of access requests sent by the client, the received access request is allocated to the plurality of threads; and

    Invoking the plurality of threads to execute the allocated access request, accessing the second system through the network, and feeding back the data acquired from the second system to the first system, and the first system feeds back to the client.
16. The computer readable storage medium of claim 15, wherein the step of creating a plurality of threads according to the number of servers configured by the first system comprises:

    Determining the number of servers configured in the first system; and

    A corresponding plurality of threads are created according to the number of servers configured by the first system.
17. The computer readable storage medium according to claim 15, wherein when the first system receives a large number of access requests sent by the client, the received access request is allocated to the plurality of threads. The steps include:

    Performing a remainder operation on the number of access requests sent by the client received by the first system and the number of the plurality of threads;

    An access request is allocated to the plurality of threads according to the result of the operation.
18. The computer readable storage medium according to claim 16, wherein when the first system receives a large number of access requests sent by the client, the received access request is allocated to the plurality of threads. The steps include:

    Performing a remainder operation on the number of access requests sent by the client received by the first system and the number of the plurality of threads;

    An access request is allocated to the plurality of threads according to the result of the operation.
19. The computer readable storage medium of claim 15 or 16, wherein the number of the plurality of threads is an integer multiple of the number of servers configured by the first system.
20. The computer readable storage medium of claim 17 or 18, wherein the number of the plurality of threads is an integer multiple of the number of servers configured by the first system.

Images