JP5291504B2 - Load balancing processing system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To distribute processing requests according to a load state on a service provider. <P>SOLUTION: The service user API84 is provided for each service user process 81, and the service provider API87 is provided for each service provider process 82. The service user API84 refers to a processing request queue information storage region 86 and transmits the processing request to the service provider process 82 having the least number of uncompleted processing requests. The service provider API87 records the number of processing request receptions and the number of processed result transmissions in a service provider queue information storage region 88 for each service user process 81, and periodically transmits the number of processing request receptions and the number of processed result transmissions of each service user process 81 to a management daemon 83. The management daemon 83 periodically transmits client queue information to each service user process 81. The client queue information includes the number of uncompleted processing requests in each service provider process 82. <P>COPYRIGHT: (C)2011,JPO&amp;INPIT

Description

  The present invention relates to a load distribution processing system, and in particular, a mode in which a plurality of processes on a service providing side accept processing requests from a plurality of processes on a service using side, perform parallel processing, and return the processing results to the service using process. In this information processing system, the load on the service providing side process is distributed to improve the processing capacity of the entire system.

  In a client-server type information processing system, a method is adopted in which the processing capacity of the entire system is expanded by adding server machines to increase the amount of information processing and improving the parallelism of processing. As described above, in order to improve system performance by parallelizing processing, a load distribution function for appropriately distributing processing requests among a plurality of service providing processes that perform processing is necessary. For this reason, various load distribution processing methods have been devised so far.

  For example, in the case of the load distribution processing method called round robin, processing requests are distributed in order to the service providing side processes in parallel, and there is an advantage that can be realized by simple implementation. Because the load on the side process is not considered at all, the next processing request is also mechanically allocated to the service provider process that is executing heavy processing, which may lead to a situation where appropriate load balancing cannot be performed. there were.

  On the other hand, in the method of acquiring CPU load information from each service provider side process and sending a processing request to the service provider process with the lowest CPU load, at first glance, the actual load of each service provider process Appropriate distributed processing is likely to be realized, but in processing where DISK IO is a bottleneck, processing may be stagnant even though the CPU load is low, so appropriate load distribution can also be performed There can be no situations.

  In addition, a service request is issued to the service provider processes all at once by broadcast communication, and the person who can perform the earliest processing makes a process declaration to the remaining service provider processes, and this service provider has given this name. There is also a load balancing method in which only the process on the side executes the process, but in this case, the process declarations are complicatedly mixed among the service provider processes, so the same process is mistakenly executed in multiple service provider processes. Network load increases due to the occurrence of accidents and frequent occurrences of processing declaration messages.

Patent Document 1 discloses a technique in which a load distribution processing device is interposed between a client and a server, and the load distribution processing device distributes requests from the client to the server with the lowest load and the highest priority. It is disclosed. For this purpose, the load distribution processing device includes storage means for storing the priority order information of each server, the maximum processing amount and the execution processing amount of each server.
JP2007-52542A

In the case of the load distribution processing system of Patent Document 1, since all requests and processing result data pass through the load distribution processing apparatus, the load distribution processing apparatus can accurately recognize the load status of each server. Become.
However, as compared with the case where the request and the processing result data are directly exchanged between the client and the server, a transmission delay due to passing through the load distribution processing device inevitably occurs. In addition, when the load is high, the load is concentrated on the load distribution processing apparatus, and there is a possibility that the performance of the entire system is deteriorated.

  The present invention has been devised to solve such a conventional problem, and can distribute processing requests according to the load situation of each service providing side process, and further, processing requests and processing results. The purpose is to provide a load distribution processing technology that can directly communicate between a service using process and a providing process.

  In order to achieve the above object, the load distribution processing system according to claim 1 executes a plurality of service using processes that generate processing requests, executes necessary processing for the processing requests, and outputs processing results. A plurality of service providing side processes, a processing request allocating unit provided for each service using side process, a load information managing unit provided for each service providing side process, and a load information distributing unit In the load distribution processing system, the processing request distribution unit stores, for each service providing side process, the number of incomplete processing requests related to all service using side processes handled by the service providing side process. When the processing request is passed from the first storage area to be stored and the service user side process in charge, the first storage area is referred to, and the number of incomplete processing requests is the highest. A function for identifying a few service providing side processes, a function for transmitting a processing request to the load information managing unit related to the service providing side process, and a processing result by the service providing side process are received from the load information managing unit, When the function passed to the service use side process and the number of incomplete processing requests related to all service use side processes for each service providing side process are transmitted from the load information distribution unit, this is stored in the first storage area. It has a function to update the number of incomplete processing requests for each stored service providing process, and the load information management unit receives the processing request of the service using side process from the corresponding processing request distribution unit and is responsible for it The function to be passed to the service provider process and the processing result passed from the service provider process A function for returning to the processing request distribution unit of the process, a second storage area for storing the number of processing request receptions and the number of processing result replies for each service-use process, and receiving the processing request from the processing request distribution unit A function of adding 1 to the number of received processing requests each time, a function of adding 1 to the number of processing result replies each time a processing result is returned to the processing request distribution unit, and a predetermined timing, The load information distribution unit has a function of transmitting the number of received processing requests and the number of processing result replies related to each service using side process to the load information distributing unit. A third storage area for storing the number of processing request receptions and the number of processing result replies related to the process, and each service using side process for each service providing side process at a predetermined timing Subtract the number of processing result replies from the number of processing request receptions to obtain the number of incomplete processing requests, add this to all service using processes, and the unrelated to all service using processes for each service providing process A feature is that it has a function of transmitting the number of completed processing requests to each processing request distribution unit.

  Further, the load distribution processing system according to claim 2 is based on the system of claim 1, and when the load information management unit returns the processing result to the processing request distribution unit of the service user side process, It has a function to calculate the total value of the number of processing request receptions related to each service user side process and the total value of the number of processing result replies related to each service user side process, and send it to the processing request distribution part together with the processing result Then, the processing request distribution unit subtracts the total value of the processing result reply number from the total value of the processing request reception number, and calculates the number of incomplete processing request numbers related to all the service using side processes of the service providing side process. A function to update the number of incomplete processing requests related to the service providing side process in the first storage area according to the function to be obtained and the number of incomplete processing requests. It is characterized by comprising.

  The load distribution processing system according to claim 3, a plurality of service using processes that generate processing requests, a plurality of service providing processes that execute processing necessary for the processing requests and output processing results, A load distribution processing system comprising a processing request distribution unit provided for each service using side process, a load information management unit provided for each service providing side process, and a load information distribution unit, For each service providing side process, the above processing request distribution unit determines the number of self requesting requests that are the number of incomplete processing requests that are being transmitted to the service providing side process, and other service using side processes The first storage area for storing the number of other requests that are the total number of incomplete processing requests being sent to the providing process, and the service using side A function that identifies the service providing side process with the smallest number of unfinished processing requests, which is the sum of the number of self-requests and the number of other requests, by referring to the first storage area when a processing request is passed from the service The function of transmitting a processing request to the load information management unit related to the service providing side process, the function of adding 1 to the number of self requests related to the service providing side process, and the processing result received from the load information management unit In this case, a function of subtracting 1 from the number of self-requests related to the service providing side process, a function of passing the processing result to the service using side process, and another service for each service providing side process from the load information distribution unit When the total number of incomplete processing requests related to the process on the user side is transmitted, it has a function of updating the number of other requests stored in the first storage area by this, The load information management unit receives the processing request of the service using side process from the corresponding processing request allocating unit and passes the processing result passed from the service providing side process to the service providing side process that it is responsible for , A function for returning to the processing request distribution unit of the service using side process, a second storage area for storing the number of received processing requests and the number of processing result returning for each service using side process, and the processing request to the processing request A function of adding 1 to the number of received processing requests each time receiving from the allocating unit; a function of adding 1 to the number of response of processing results each time a processing result is returned to the processing request allocating unit; At a predetermined timing, it has a function of transmitting the processing request reception number and processing result reply number related to each service using side process to the load information distribution unit, the load information distribution unit, A third storage area for storing the number of received processing requests and the number of processing result replies related to each service using side process transmitted from each load information management unit, and for each service providing side process at a predetermined timing, A function that subtracts the number of processing result replies from the number of processing request receptions related to the service using process to obtain the number of incomplete processing requests, and adds this to all service using processes, and all services for each service providing process A function for subtracting the number of incomplete processing requests for each service user side process from the number of incomplete processing requests for the user side process and calculating the number of other requests for each service user side process, and the number of other requests Is provided to the processing request distribution unit related to the corresponding service using side process.

  The load distribution processing system according to claim 4 is based on the system of claim 3, and further, when the load information management unit returns the processing result to the processing request distribution unit of the service use side process, It has the function to calculate the aggregate value of the number of processing request receptions related to the user side process and the total value of the processing result reply counts related to each service usage side process, and send it to the processing request distribution unit together with the processing result. The processing request distribution unit subtracts the total value of the processing result response number from the total value of the processing request received number, and calculates the number of other requests by subtracting the number of own requests from the difference. , And a function of updating the number of other requests related to the corresponding service providing process in the first storage area.

  The load distribution processing system according to claim 5 is based on the system according to claims 1 to 4, and further, when the processing request distribution unit transmits the processing request to the load information management unit of the service providing side process, A function for determining whether or not the number of incomplete processing requests related to the service providing side process exceeds a preset threshold, and if the number exceeds the threshold, the processing request is For each processing request stored in the fourth storage area, refer to the first storage area each time the storage information in the storage area is updated and the storage information in the first storage area is updated. A function that identifies the service providing side process with the smallest number of incomplete processing requests and whether or not the number of incomplete processing requests of the service providing process is equal to or less than a preset threshold. The processing request is characterized by having a function of transmitting the load information management unit of the corresponding serving process if.

  The load distribution processing system according to claim 6 is based on the system according to claims 1 to 5, and the service using process calculates a price according to a preset rule at a preset timing, It consists of multiple ordering processes of the securities transaction auto-execution system that executes the process of generating new order information for the quantity allocated to itself based on the price, and the service provider process connects the ordering process and the gateway process. Intervening, accepting the order information generated by the ordering process and sending it to the gateway process, and executing the process of sending the order confirmation information from the stock exchange computer sent from the gateway process to the ordering process And the processing request distribution unit is configured as described above. The order information generated by the ordering process is transmitted as the processing request to the load information management unit of the reception process, and the order confirmation information transmitted from the load information management unit of the reception process is used as the processing result as the ordering process. The load information management unit receives the order information as the processing request from the processing request distribution unit of the ordering process, passes the order information to the receiving process, and as the processing result passed from the receiving process. The order confirmation information is transmitted to the processing request distribution unit of the ordering process.

  The load distribution processing system according to claim 7 is based on the system of claim 6, wherein the service using side process is composed of the reception process, and the service providing side process is composed of the gateway process. The request distribution unit transmits the order information passed from the reception process to the load information management unit of the gateway process as the processing request, and the order confirmation information transmitted from the load information management unit of the gateway process. The load information management unit receives the order information as the processing request from the processing request distribution unit of the receiving process, passes it to the gateway process, and is passed from the gateway process as the processing result. Order confirmation information as a result of the above processing It is characterized by transmitting to the processing request distribution unit.

In the case of the load distribution processing system according to claim 1, the load information management unit provided for each service providing side process loads information on the service providing side process (the number of received processing requests and the number of processing result replies for each service using side process). ) And the load information is periodically transmitted to the load information distribution unit. Further, load information (number of uncompleted processing requests) for each service using side process is periodically distributed from the load information distributing unit to the processing request distributing unit provided for each service using side process. As a result, the processing request allocating unit of each service using side process refers to the above load information when transmitting the processing request generated by the service using side process, so that the service providing side process with the smallest load is provided. It is possible to send a processing request to. Since this load information is not CPU load information but consists of the number of incomplete processing requests, it can be said that it accurately represents the actual load status of each service providing process.
In addition, since the processing request and the processing result are directly exchanged between the processing request distribution unit of the service using process and the load information management unit of the service providing process, the processing request and the processing result pass through the load distribution processing device as in Patent Document 1. Compared to the case, transmission / reception of electronic messages is made more efficient. Further, there is no possibility that the performance of the entire system is deteriorated due to the concentration of the load on the load distribution processing apparatus.
Collection and distribution of load information is not performed in real time, but is a system that is executed collectively at predetermined time intervals, so that network load is not increased due to frequent occurrence of load information.

  In the case of the load distribution processing system according to claim 3, in addition to the effect of claim 1, “the number of self-requests” issued by the service use side process in charge of the load information held by the processing request distribution unit. And the number of other requests issued by all other service-using processes, and the processing request distribution unit itself has a mechanism to manage the increase / decrease in the number of requests, so at least the self The load information of each service providing side process related to the service using side process in charge can be maintained in the latest state in real time without waiting for the delivery from the load information delivery unit.

  In the case of the load distribution processing system according to claim 2 and 4, when the load information management unit returns the processing result by the service providing side process to the processing request distribution unit of the service providing side process, the service provided by itself The load information at the current time of the side process is returned together, and the processing request distribution unit has a mechanism to update the load information managed by itself based on this latest load information, so every time a processing result is received, At least the load information related to the service providing process can be updated.

  In the load distribution processing system according to claim 5, when the number of incomplete processing requests of the service providing side process having the smallest load exceeds a predetermined threshold, the entire service providing side process has a high load. Since it is determined that the processing request is stored, the processing request is temporarily stored in the fourth storage area for standby, and the processing request is transmitted after the high load state is resolved. It is possible to effectively avoid a risk that a failure such as a system failure occurs due to a continuous transmission of a processing request to the service providing side process that has fallen.

  FIG. 1 is a schematic diagram showing the overall configuration of a load distribution processing system 80 according to the present invention, which includes a plurality of service using side processes 81, a plurality of service providing side processes 82, and a management daemon 83. The management daemon 83 corresponds to a “load information distribution unit”.

  In addition, the service using process 81 includes an API (Application Program Interface) for load distribution processing. This service-use-side API 84 corresponds to a “processing request distribution unit”, and a distribution waiting request storage area (corresponding to a “fourth storage area”) 85 that temporarily stores processing request data waiting for distribution. The processing request queue information storage area (corresponding to the “first storage area”) 86 for storing the processing request queue information is provided.

  The service providing side process 82 includes an API for load distribution processing. The service providing side API 87 corresponds to a “load information management unit” and includes a service providing side queue information storage area (corresponding to a “second storage area”) 88 for storing service providing side queue information.

The service using side API 84 and the service providing side API 87 are configured by functions provided by common middleware.
The management daemon 83 is a middleware resident program, and includes a management daemon queue information storage area 89 for storing management daemon queue information.
Between each service using side API 84 and each service providing side API 87, between each service using side API 84 and the management daemon 83, and between each service providing side API 87 and the management daemon 83, TCP / IP (Transmission Control Protocol) / Internet Protocol).

In the load distribution processing system 80, the processing request data and the processing result data are transmitted and received directly between the service using side API 84 and the service providing side API 87, and the management daemon 83 does not relay them.
In addition, information indicating its own load status is periodically transmitted from the service providing process to the management daemon 83 at regular intervals, and from the management daemon 83 to each service using process, Information indicating the load status of each service providing process is periodically transmitted at regular intervals.
Each service using process refers to the information sent from the management daemon 83, selects the service providing process with the least load, and transmits a processing request.
The operation of this load distribution processing system will be described below with reference to the flowcharts of FIGS.

  First, when any processing request occurs in the service using side process, the service using side API 84 is activated by the service using side process 81 (S60 in FIG. 2). When the service using side API 84 receives a processing request from the service using side process 81 (S61), it refers to the processing request queue information and identifies the service providing side process 82 with the smallest load (S12).

That is, in the processing request queue information storage area 86, as shown in FIG. 4, a record having data items of a service providing side ID (configured of IP address + process ID), the number of own requests, and the number of other requests. Stored for each service providing process.
Here, the “number of self-requests” means the number of incomplete processing requests issued by the service using process itself to the service providing process, and is information that is updated from time to time by the service using API 84. is there.
On the other hand, “the number of other requests” means the number of incomplete processing requests issued to the service providing side process by a service using side process other than the service using side process. This is information that is updated by the service using API 84 based on the client queue information that is transmitted automatically.
Therefore, the service use side API 84 recognizes the service providing side process 82 having the smallest sum of the number of self requests and the number of other requests as the service providing side process with the smallest load.

Next, the service using side API 84 determines whether or not the value of “the number of own requests + the number of other requests” related to the service providing side process with the smallest load is larger than a preset threshold value (S63). ).
If the determination result is YES, this means that the service providing side process is in a high load state, and the service using side API 84 refrains from issuing a processing request immediately. Specifically, the processing request data is temporarily stored in the distribution wait request storage area 85 (S84).

On the other hand, when a NO determination result is obtained in S63, the service using side API 84 adds “1” to the value of “the number of self requests” of the record of the service providing side process 82 (S65), A processing request is transmitted to the service providing side process 82 (S66).
When there are a plurality of service providing side processes 82 in which the total value of the number of self-requests and the number of other requests is minimized, the service using side API 84 sets one service providing side process 82 according to a predetermined rule (for example, round robin method). Select and send processing request.

Receiving this, the service providing side API 87 searches the service providing side queue information storage area 88 and extracts the record of the service using side process 81 (S67).
That is, as shown in FIG. 5, the service providing side queue information storage area 88 includes data items such as a service using side ID (consisting of IP address + process ID), the number of received processing requests, and the number of processing request replies. A record is stored for each service using process 81.
For this reason, the service providing side API 87 can specify the record of the service using side process 81 by the IP address and the process ID included in the processing request transmitted from the service using side process 81.

Incidentally, the “number of processing request received” is a data item for recording the cumulative number of processing requests received from the service using process 81, and the “processing request reply count” is sent to the service using process 81. This is a data item for recording the cumulative number of processing results, and is updated as needed by the service providing side API 87.
By subtracting the number of processing request replies from the number of received processing requests, the number of incomplete processing requests currently being processed can be determined.

  Next, the service providing side API 87 adds “1” to the number of received processing requests of the record of the extracted service using side process 81 (S68), associates the processing request with the record (S69), and then provides the service providing side process. The processing request is passed to 82 (S70).

Receiving this, the service providing side process 82 executes necessary processing.
When the service providing side API 87 receives the processing result from the service providing side process 82 (S71), "1" is added to the number of processing request replies in the record of the service using side process 81 (S72).

Next, the service providing side API 87 generates summary information of the service providing side queue information (S73).
As shown in FIG. 6, the summary information of the service providing side queue information includes data items of the number of processing request receptions and the number of processing request replies. The total value of the number of processing requests related to all the service using side processes 81 handled, and the “number of processing request replies” is the total number of processing request numbers related to all the service using side processes 81 handled by the service providing side process 82 Is stored.
To this end, the service providing side API 87 adds the number of processing request receptions related to all the records of the service providing side queue information to calculate the number of processing request receptions of summary information, and similarly, processes related to all the records of the service providing side queue information The number of request replies is added to calculate the number of processing request replies for summary information.

Next, the service providing side API 87 returns the processing result and summary information to the service using side API 84 (S74).
Receiving this, the service using side API 84 searches the processing request queue information storage area 86 using “IP address + process ID” of the service providing side process 82 as a key, and extracts the record of the service providing side process 82. (S75).
Next, the service use side API 84 subtracts “1” from the “number of requests” of the record (S76), and then passes the processing result to the service use side process 81 (S77).

Next, the service using side API 84 updates the “number of other requests” in the record of the service providing side process 82 based on the summary information transmitted from the service providing side API 87 (S78).
Specifically, the latest "number of other requests" is obtained by subtracting the number of processing request replies from the number of received processing requests in the summary information and further subtracting the number of self-requests from the calculation result. Overwrite "Number of other requests" in the above record.

  On the other hand, each time the preset timing arrives (S79), the service providing side API 87 transmits all records of the service providing side queue information related to each service using side process 81 to the management daemon 83 (S80). .

Receiving this, the management daemon 83 searches the management daemon queue information storage area 89 and extracts a record of each service using side process 81 related to the service providing side process 82 (S81).
That is, in the management daemon queue information storage area 89, as shown in FIG. 7, the service providing side ID (IP address + process ID), the service using side ID (IP address + process ID), the number of received processing requests, the processing request A record having data items for the number of replies is stored for each service providing process × service using process.
For this reason, the management daemon 83 extracts all records related to the service providing side process 82 based on the IP address and process ID transmitted from the service providing side process 82, and then sets the service using side ID of each service providing side queue information as the service using side ID. Corresponding records can be identified based on this.

Next, the management daemon 83 overwrites and updates the processing request reception number and the processing request reply number of the management daemon queue information with the service providing side queue information transmitted from the service providing side process 82 (S82).
The service provider side queue information is periodically and asynchronously transmitted from each service provider side process 82, and the management daemon 83 receiving this information records each time the management daemon queue information relates to the service provider side process 82. Update.

The management daemon 83 generates client queue information based on the management daemon queue information every time a preset timing arrives (S83).
As shown in FIG. 8, this client queue information includes data items of a service providing side ID (IP address + process ID) and the number of other requests, and each service providing side process 81 has a data item in each service providing side process 82. The “number of other requests (total value of the number of incomplete processing requests related to service using side processes other than the service using side process)” is calculated and used as client queue information.

  For example, as shown in FIG. 9, there are 10 service providing processes X being processed (incomplete), of which 2 are for service using process A and 2 are for service using process B. If there are 5 cases for the service use side process C, the “other requests for each service use side process of the service providing side process X according to the total number of cases being processed—the number of cases for each service use side process” “Number of cases” is calculated as follows: A = 8, B = 5, C = 7.

  In addition, there are 15 cases where the service providing process Y is being processed, of which 7 are for the service using process A, 2 are for the service using process B, and 2 are for the service using process C. If there are six cases, the “number of other requests” for each service user side process of the service provider side process Y is 8 for A, B It is calculated as follows: use = 13 cases, C use = 9 cases.

  Similarly, there are 20 cases where the service providing process Z is being processed, of which 8 are for the service using process A, 6 are for the service using process B, and 6 are for the service using process C. The number of “other requests” for each service using side process of the service providing side process Z is 12 for A according to the total number of processes being processed—the number of processes for each service using side process. For B = 14 cases, C = 14 cases are calculated.

Finally, the client queue information for each service using process 81 is completed by aggregating the number of other requests in each service providing process 82 for each service using process 81.
Next, the management daemon 83 transmits client queue information for each service using side process to the corresponding service using side API 84 (S85).

Receiving this, each service using side API 84 overwrites the number of other requests related to each service providing side process 82 in the processing request queue information (S86).
In S78 described above, only the number of other requests related to the service provider process 82 is updated based on the summary information transmitted from the service provider API 87 together with the processing result, whereas in S86 all services are updated. The contents of the two processes are different in that the number of other requests related to the providing process 82 is updated all at once.

  By the way, in S68, when the value of “the number of self requests + the number of other requests” related to the service providing side process 82 with the smallest load is larger than a predetermined threshold value, the process request data is waited for distribution in S64. Although it has been described that it is stored in the request storage area 85, the handling of this distribution waiting request will be described with reference to the flowchart of FIG.

First, whenever the processing request queue information is updated as in S76, S78, and S86 (S90), the service using side API 84 refers to the processing request queue information and identifies the service providing side process 82 with the smallest load. (S91), it is determined whether or not the value of “the number of own requests + the number of other requests” related to the service providing side process 82 is equal to or less than a preset threshold value (S92).
Then, when “the number of self-requests + the number of other requests” related to the service providing side process 82 is equal to or less than a predetermined threshold, the service using side API 84 sets the value of “the number of self-requesting” in the record of the service providing side process 82. After adding “1” to (S93), a processing request is transmitted to the service providing side process 82 (S94).

When the processing result is returned from the service providing side process 82 (S96), the service using side API 84 searches the processing request queue information storage area 86 using the “IP address + process ID” of the service providing side process 82 as a key. Then, a record of the service providing side process 82 is extracted (S97).
Next, the service use side API 84 subtracts “1” from the “number of requests” of the record (S98), and then passes the processing result to the service use side process 81 (S99).

  In the above description, the load distribution processing system 10 is exemplified by the middleware API (the service use side API 84 and the service providing side API 87) and the management daemon 83. However, the present invention is limited to this embodiment. Instead, it may be configured by an independent program having the same functions as those of the service use side API 84, the service providing side API 87, and the management daemon 83.

As described above, this load distribution processing system 10 is a method in which processing requests and processing results are directly exchanged between the service using process 81 and the service provider process 82. Since it is not a mechanism relayed by the distributed processing apparatus, there is no transmission delay.
In addition, the processing request queue information indicating the current load status of each service providing side process 82 is updated every time the processing result is returned from the service providing side process 82 or the client queue information is transmitted from the management daemon 83. Therefore, it is possible to distribute processing requests reflecting the actual load of each service providing process 82.

Thus, in the case of this load distribution processing system 10, the distributed processing that reflects the actual load of the service providing side process 82 is possible, and the processing request and the processing result are transmitted at high speed. Since it is provided, it is suitable for a stock automatic execution system that requires a large amount of order information to be obtained instantly.
Hereinafter, after describing the securities transaction automatic execution system based on FIGS. 11 to 29, an example in which the present invention is applied to the securities transaction automatic execution system will be described based on FIGS. 30 and 31.

FIG. 11 is a block diagram showing the overall configuration of the securities transaction automatic execution system 10, which includes a setting registration unit 12, an algorithm DB 14, an execution control unit 16, an order division unit 18, a plurality of ordering units 20, and a volume. A curve selection unit 21 and a volume curve change unit 22 are provided.
The setting registration unit 12, the execution control unit 16, the order division unit 18, each ordering unit 20, the volume curve selection unit 21, and the volume curve change unit 22 execute necessary processes according to the OS and a dedicated application program by the computer CPU. Is realized. The algorithm DB 14 is provided in the hard disk of the computer.

A client terminal 23 operated by a trader is connected to the setting registration unit 12 and the execution control unit 16 via a communication network.
The execution control unit 16 is connected to a stock exchange computer 24 via a communication network. From the computer 24 of the stock exchange to the execution control unit 16, market data (current value data, quote data, volume data, etc. for each stock code) and contract data (order ID, contract amount, contract price, contract date) Etc.) are transmitted intermittently.

In using this system 10, the trader needs to set a plurality of algorithms for automatic execution in advance and register them in the algorithm DB.
For this purpose, the trader starts a dedicated application program on the client terminal 23, accesses the setting registration unit 12, and displays the algorithm setting screen on the display.
FIG. 12 shows an example of the algorithm setting screen 30 displayed on the display of the client terminal 23. The left pane 31 has an algorithm 32, a volume curve selection part 33, a volume curve change part 34, an order division part 35, Each setting item of the order part 36 is arranged in a tree shape.

  Here, the trader right-clicks with the branch of the algorithm 32 selected, selects “add algorithm” from the expanded right-click menu, and inputs the algorithm name. As a result, a new algorithm name is added under the algorithm 32. Here, “VWAP strategy” is newly added.

  Next, with the added “VWAP Strategy” selected, the trader selects the volume curve selection part specification field 38, volume curve change part specification field 39, and order split part specification field 40 displayed in the right pane 37. Select and input a typical volume curve selection part name, volume curve change part name, and order split part name. Further, the trader selects and inputs an order part to be associated with the displayed order part mnemonic (here, “$ LimitOrder” is displayed) in the order part designation field 41.

  Here, the “volume curve” means a curve showing a correspondence relationship between the transition of the execution rate with respect to the total number of orders and the passage of time, and is synonymous with ordering schedule definition data that regulates the pace of execution. FIG. 13 shows an example of a volume curve, and for each brand, a curve is drawn in which the correspondence between the trading time of a day on the stock exchange and the trading volume is averaged over a plurality of days. This is adopted, for example, in an algorithm called VWAP, which targets the contract price with the volume-weighted average of the subject stock on the exchange. In addition to this, for example, an algorithm called ArrivalPrice uses a curve that theoretically minimizes the market impact according to the statistical value of the past stocks as a volume curve.

“Volume curve selection component” means a program component that performs a function of determining a volume curve to be applied by determining a preset condition when the algorithm is activated. By instantiating the volume curve selection component, the volume curve selection unit 21 is generated.
In the figure, a volume curve selection part named “sample VWAP1” is designated.
Note that specific volume curve data is stored in the algorithm DB 14.

“Volume curve changing component” means a program component that performs a function of determining a change condition at a preset timing and executing a necessary change to the volume curve during execution of the algorithm. The volume curve changing unit 22 is generated by instantiating the volume curve changing part.
In the figure, a volume curve changing part named “5 minutes ahead of sample” is designated.

“Order division parts” is a method of dividing a given total number of orders into a plurality of individual orders according to a predetermined rule, instantiating an order part responsible for the order processing for each individual order, and assigning the calculated individual order quantity. It means program parts that perform their functions. By instantiating the order division part, the order division unit 18 is generated.
In the figure, the order division part “5 minutes slice” is selected.

"Order parts" means that the individual order information of the quantity allocated by the order splitting unit 18 is transmitted to the stock exchange computer 24 via the execution control unit 16, and the price is manipulated according to a predetermined logic, It means a program component that demonstrates the function of pursuing the execution of a contract at an advantageous price as much as possible. The ordering unit 20 is generated by instantiating the ordering part.
In the figure, the ordering part “concession after 5 minutes” is associated with the mnemonic (abbreviation) of the ordering part “$ LimitOrder”. Although details will be described later, the mnemonic of the ordered part is the name assigned by the trader when setting the ordered divided part selected in the ordered divided part designation column 40.

  FIG. 14 summarizes the setting items of the algorithm. For the traders who have completed the specification of these volume curve selection parts, the specification of volume curve change parts, the specification of order split parts, and the association of the order part mnemonics with the order parts, select (File (F) → Save (S) ”In order to request registration of settings. Upon receipt of this, the setting registration unit 12 “Volume curve selection part: sample VWAP1, volume curve change part: sample 5 minutes ahead, order split part: slice 5 minutes, order part mnemonic ($ LimitOrder) =: 5 minutes later The combination information of “concess” is stored in the algorithm DB 14 in association with the algorithm name “VWAP strategy”.

  In the algorithm setting screen 30 of FIG. 12, in addition to “VWAP strategy”, algorithm names such as “participation”, “opportunity”, and “PEG best quotation” are listed. In principle, the selected part is specified, the volume curve changing part is specified, the order split part is specified, and the mnemonic of the ordered part is associated with the ordered part. However, depending on the algorithm, the order division unit 18 does not need to refer to the volume curve when calculating the individual order quantity. In this case, the specification of the volume curve selection part and the specification of the volume curve change part are omitted. The When there is no need to change the volume curve selected first, only the volume curve selection part is specified, and the specification of the volume curve change part is omitted.

  In order to set a unique algorithm, the trader sets in advance his own volume curve selection part, volume curve change part, order division part and order part.

  First, the setting of the volume curve selection part will be described. As shown in FIG. 15, the right click menu is expanded by right-clicking with the branch of the volume curve selection part 33 selected in the left pane 31 of the algorithm setting screen 30. Select “Add Volume Curve Selection Part” from the list and type in the volume curve selection part name. As a result, a new volume curve selection part name is added under the volume curve selection part 33. Here, it is assumed that “sample VWAP1” is newly added.

  With respect to the volume curve selection part, a plurality of operation modes can be set in order to switch the volume curve according to the situation at the time of starting the algorithm. Specifically, right-click the “Sample VWAP1” branch in the left pane 31 of the algorithm setting screen 30 and select “Add Operation Mode” from the expanded right-click menu. Type in a name. As a result, a new operation mode is added under “sample VWAP1”. In the figure, two operation modes of “normal day” and “SQ day” are provided. Here, “SQ date” means the settlement date for futures and options.

Next, the trader selects and inputs a specific volume curve to the volume curve selection input field 42 displayed in the right pane 37 with the added operation mode selected. In addition, a specific set value is input to the application condition input field 43.
In the figure, the operation mode of “SQ day” is selected, “VWAP” is set as the volume curve, and “SQ day” is set as the application condition. This means that it is ruled that “VWAP” should be referred to as a volume curve when the algorithm activation time falls on the SQ day.

  FIG. 16 summarizes the setting items related to the volume curve selection component. The trader who has completed the generation of these operation modes, the specification of the volume curve in each operation mode, and the specification of the application conditions, click `` File (F) → Save (S) '' in the menu bar in order to register the settings. Ask. In response to this, the setting registration unit 12 adds a code corresponding to the setting item selected and input by the trader to the program code of the template describing the common functions of the volume curve selection component, and then creates a unique volume curve selection component. Is automatically generated and stored in the algorithm DB 14 in association with the program part name of “sample VWAP1”.

  Next, the trader moves to the setting of the volume curve changing part. That is, as shown in FIG. 17, right click with the branch of the volume curve changing component 34 selected in the left pane 31 of the algorithm setting screen 30, and select “Add Volume Curve Changing Component” from the expanded right click menu. ”And type in the volume curve change part name. As a result, a new volume curve change part name is added under the volume curve change part 34. Here, “sample 5 minutes ahead” is newly added.

  With respect to the volume curve changing component, a plurality of operation modes can be set in order to enable flexible adjustment of the volume curve in accordance with a change in the situation during execution of the algorithm. Specifically, in the left pane 31 of the algorithm setting screen 30, right-click with the “sample 5 minutes ahead” branch selected, and select “Add Operation Mode” from the expanded right-click menu. Type in the operating mode name. As a result, a new operation mode is added under “sample 5 minutes ahead”. In the figure, only the “On Order” operation mode is provided, but multiple operation modes can be generated.

Next, the trader inputs specific setting values to the timing selection input field 44, the change condition input field 45, and the action input field 46 displayed in the right pane 37 while the added operation mode is selected.
In the figure, “new case” is selected and input as the timing. Also, “Volume curve adjustment (min, 5.0)” is entered as an action. This means that it is a rule to advance the current volume curve for 5 minutes when a new item is ordered from a trader.
Here, since the change condition input field 45 is blank, the volume curve is always advanced for 5 minutes when it matches the timing of a new case. However, a conditional expression is input in the change condition input field 45 in advance. Therefore, finer control can be performed. For example, it is applicable to describe in a predetermined grammar that “the order quantity of a new case exceeds 3% of the total number of orders” as a conditional expression.

  FIG. 18 summarizes the setting items related to the volume curve changing component. For the traders who have created these operation modes, specified the timing in each operation mode, set the change conditions, and set the actions, click `` File (F) → Save (S) '' in the menu bar in order. Ask for registration. In response to this, the setting registration unit 12 adds a code corresponding to the setting item selected and input by the trader to the program code of the template describing the common functions of the volume curve changing parts. Is automatically generated and stored in the algorithm DB 14 in association with the program part name “5 minutes ahead of sample”.

  Next, the trader moves to the setting of order division parts. That is, as shown in FIG. 19, right click with the branch of the order split part 35 selected in the left pane 31 of the algorithm setting screen 30, and select “Add Order Split Part” from the expanded right click menu. Select and type in the order split part name. As a result, a new order split part name is added under the order split part 35. Here, it is assumed that “5-minute slice” is newly added.

  One or more operation modes are set in advance for the order divided parts. Specifically, in the left pane 31 of the algorithm setting screen 30, right-click with the “5-minute slice” branch selected, and select “Add Operation Mode” from the expanded right-click menu. Type in the mode name. As a result, a new operation mode is added under “5-minute slice”. In the figure, only the “slice” operation mode is provided.

  Next, the trader selects specific operation values for the timing selection input field 48, the condition input field 49, and the content input field 50 displayed in the right pane 37 while the operation mode of the added “slice” is selected. Select and input.

  Here, the timing selection input field 48 is an item that defines the time condition when the ordering part 20 is instantiated to generate the ordering unit 20 and whether or not to issue a new order is determined. It is specified that the determination should be made at “minute interval”.

  In addition, the condition input field 49 is an item that defines a determination rule (standard) for whether or not to place a new order by instantiating a part to be ordered. In the figure, referring to the volume curve ratio, A conditional expression that specifies that a new order should be issued if it is behind schedule is described in a unique grammar.

  The content input column 50 includes a mnemonic input column 50 (a) for ordering parts, an assigned quantity input column 50 (b), and a rounding method selection column 50 (c). The trader inputs an arbitrary mnemonic of the ordered part to be responsible for the ordering process in the mnemonic input field 50 (a) of the ordered part. Next, the trader inputs a quantity calculation rule in the assigned quantity input field 50 (b). Specifically, click the “Formula setting” button to open the input window. For example, refer to “Volume curve to calculate the current planned quantity and subtract the constant amount from the planned quantity to the current time. Write a calculation formula that prescribes “to be assigned quantity” in its own grammar. Finally, the trader selects and inputs a rounding method (rounding off, rounding down, etc.) in the rounding method selection field 50 (c) when a fraction occurs in the allocated quantity.

  FIG. 20 summarizes the setting items related to the order split parts. For the traders who have completed the generation of these operation modes, specification of timing in each operation mode, setting of conditions, setting of contents (input of mnemonic for ordering parts, input of calculation formula of assigned quantity, selection of rounding method) Click “File (F) → Save (S)” in order to register settings. In response to this, the setting registration unit 12 automatically adds a code corresponding to the setting item selected and input by the trader to the program code of the template describing the common functions of the order split parts, and automatically assigns the specific order split parts. It is generated and stored in the algorithm DB 14 in association with the program part name of “5-minute slice”.

  Next, the trader moves to the definition of the ordered part. That is, as shown in FIG. 21, right-clicking is performed with the branch of the ordering part 36 selected in the left pane 31 of the algorithm setting screen 30, and “Add ordering part” is selected from the expanded right-click menu. , Type in the order part name. As a result, a new order part name is added under the order part 36. Here, “concession after 5 minutes” is newly added.

With respect to the ordered parts, one or a plurality of operation modes can be set in order to more flexibly implement the price strategy of the trader. Specifically, in the left pane 31 of the algorithm setting screen 30, right-click with the branch of “Concession after 5 minutes” selected, select “Add operation mode” from the expanded right-click menu, Type in the operating mode name. As a result, a new operation mode is added under “Concession after 5 minutes”. In the figure, three operation modes of “new order”, “PEG operation”, and “concession after 5 minutes” are provided.
The number of operation modes is not limited, but at least an operation mode corresponding to “new order” needs to be provided.

Next, with the selected operation mode selected, the trader selects and inputs specific set values to the timing selection input field 52, the condition input field 53, and the action input field 54 displayed in the right pane 37.
In the figure, “PEG operation” is selected, and “market price information” is selected and input as the timing. This “timing” means a time condition for the operation mode to be activated, and the value of “market price information” means “when the market price changes”.

In addition, the condition input field 53 is an item that prescribes a rule for determining whether or not to change the price. In the figure, “If the current best price is compared with your limit and there is a difference between the two, The conditional expression that “a correction order should be issued” is described in a unique grammar.
The action input field 54 is an item that defines the type of order (new order / correction order) and the rules for calculating the price. In the figure, “Your own order price is the best quote price in the market (however, execution restrictions) "Correction within price)" is set.

The trader sets the above “timing”, “condition”, and “action” for each operation mode of “new order”, “PEG operation”, and “concession after 5 minutes”.
FIG. 22 schematically shows the setting contents related to the ordered part of “5 minutes concession”. For “new order”, “immediately after generation” is used as the timing, and “new order / best quotation price” is used as the action. "Is set. In the case of a new order, since it is sufficient to simply send new order information to the computer of the exchange, the condition is blank.

  For “concession after 5 minutes”, “when 5 minutes have passed after generation” is set as the timing, and “price correction / reverse best quotation price” is set as the action. Even in the case of “concession after 5 minutes”, the order is determined only by the time condition (timing), and it is not necessary to determine whether or not it is necessary, so the condition is blank.

  FIG. 23 summarizes the setting items related to the ordered parts. For the traders who have created these operation modes, specified the timings in each operation mode, set the conditions, and set the actions, click `` File (F) → Save (S) '' in the menu bar in order to set the settings. Ask for registration. In response to this, the setting registration unit 12 automatically generates a unique ordering part by adding a code corresponding to the setting item selected and input by the trader to the program code of the template describing the common functions of the ordering part. , Stored in the algorithm DB 14 in association with the program part name “concession after 5 minutes”.

  FIG. 24 shows a configuration of an algorithm in the system 10. Each algorithm includes a volume curve selection part, a volume curve change part, and an order division part. The order division part includes a plurality of order division parts according to the operation mode. With ordering parts. However, when the rule for calculating the individual order quantity without referring to the volume curve is specified for the order split parts, it is not necessary to specify the volume curve selection part and the volume curve change part. Further, when the order division part has only a single operation mode, there is one ordering part. Therefore, the minimum configuration of the algorithm is a combination of one order division part and one order part.

  As described above with reference to FIG. 12, the trader selects and inputs the volume curve selection part, the volume curve change part, and the order division part on the algorithm configuration setting screen, and also the mnemonic of the order part and the order part name. Make an association.

Next, a method for using the automatic execution system 10 will be described.
First, the trader accesses the execution control unit 16 from the client terminal 23, displays the automatic execution request screen 60 on the display as shown in FIG. 25, and then sets details of automatic execution.
In other words, the type of “buy / sell” is selected and entered in the trade type selection field 61, the stock code is entered in the stock code entry field 62, and an arbitrary stock exchange is selected and entered in the market selection field 63, and the quantity is entered. The total number of orders is entered in the column 64, and if there is an upper limit or lower limit in the contract price, a specific price is entered in the execution limit price input column 65. Next, when the ▼ button is clicked in the algorithm selection field 66, a pull-down menu listing the algorithm names set by the trader is displayed, and the algorithm name desired to be used is selected.

Here, if a rule that requires parameter replenishment is included in the configuration of the algorithm selected by the user, the item name and type are displayed in the parameter input field 67. Enter typical parameters.
For example, when the order split part is set, when the calculation rule of “the quantity corresponding to X% of the market volume is set as the order quantity” is set in the allocated quantity input field 50b, the item name “ “Participation rate” is displayed as “Decimal” in the type. On the other hand, the trader inputs a specific numerical value such as “0.3” as a value.

  The user who has completed the above settings clicks the execute button 68 and instructs the execution control unit 16 of the automatic execution system 10 to execute automatic execution.

  Next, the operation of the execution control unit 16 will be described with reference to the flowchart of FIG. First, the execution control unit 16 that has received an automatic execution request with designation of a trade type, a brand code, a market, a quantity, an algorithm, etc. from the client terminal 23 (S10) refers to the algorithm DB 14 and designates the designated algorithm (VWAP strategy). The volume curve selection part, the volume curve change part, the order division part, and the order part according to () are specified (S12).

Next, the execution control unit 16 instantiates the corresponding volume curve selection part, volume curve change part, and order division part, and generates the volume curve selection part 21, volume curve change part 22, and order division part 18 (S14).
Next, the execution control unit 16 passes the brand code, trade type, quantity, and order part name to the order splitting unit 18 (S16).

The volume curve selection unit 21 compares the current time with the calendar information and SQ day information stored in a predetermined area, determines whether the current day is an SQ day or a normal day, and a volume curve to be applied based on the result. The name is specified, and the volume curve name is passed to the execution control unit 16.
The execution control unit 16 refers to the corresponding volume curve data stored in the algorithm DB 14 whenever there is an inquiry from the order splitting unit 18 about the current volume curve ratio (scheduled execution rate). Is calculated and returned to the order splitting unit 18.

  Thereafter, the execution control unit 16 provides the order division unit 18, the ordering unit 20, and the volume curve changing unit 22 with market data and contract data transmitted from the computer 24 of the exchange as well as order information by the trader as needed.

The volume curve changing unit 22 constantly monitors the market data provided from the execution control unit 16 and the order information by the trader, and when a predetermined change condition is met, a necessary change command for a preset volume curve ( For example, the volume control curve should be advanced by 5 minutes).
Thereafter, when there is an inquiry about the volume curve ratio from the order splitting section 18, the execution control section 16 orders the volume curve ratio with the above change (for example, the volume curve ratio after 5 minutes from the current time). Provided to the division unit 18.

  Next, the operation of the order division unit 18 will be described with reference to the flowchart of FIG. Here, it is assumed that the order division unit 18 is generated based on the order division part of “5-minute slice”. First, the order dividing unit 18 instantiates the ordering part designated by the execution control unit 16, that is, “concession after 5 minutes” at the same time when the transaction start time arrives, and generates the first ordering unit 20 (S20).

At this time, the order division unit 18 inquires the execution control unit 16 about the current volume curve ratio, and by multiplying the volume curve ratio passed from the execution control unit 16 by the total number of orders, the order passed to the first ordering unit 20 The quantity is calculated (S22).
Next, the order division unit 18 passes the brand code, the trade type, and the current order quantity to the ordering unit 20 (S24). Thereafter, corresponding order information is transmitted from the ordering unit 20 to the computer 24 of the stock exchange via the execution control unit 16, which will be described in detail later.

After 5 minutes have passed since the creation of the first ordering unit 20 (S26), the order splitting unit 18 inquires the execution control unit 16 again about the current volume curve ratio, and the volume curve ratio passed from the execution control unit 16 Is multiplied by the total number of orders to calculate the planned execution quantity (S28).
Next, the order division unit 18 compares the execution completion quantity (cumulative value of the approximate constant quantity) up to the present time with the above-mentioned planned execution quantity, and if the execution completion quantity is below the planned execution quantity (S30) Then, the ordering part of “concession after 5 minutes” is instantiated to generate the next ordering unit 20 (S32).
Then, the order quantity corresponding to the difference between the brand code, the trade type and the planned execution quantity and the execution completion quantity is passed to the ordering section 20 (S34).

On the other hand, if it is determined in S30 that the execution completion quantity is greater than or equal to the scheduled execution quantity, the order division unit 18 defers generation of a new ordering unit 20 this time and waits until the next timing comes.
In this automatic execution system 10, even after directing the execution control of stock trading to the execution control unit 16, the trader shall send individual order information to the execution control unit 16 based on its own judgment within the range of the total number of orders. The order information is transmitted from the execution control unit 16 to the computer 24 of the exchange. In addition, when a contract is established for an individual order based on the judgment of the trader, execution report data is transmitted from the computer 24 of the exchange to the execution control unit 16. For this reason, a situation may occur where the execution completion quantity exceeds the scheduled execution quantity.

  The order dividing unit 18 repeats the processes of S28 to S34 every 5 minutes until the set transaction end time arrives (S26, S36), and continues to generate a plurality of ordering units 20. However, if the cumulative number of orders reaches the total number of orders before the transaction end time arrives, the processing is stopped at that point.

Next, the operation of the ordering unit 20 will be described with reference to the flowchart of FIG. Here, it is assumed that the ordering unit 20 is generated based on the ordering part of “concession after 5 minutes”.
First, the ordering unit 20 immediately after generation generates order information having the following contents according to the setting of the “new ordering” mode, and transmits the order information to the computer 24 of the exchange designated by the trader via the execution control unit 16 ( S40).
Stock Code: 4307
Type of Sale: Buy Quantity: All Allocated Quantity Price: Current Best Price (Limit)
The current best price is calculated based on the market data transmitted from the execution control unit 16.

After newly issuing the order information, the ordering unit 20 shifts to the “PEG operation” mode. That is, the ordering unit 20 constantly monitors the market data transmitted from the execution control unit 16, and when the market price fluctuates (S44), it determines the divergence between the current best price and its limit (S46). ). Here, if there is a divergence between the best quote price and its own limit price, the ordering unit 20 generates corrected order information for correcting the limit price to the current best quote price, and the transaction is made via the execution control unit 16. The data is transmitted to the computer 24 (S48).
The ordering unit 20 continues the process for following the best quotation price until a contract is established for the total quantity of its own order (S42), or until 5 minutes have passed since the new order information was transmitted. .

When 5 minutes have passed without fulfilling the contract (S50), the ordering unit 20 shifts to the “concession after 5 minutes” mode, and generates and executes price correction order information for changing the order price to “reverse best price”. The data is transmitted to the exchange computer 24 via the control unit 16 (S52).
“Reverse best quote price” means the best quote price on the selling side when placing a buy order, and the best quote price on the buying side if placing a sell order. By changing, it becomes possible to establish a contract with high accuracy. This reverse best price is calculated based on the market data transmitted from the execution control unit 16.

  In the case of the ordering part 20 generated based on the ordered part of “concession after 5 minutes”, as described above, a relatively bullish order can be placed by following the best quotation price in the market until 5 minutes after the ordering. Although maintained, after 5 minutes, by concession to the reverse best quotation price, the function that aims for more reliable execution of the contract will be demonstrated.

As described above, in the securities transaction automatic execution system 10, the automatic transaction processing of the securities transaction includes an order dividing unit 18 that divides the total number of orders into a plurality of individual order quantities, and an amount for each divided order quantity. This is achieved through cooperation with multiple ordering units 20 that transmit order information to the stock exchange computer 24. The order splitting unit and each ordering unit use order division parts and ordering parts that have been set in advance by the trader. It has a mechanism realized by instantiation.
For this reason, the trader can set an algorithm for performing a complicated operation very easily by appropriately combining the order division parts and the order parts that are defined in advance. Also, when changing the operation pattern of the algorithm, it can be easily realized by changing the combination of the order split parts and the order parts.

  For third parties, the algorithm consists of a combination of order split parts and order parts, so the operation of the entire algorithm can be understood by stepping through the settings of the order split parts and order parts. It becomes easy, and it becomes possible to improve the reusability and maintainability.

  The algorithm setting described above is an example, and the trader registers a large number of order division parts, order parts, volume curve selection parts, and volume curve change parts with different setting patterns in the algorithm DB 14 in advance, and these can be freely set. By registering a large number of algorithms for automatic execution combined with the above in the algorithm DB 14 in advance, it becomes possible to immediately use an algorithm optimal for the characteristics of the brand and the market situation.

  In the above, an example in which all the setting information is stored in the algorithm DB 14 is shown, but each setting information may be stored in a plurality of storage units, and necessary data items may be associated with each other.

As described above, a plurality of ordering units 20 are generated as the transaction time progresses, and a large amount of data such as order information and execution information is exchanged at high speed with the stock exchange computer 24 via the execution control unit 16. The Rukoto.
FIG. 29 is a conceptual diagram showing the internal structure of the execution control unit 16, and includes a plurality of reception units 74 and a plurality of GW (gateway) units 76.

Each receiving unit 74 is an independent process, and receives from the GW unit 76 the function of receiving the order information transmitted from the ordering unit 20 and passing it to the GW unit 76, and the order receiving information returned from the computer 24 of the stock exchange. And a function of passing to the ordering unit 20.
Each GW unit 76 is also an independent process. The order information received from the receiving unit 74 is converted in format and sent to the stock exchange computer 24. The order confirmation information returned from the computer 24 For example, the format is converted and passed to the reception unit 74.

  As described above, a large number of receiving units 74 and GW units 76 are activated in the execution control unit 16, and various data are exchanged at high speed between processes and with a plurality of ordering units 20. The efficiency can be improved by applying the load distribution processing system 80 according to the present invention to each section.

FIG. 30 is a schematic diagram showing an example in which the load distribution processing system 80 is applied between the ordering unit 20 and the receiving unit 74. Each ordering unit 20 (ordering process = service use side process) has a service use side API 84. Each receiving unit 74 (receiving process = service providing side process) is provided with a service providing side API 87.
The service using side API 84 and the service providing side API 87 are functions provided by middleware. In addition, a management daemon 83 that is a resident program of the middleware is activated.

  Although not shown in the figure, the service use side API 84 includes a distribution wait request storage area 85 and a processing request queue information storage area 86 similar to those described above. Although not shown, the service providing side API 87 includes a service providing side queue information storage area 88, and the management daemon 83 includes a management daemon queue information storage area 89.

Then, the order information (processing request) generated by the ordering unit 20 is passed to the service use side API 84.
Receiving this, the service use side API 84 refers to the processing request queue information, identifies the reception unit 74 with the smallest load (number of own requests + number of other requests), and determines the “number of own requests + If the value of “number of other requests” is equal to or less than a predetermined threshold, after adding “1” to “number of requests” of the record of the receiving unit 74, an order is made to the service providing side API 87 of the receiving unit 74 Send information.
When “the number of own requests + the number of other requests” of the receiving unit 74 having the smallest load exceeds the threshold value, the order information is temporarily stored in the allocation waiting request storage area 85, and “the number of own requests + the number of other requests”. Is transmitted to the service providing side API 87 of the receiving unit 74 at the time when becomes below the threshold.

Upon receiving this order information, the service providing side API 87 searches the service providing side queue information storage area 88 and extracts the record of the ordering unit 20. Next, the service providing side API 87 adds “1” to the processing request reception number of records of the extracted ordering unit 20, associates the order information with the record, and passes the order information to the receiving unit 74.
This order information is transferred from the receiving unit 74 to the GW unit 76 and transmitted to the computer 24 of the stock exchange via the GW unit 76.

When order confirmation information indicating that an order has been received is transmitted from the computer 24 of the stock exchange, the order confirmation information reaches the reception unit 74 via the GW unit 76, and the reception unit 74 receives the order confirmation information ( Process result) to the service providing side API 87.
Upon receiving this, the service providing side API 87 adds “1” to the number of processing request replies for the record of the ordering unit 20, generates summary information of the service providing side queue information, and together with the order confirmation information, the service using side API 84. Send to.

Receiving this, the service use side API 84 searches the processing request queue information storage area 86 using the “IP address + process ID” of the reception unit 74 as a key, extracts the record of the reception unit 74, and requests its own request. After subtracting “1” from the number of cases, the order confirmation information is passed to the ordering unit 20.
Next, the service using side API 84 updates the “number of other requests” in the record of the receiving unit 74 based on the summary information transmitted from the service providing side API 87.

  When the preset timing arrives, the service providing side API 87 transmits the service providing side queue information related to each ordering unit 20 to the management daemon 83.

Receiving this, the management daemon 83 searches the management daemon queue information storage area 89 and extracts the record of each ordering unit 20 related to the receiving unit 74.
Next, the management daemon 83 overwrites and updates the processing request reception number and the processing request reply number of the management daemon queue information with the service providing side queue information transmitted from the reception unit 74.

Also, when the preset timing arrives, the management daemon 83 generates client queue information (ID of the receiving unit 74 + the number of other requests) for each ordering unit 20 based on the management daemon queue information, To send.
Receiving this, the service use side API 84 of each ordering unit 20 overwrites and updates the number of other requests related to each receiving unit 74 in the processing request queue information.

  As a result, each ordering unit 20 can transmit order information to the receiving unit 74 with the smallest load at the present time.

FIG. 31 is a schematic diagram showing an example in which the load distribution processing system 80 is applied between the reception unit 74 and the GW unit 76. Each reception unit 74 (reception process = service use side process) has a service use side API 84. Each GW unit 76 (gateway process = service providing side process) is provided with a service providing side API 87. That is, the accepting unit 74 that functions as a service providing process in the above functions as a service using process in this situation.
The service using side API 84 and the service providing side API 87 are functions provided by middleware. In addition, a management daemon 83 that is a resident program of the middleware is activated.

  Although not shown in the figure, the service use side API 84 includes a distribution wait request storage area 85 and a processing request queue information storage area 86 similar to those described above. Although not shown, the service providing side API 87 includes a service providing side queue information storage area 88, and the management daemon 83 includes a management daemon queue information storage area 89.

Then, the order information (processing request) received by the receiving unit 74 from the ordering unit 20 is passed to the service use side API 84.
Receiving this, the service user side API 84 refers to the processing request queue information, identifies the GW unit 76 with the smallest load (number of self-requests + number of other requests), and determines the “number of self-requests + If the value of “number of other requests” is equal to or less than a predetermined threshold, “1” is added to “number of requests” of the record of the GW unit 76, and then an order is made to the service providing side API 87 of the GW unit 76 Send information.
If “the number of own requests + the number of other requests” of the GW unit 76 having the smallest load exceeds the threshold, the order information is temporarily stored in the allocation waiting request storage area 85, and “the number of own requests + the number of other requests”. Is transmitted to the service providing side API 87 of the GW unit 76 at the time when becomes below the threshold.

Receiving this order information, the service providing side API 87 searches the service providing side queue information storage area 88 and extracts the record of the receiving unit 74. Next, the service providing side API 87 adds “1” to the number of processing request receptions of the record of the extracted receiving unit 74, associates the order information with the record, and passes the order information to the GW unit 76.
The GW unit 76 converts this order information into a predetermined format and transmits it to the stock exchange computer 24.

When order confirmation information indicating that an order has been received is transmitted from the computer 24 of the stock exchange, the GW unit 76 converts it into a predetermined format and then passes it to the service providing side API 87.
Upon receiving this order confirmation information (processing result), the service providing side API 87 adds “1” to the number of processing request replies in the record of the receiving unit 74, generates summary information of the service providing side queue information, and confirms the order. The information is transmitted to the service use side API 84 together with the information.

Receiving this, the service-use API 84 searches the processing request queue information storage area 86 using “IP address + process ID” of the GW unit 76 as a key, extracts the record of the GW unit 76, and extracts “ After subtracting “1” from the “number of self-requests”, the order confirmation information is passed to the reception unit 74.
Next, the service using side API 84 updates the “number of other requests” in the record of the GW unit 76 based on the summary information transmitted from the service providing side API 87.

  When the preset timing arrives, the service providing side API 87 transmits all the records of the service providing side queue information related to each receiving unit 74 to the management daemon 83.

Receiving this, the management daemon 83 searches the management daemon queue information storage area 89 and extracts the records of the receiving units 74 related to the GW unit 76.
Next, the management daemon 83 overwrites and updates the processing request reception number and the processing request reply number of the management daemon queue information with the service providing side queue information transmitted from the GW unit 76.

Also, when the preset timing arrives, the management daemon 83 generates client queue information (ID of the GW unit 76 + the number of other requests) for each reception unit 74 based on the management daemon queue information. To send.
Receiving this, the service utilization side API 84 of each receiving unit 74 overwrites and updates the number of other requests related to each GW unit 76 in the processing request queue information.

  As a result, each reception unit 74 can transmit order information to the GW unit 76 having the smallest load at the present time.

  As described above, the load distribution processing system 80 is applied between each ordering unit 20 and each reception unit 74, and the load distribution processing system 80 is also multistaged between each reception unit 74 and each GW unit 76. As a result, the exchange of order information and order confirmation information between the ordering unit 20 and the GW unit 76 is improved.

1 is a block diagram showing an overall configuration of a load distribution processing system according to the present invention. It is a flowchart which shows operation | movement of a load distribution processing system. It is a flowchart which shows operation | movement of a load distribution processing system. It is explanatory drawing which shows the structure of process request queue information. It is explanatory drawing which shows the structure of service provision side queue information. It is explanatory drawing which shows the structure of summary information. It is explanatory drawing which shows the structure of management daemon queue information. It is explanatory drawing which shows the structure of client queue information. It is explanatory drawing which shows the production | generation process of client queue information. It is a flowchart which shows the process sequence regarding a distribution waiting request. It is a block diagram which shows the whole structure of the securities transaction automatic execution system which is an application example of this invention. It is explanatory drawing which shows the scene which sets the whole structure of an algorithm in an algorithm setting screen. It is explanatory drawing which shows the specific example of a volume curve. It is a figure which shows the setting item of an algorithm. It is explanatory drawing which shows the scene which sets a volume curve selection component in an algorithm setting screen. It is a figure which shows the setting item of volume curve selection components. It is explanatory drawing which shows the scene which sets a volume curve change component in an algorithm setting screen. It is a figure which shows the setting item of a volume curve change component. It is explanatory drawing which shows the scene which sets an order division | segmentation part in an algorithm setting screen. It is a figure which shows the setting item of order division | segmentation parts. It is explanatory drawing which shows the scene which sets ordering parts in an algorithm setting screen. It is explanatory drawing which shows the example of a setting of order parts. It is a figure which shows the setting item of order parts. It is a figure which shows the structural example of an algorithm. It is explanatory drawing which shows an automatic execution request screen. It is a flowchart which shows operation | movement of an execution control part. It is a flowchart which shows operation | movement of an order division | segmentation part. It is a flowchart which shows operation | movement of an ordering part. It is a block diagram which shows the internal structure of an execution control part. It is a block diagram which shows the example which applied the load distribution processing system between the ordering part and the reception part. It is a block diagram which shows the example which applied the load distribution processing system between the reception part and GW part.

10 Securities transaction execution system
12 Setting registration section
16 Executive Control Department
18 Order division
20 Order Department
21 Volume curve selector
22 Volume curve change section
23 Client terminal
24 Stock trading computer
30 Algorithm setting screen
31 Left pane
32 algorithm
33 Volume curve selection parts
34 Volume curve change parts
35 Order split parts
36 Parts ordered
37 Right pane
38 Volume curve selection part specification field
39 Volume curve change part specification field
40 Order split parts designation field
41 Ordered part specification field
42 Volume curve selection input field
43 Application condition input field
44 Timing selection input field
45 Change condition input field
46 Action input field
48 Timing selection input field
49 Condition input field
50 Content input field
50a Mnemonic input field
50b Allocation quantity input field
50c Rounding method selection field
52 Timing selection input field
53 Condition input field
54 Action input field
60 Automatic execution request screen
61 Transaction type selection field
62 Stock code input field
63 Market selection field
64 Quantity input field
65 Execution limit price input field
67 Parameter input field
67a Value input field
68 Submit button
72 Algorithm selection field
74 Reception
76 GW Department
80 Load balancing system
81 Service consumer process
82 Service provider process
83 Management Daemon
84 Service-use API
85 Waiting request storage area
86 Processing request queue information storage area
87 Service Provider API
88 Service provider queue information storage area
89 Management daemon queue information storage area

Claims (7)

A plurality of service using processes that generate processing requests, a plurality of service providing processes that execute processing necessary for the processing requests and outputting processing results, and a process provided for each service using process A load distribution processing system comprising a request distribution unit, a load information management unit provided for each service providing side process, and a load information distribution unit,
The processing request distribution unit stores, for each service providing process, a first storage area for storing the number of incomplete processing requests related to all service using processes handled by the service providing process;
A function for identifying the service providing side process having the smallest number of unfinished processing requests with reference to the first storage area when a processing request is passed from the service using side process in charge of itself;
A function of transmitting a processing request to the load information management unit related to the service providing side process;
A function of receiving a processing result by the service providing side process from the load information management unit and passing it to the service using side process;
When the number of incomplete processing requests related to all service using processes for each service providing process is transmitted from the load information distribution unit, each service providing process stored in the first storage area thereby A function to update the number of incomplete processing requests,
The load information management unit receives a processing request of a service using side process from a corresponding processing request distributing unit, and passes it to a service providing side process in charge of itself,
A function of returning the processing result passed from the service providing side process to the processing request distributing unit of the service using side process;
A second storage area for storing the number of received processing requests and the number of processing result replies for each service using process;
A function of adding 1 to the number of received processing requests each time a processing request is received from the processing request distribution unit;
A function of adding 1 to the number of processing result replies each time a processing result is returned to the processing request distribution unit;
Provided with a function of transmitting the processing request reception number and processing result reply number related to each service using process to the load information distribution unit at a predetermined timing,
The load information distribution unit includes a third storage area for storing the number of processing request receptions and the number of processing result replies related to each service user side process transmitted from each load information management unit,
At a given timing, for each service providing side process, subtract the number of processing result replies from the number of processing request received for each service using side process to obtain the number of incomplete processing requests, and add this to all service using side processes Function to
A load distribution processing system comprising a function of transmitting the number of incomplete processing requests related to all service using side processes for each service providing side process to each processing request distribution unit. When the load information management unit returns the processing result to the processing request distribution unit of the service using side process, the load information management unit collects the processing request reception number related to each service using side process and the processing related to each service using side process. It has a function to calculate the total value of the number of result replies and send it to the processing request distribution part together with the processing result,
The processing request distribution unit subtracts the total value of the processing result response number from the total value of the processing request reception number to obtain the number of incomplete processing request numbers related to all the service using side processes of the service providing side process. Function and
2. The load distribution according to claim 1, further comprising a function of updating the number of incomplete processing requests related to the service providing side process in the first storage area based on the number of incomplete processing requests. Processing system. A plurality of service using processes that generate processing requests, a plurality of service providing processes that execute processing necessary for the processing requests and outputting processing results, and a process provided for each service using process A load distribution processing system comprising a request distribution unit, a load information management unit provided for each service providing side process, and a load information distribution unit,
For each service providing side process, the above processing request distribution unit determines the number of self requesting requests that are the number of incomplete processing requests that are being transmitted to the service providing side process, and other service using side processes A first storage area for storing the number of other requests that are the total number of incomplete processing requests being transmitted to the providing process;
Provide a service with the smallest number of unfinished processing requests, which is the sum of the number of self-requests and the number of other requests, by referring to the first storage area when a processing request is passed from the service user side process in charge The ability to identify the side process,
A function of transmitting a processing request to the load information management unit related to the service providing side process;
A function of adding 1 to the number of requests related to the service provider process;
When receiving the processing result from the load information management unit, a function of subtracting 1 from the number of self-requests related to the service providing side process;
A function for passing the processing result to the service consuming process;
The number of other requests stored in the first storage area when the total number of incomplete processing requests related to other service using processes for each service providing process is transmitted from the load information distribution unit With the ability to update
The load information management unit receives a processing request of a service using side process from a corresponding processing request distributing unit, and passes it to a service providing side process in charge of itself,
A function of returning the processing result passed from the service providing side process to the processing request distributing unit of the service using side process;
A second storage area for storing the number of received processing requests and the number of processing result replies for each service using process;
A function of adding 1 to the number of received processing requests each time a processing request is received from the processing request distribution unit;
A function of adding 1 to the number of processing result replies each time a processing result is returned to the processing request distribution unit;
Provided with a function of transmitting the processing request reception number and processing result reply number related to each service using process to the load information distribution unit at a predetermined timing,
The load information distribution unit includes a third storage area for storing the number of processing request receptions and the number of processing result replies related to each service user side process transmitted from each load information management unit,
At a given timing, for each service providing side process, subtract the number of processing result replies from the number of processing request received for each service using side process to obtain the number of incomplete processing requests, and add this to all service using side processes Function to
Subtract the number of incomplete processing requests for each service using side process from the number of incomplete processing requests for all service using side processes for each service providing side process to obtain the number of other requests for each service using side process. A function to calculate,
A load distribution processing system comprising a function of transmitting the number of other requests to a processing request distribution unit related to a corresponding service using side process. When the load information management unit returns the processing result to the processing request distribution unit of the service using side process, the load information management unit collects the processing request reception number related to each service using side process and the processing related to each service using side process. It has a function to calculate the total value of the number of result replies and send it to the processing request distribution part together with the processing result,
The processing request distribution unit subtracts the total value of the processing result reply number from the total value of the processing request reception number, and calculates the number of other requests by subtracting the number of own requests from the difference,
4. The load distribution processing system according to claim 3, further comprising a function of updating the number of other requests related to the service providing side process in the first storage area based on the number of other requests. When the processing request distribution unit transmits the processing request to the load information management unit of the service providing side process, whether or not the number of incomplete processing requests related to the service providing side process exceeds a preset threshold value A function to determine whether
A function of temporarily storing the processing request in the fourth storage area for standby when the threshold value is exceeded;
Each time the storage information of the first storage area is updated, the number of unprocessed processing requests with respect to each processing request stored in the fourth storage area is smallest with reference to the first storage area. The ability to identify the service provider process;
It is determined whether or not the number of incomplete processing requests of the service providing side process is less than or equal to a preset threshold, and if the number is less than or equal to the threshold, the processing request is transmitted to the load information management unit of the corresponding service providing side process The load distribution processing system according to claim 1, further comprising a function. A securities transaction in which the service-use-side process calculates a price according to a preset rule at a preset timing and generates a new order information corresponding to the quantity allocated to itself based on the price. It consists of multiple ordering processes of the automated execution system,
The service providing process is interposed between the ordering process and the gateway process, receives the order information generated by the ordering process, transmits the order information to the gateway process, and the computer of the stock exchange transmitted from the gateway process. It consists of multiple acceptance processes that execute processing to send order confirmation information from the above ordering process,
The processing request distribution unit transmits the order information generated by the ordering process as the processing request to the load information management unit of the reception process, and the order confirmation transmitted from the load information management unit of the reception process. Pass information to the ordering process as a result of the processing,
The load information management unit receives the order information as the processing request from the processing request distribution unit of the ordering process, passes the order information to the receiving process, and the order confirmation information as the processing result passed from the receiving process Is transmitted to the processing request distribution part of the ordering process. 6. The load distribution processing system according to claim 1, wherein The service usage process consists of the reception process,
The service provider side process consists of the gateway process,
The processing request distribution unit transmits the order information passed from the reception process as the processing request to the load information management unit of the gateway process, and the order confirmation transmitted from the load information management unit of the gateway process. Pass the information to the reception process as the processing result,
The load information management unit receives the order information as the processing request from the processing request distribution unit of the reception process, passes the order information to the gateway process, and receives the order confirmation information as the processing result passed from the gateway process. The load distribution processing system according to claim 6, wherein the load distribution processing system is transmitted to a processing request distribution unit of the reception process.

Images