JP2016018222A - Queue server - Google Patents

Abstract

PROBLEM TO BE SOLVED: To solve the problem in which the background art is incapable of controlling in units of internal requests of queue for each service realization system per queue, although it can guarantee the order of priority, making it necessary to design a queue for each service realization system and bringing about complexity in operation, and also has a drawback in that, since the queue is processed in order of storage, if a request at the top of queue results in an error, a subsequent process is delayed although it has no interrelation with the top.SOLUTION: When requests in a queue have no interrelation in the processing in order of storage in the same queue that is the feature of a queue, it is allowed that the requests are assigned with priority and processed in order of priority. The queue and queue management are thereby facilitated. A priority management table for managing the interrelation of messages in a queue is prepared, and, when requests are stored in a queue, they are assigned with a priority determination key, so that, even when they have no interrelation in the same queue, no requests are kept resident in the queue.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a system for handling queues in a system for realizing each service.

  A system that holds a conventional queue creates a queue for each application, and handles each request as a message for each queue and controls the request by FIFO (first in first out). For example, when a service such as service subscription / cancellation used in a mail system or the like is performed, a system configuration using a server using a queue is generally used. The reason for using the queue is that processing from the terminal (client server) is performed without delay, and that requests are not lost even when a failure occurs in each server that implements the service.

  There exists patent document 1 as a related technique. What is disclosed in this document is a "queue integration system that can integrate a group of queues with order dependencies in the correct order for each consumer system". Processing is performed with priority between queues, not within the queue. Technology. Therefore, by creating a queue for each service and further providing a combined queue that manages the priority between the queues, the priority of requests between the queues is determined, and processing is performed according to the priority. (See summary).

JP 2007-266724 A

  With the technique disclosed in Patent Document 1, priority can be guaranteed for each service realization system for each queue, but the order cannot be controlled in units of requests in the queue. In addition, it is necessary to design a queue for each service realization system, and the operation is complicated.

  Further, in a system using queues as shown in FIG. 9, the queues are processed in the order of storage. Since processing is performed in the order of storage, there is a problem that processing delay occurs due to the influence of processing of other requests stored in the queue that have no mutual relationship. Also, as shown in FIG. 10, there is a problem that when the head request becomes an error, the subsequent processing is delayed even if there is no correlation with the head.

  Not only the above-mentioned requests, but also data that can be handled as messages to be stored in a queue, for example, characters, diagrams, images, sounds, videos, etc. that are sent and received between personal computers, mobile phones, and personal digital assistants using various communication protocols There are similar problems with information such as e-mail, sensor information, and data transmitted by things such as cars.

  The present invention makes it possible to control the processing order of messages in a queue based on the interrelationship with other messages in the processing in the storage order that is a characteristic of the queue within the same queue. Provides queue control technology that facilitates queue management.

  The present invention provides a priority management table for managing the mutual relationship of messages in a queue, and assigns a key (hereinafter referred to as a priority determination key) for associating mutually related messages when storing the queue. It is characterized by enabling independent processing of messages having no mutual relationship in the queue and preventing queue retention by order control using a priority determination key.

A more specific aspect of the present invention is a queue server that relays a service request received from a client server to a plurality of service realization servers.
The queue server includes a queue and a queue information management unit. The queue information management unit associates the received message destined for one of the service realization servers with another message having a correlation with the message. Is stored in the queue, and the same key as the key is acquired for the message acquired from the queue and the other message with the same key as the key attached to the message. A transmission process to any one of the service realization servers is performed independently of the other messages not attached.
The queue information management unit associates the messages with the same key with each other when storing the message in the queue, and refers to the association when acquiring the message from the queue. You may comprise.

  According to the present invention, when a request is stored in a queue and when a request is acquired from a queue, it is possible to simplify the queue design and to eliminate a processing delay affected by an unrelated request.

The figure which illustrates the logical structure and table of a present Example Sequence diagram illustrating normal processing when priority determination keys are all the same in this embodiment Sequence diagram illustrating error processing when priority determination keys are all the same in this embodiment Sequence diagram illustrating normal processing when priority determination key in this embodiment is different only in request B Sequence diagram illustrating error processing when priority determination keys in this embodiment differ only in request B The figure which illustrates the flowchart when the request is stored in the queue The figure which illustrates the flowchart at the time of request acquisition from the queue Diagram illustrating a flowchart when deleting a request from the queue Sequence diagram showing normal processing on a server using a conventional queue Sequence diagram showing error handling at a server using a conventional queue

  Hereinafter, embodiments of the present embodiment will be described in detail with reference to the drawings. In the following embodiment, a service request will be described as an example of a message. Other messages can be similarly implemented.

  FIG. 1 shows a logical configuration and a table diagram of the embodiment of the present embodiment. Reference numeral 300 denotes a queue server, which is hereinafter referred to as a priority guarantee server. The priority guarantee server 300 is connected to the client server 102 that transmits a request for each service and the service implementation servers 104 to 106 that provide the requested service based on the request relayed by the priority guarantee server 300.

  The priority guarantee server 300 manages an input interface 302 that receives a request from the client server 102, a queue 303 that stores a request from the input interface, and a case where a request is stored in the queue 303 or output from the queue 303. A queue information management unit 304 and an output interface 305 are provided.

  The queue information management unit 304 holds a queue storage management table 309, a queue acquisition management table 313, and a priority order control table 310 on the memory.

  The queue storage management table 309 stores a list in which request IDs 307 and priority determination keys 308 are associated with each other when storing requests in the queue, and is used for managing the stored requests. The queue acquisition management table 313 stores a request ID 314 when a request is acquired from the queue 303 and is used to manage the request acquired from the queue 303.

  The priority order control table 310 is a table having a priority order determination key 308 as a unique key and a list of request IDs 307a and 307b associated with each priority order determination key 308. The queue information management unit 304 controls the transmission order of requests by referring to the priority control table 310 when storing a request in the queue and when acquiring the request from the queue.

  When acquiring a request from the queue, the queue storage management table 309 is searched to extract a request that can be acquired. When the priority determination key 308 is set for the request ID to be acquired, the priority control table 310 is referred to in order to determine whether or not the request ID can be acquired.

  The priority determination key 308 is information for determining whether a request to be acquired is a target of order control at the time of transmission when the request is extracted from the queue. Of the requests stored in the queue, requests to which the same priority determination key 308 is assigned are transmitted in the order of storage. For example, by setting a telephone number or event information as a priority determination key, a request can be transmitted regardless of other telephone numbers and event information.

  The priority guarantee server 300 can be realized by using a general computer including a processor, a storage device, and a communication device. More specifically, the queue information management unit 304 can be realized by the processor executing a program stored in the storage device, and the queue 303 can be configured on the storage device. Further, the input interface 302 and the output interface 305 can be realized by the processor executing the program and cooperating with the communication apparatus.

  Next, normal processing when all the priority determination keys 308 in this embodiment are set to the same value will be described according to the sequence of FIG.

  A request A 407 is transmitted from the customer terminal 101 to the client server 102.

  The client server 102 transfers the request A to the priority guarantee server 300, and stores the request A in the queue 303 in the process of 409.

  The priority guarantee server 300 returns a normal response 410 to the client server 102, and the client server 102 returns a normal response 411 to the customer terminal 101.

  Next, request B is processed in the same sequence as request A.

  The request B 412 is transmitted from the customer terminal 101 to the client server 102, and the client server 102 transfers the request B 413 to the priority guarantee server 300.

  The priority guarantee server 300 stores the request B in the queue 303 by the process of 414.

  After the processing of 414, the priority guarantee server 300 returns a normal response 415 to the client server 102, and the client server 102 returns a normal response 416 to the customer terminal 101.

  Subsequently, the request C is processed in the same sequence as the request A and the request B.

  The request C417 is transmitted from the customer terminal 101 to the client server 102, and the client server 102 transfers the request C418 to the priority guarantee server 300.

  The priority guarantee server 300 stores the request C in the queue 303 in the process of 419.

  After the processing of 419, the priority guarantee server 300 returns a normal response 420 to the client server 102, and the client server 102 returns a normal response 421 to the customer terminal 101.

  In the priority guarantee server 300, the request A, the request B, and the request C are stored in the queue 303 in the order, and since the priority guarantee keys are the same, the request is obtained from the queue 303 in the process 422, and the service realization server Request A is transmitted to A 104, and service realization server A 104 responds with normal response 424.

  After the process 422, the request A is deleted from the queue 303 in the process 425.

  Subsequently, in the process of 426, the request B is acquired from the queue 303, the request B427 is transmitted to the service realization server B105, and the service realization server B105 responds with a normal response 428.

  After the process of 426, the request B is deleted from the queue 303 in the process of 429.

  Finally, request C is acquired from the queue 303 in the process of 430, the request C431 is transmitted to the service realization server C106, and the service realization server C106 responds with a normal response 432.

  After the process of 430, the request C is deleted from the queue 303 in the process of 433.

  As described in detail in FIG. 2, when the priority guarantee server 300 receives the request A, the request B, and the request C continuously, and the priority determination key 308 is the same, the requests are processed in the storage order.

  FIG. 3 is a diagram at the time of error processing when all of the priority determination keys 308 in this embodiment are set to the same value, and will be described according to the sequence.

  A request A 507 is transmitted from the customer terminal 101 to the client server 102.

  The client server 102 transfers the request A to the priority guarantee server 300 and stores the request A in the queue 303 in the process of 509.

  The priority guarantee server 300 sends a normal response 510 to the client server 102, and the client server 102 sends a normal response 511 to the customer terminal 101.

  Next, request B is processed in the same sequence as request A.

  The request B 512 is transmitted from the customer terminal 101 to the client server 102, and the client server 102 transfers the request B 513 to the priority guarantee server 300.

  The priority guarantee server 300 stores the request B in the queue 303 in the process of 514.

  After the processing of 514, the priority guarantee server 300 returns a normal response 515 to the client server 102, and the client server 102 returns a normal response 516 to the customer terminal 101.

  Subsequently, the request C is processed in the same sequence as the request A and the request B.

  The request B517 is transmitted from the customer terminal 101 to the client server 102, and the client server 102 transfers the request C518 to the priority guarantee server 300.

  The priority guarantee server 300 stores the request C in the queue 303 in the process of 519.

  After the processing of 519, the priority guarantee server 300 returns a normal response 520 to the client server 102, and the client server 102 returns a normal response 521 to the customer terminal 101.

  Next, the priority guarantee server 300 acquires the request A from the queue 303 in the process of 522, and transmits the request A to the service realization server A104.

  The service realization server A104 returns an error response 524.

  Since the priority guarantee server 300 receives the error response, the priority guarantee server 300 executes the retry process of the request A in the process of 525.

  Regarding the request B and the request C stored in the queue 303, the request A and the request C shown in FIG. 2 are not executed because the process of the request A is executed by the process of 525.

  Next, normal processing when the priority determination key 308 in this embodiment sets a different value only for the request B will be described according to the sequence of FIG.

  A request A 607 is transmitted from the customer terminal 101 to the client server 102.

  The client server 102 transfers the request A to the priority guarantee server 300 and stores the request A in the queue 303 in the process of 609.

  The priority guarantee server 300 returns a normal response 610 to the client server 102, and the client server 102 returns a normal response 611 to the customer terminal 101.

  Next, request B is processed in the same sequence as request A.

  The request B 612 is transmitted from the customer terminal 101 to the client server 102, and the client server 102 transfers the request B 613 to the priority guarantee server 300.

  The priority guarantee server 300 stores the request B in the queue 303 in step 614.

  The priority guarantee server 300 returns a normal response 615 to the client server 102 after the processing of 614, and the client server 102 returns a normal response 616 to the customer terminal 101.

  Subsequently, the request C is processed in the same sequence as the request A and the request B.

  The request C617 is transmitted from the customer terminal 101 to the client server 102, and the client server 102 transfers the request C618 to the priority guarantee server 300.

  The priority guarantee server 300 stores the request C in the queue 303 in the process of 619.

  The priority guarantee server 300 returns a normal response 620 to the client server 102 after the processing of 619, and the client server 102 returns a normal response 621 to the customer terminal 101.

  In the priority guarantee server 300, the request A, the request B, and the request C are stored in the queue 303 in the order.

  In the process of 622, a request is acquired from the queue 303, the request A is transmitted to the service realization server A104, and the service realization server A104 responds with a normal response 624.

  After the process 622, the request A is deleted from the queue 303 in the process 625.

  Unlike the conditions shown in FIG. 3, the priority guarantee key is different only in request B. Therefore, in step 626, request C is acquired from queue 303, request C627 is transmitted to service realization server C106, and service realization server C106. Responds with a normal response 628.

  After the process of 626, the request C is deleted from the queue 303 in the process of 629.

  Finally, request B is acquired from the queue 303 in the process of 630, the request B631 is transmitted to the service realization server B105, and the service realization server B105 responds with a normal response 632.

  After the process 630, the request B is deleted from the queue 303 in the process 633.

  As described in detail in FIG. 4, when the priority guarantee server 300 continuously receives request A, request B, and request C, and when the priority determination key 308 is different only in request B, request A, request C Are processed in the storage order, but request B can be processed regardless of the processing of request A and request C.

  FIG. 5 is a diagram at the time of error processing when the priority order determination key 308 in this embodiment sets different values only for the request B, and will be described according to the sequence.

  A request A 707 is transmitted from the customer terminal 101 to the client server 102.

  The client server 102 transfers the request A to the priority guarantee server 300 and stores the request A in the queue 303 in the process of 709.

  The priority guarantee server 300 returns a normal response 710 to the client server 102, and the client server 102 returns a normal response 711 to the customer terminal 101.

  Next, request B is processed in the same sequence as request A.

  The request B 712 is transmitted from the customer terminal 101 to the client server 102, and the client server 102 transfers the request B 713 to the priority guarantee server 300.

  The priority guarantee server 300 stores the request B in the queue 303 by the process of 714.

  After the processing of 714, the priority guarantee server 300 returns a normal response 715 to the client server 102, and the client server 102 returns a normal response 716 to the customer terminal 101.

  Subsequently, the request C is processed in the same sequence as the request A and the request B.

  The request C 717 is transmitted from the customer terminal 101 to the client server 102, and the client server 102 transfers the request C 718 to the priority guarantee server 300.

  The priority guarantee server 300 stores the request C in the queue 303 in step 719.

  After the processing of 719, the priority guarantee server 300 returns a normal response 720 to the client server 102, and the client server 102 returns a normal response 721 to the customer terminal 101.

  Next, the priority guarantee server 300 acquires the request A from the queue 303 in the process of 722, and transmits the request A to the service realization server A104.

  The service realization server A104 returns an error response 724.

  Since the priority guarantee server 300 receives the error response, the priority guarantee server 300 executes the retry process of the request A in the process of 725.

  For request C stored in the queue 303, the processing of request A shown in FIG. 4 is not executed because the processing of request A is executed in the processing of 725.

  Since the priority order determination key 308 is different for the request B, the request B727 is transmitted to the service realization server B105 in the process of 726, and the service realization server B105 responds with a normal response 728.

  After the process at 726, the request B is deleted from the queue 303 at the process at 729.

  Next, details of the process of storing a request in the queue 303 by the queue information management unit 304 of the priority guarantee server 300 will be described with reference to the flowchart of FIG.

  In the request storage process, the presence / absence of the priority determination key 308 is analyzed in step 801 in order to determine whether to control the priority of the request.

  In step 802, the priority determination key 308 is determined. If the priority determination key 308 exists, the request ID 307 and the priority determination key 308 are associated with the queue storage management table 309 described in FIG. Store.

  Thereafter, in step 804, information in the priority order control table 310 is acquired. In step 805, it is determined whether the priority order determination key 308 has been registered in the priority order control table 310.

  If the determination result is YES, since it is already registered, it will be processed after the previously stored request ID 307. Therefore, it is added after the request ID 307 already registered in the processing of 806. Stores the request ID 307.

  Thereafter, the request is stored in the queue 303 in the process 807.

  If the determination result of 805 is NO, the priority determination key 308 and the request ID 307 are newly stored in the priority control table 310.

  If the priority determination key 308 is not found in the determination of 802, the request ID 307 is stored in the queue storage management table 309, the request is stored in the queue 303 in the processing of 807, and the processing is terminated.

  Next, details of the process of acquiring a request from the queue 303 by the queue information management unit 304 of the priority guarantee server 300 will be described with reference to the flowchart of FIG.

  In the request acquisition process, information of the queue storage management table 309 is acquired in 901 in order to determine the requests that can be acquired.

  A request ID 307 and a priority determination key 308 are acquired from the queue storage management table 309 acquired in 901, and the presence or absence of the priority determination key 308 is determined in 902.

  If the determination result is none, the request does not need to be transmitted to each server with priority because there is no priority determination key. Therefore, the request is acquired from the queue 303 at 910, the request acquired at 911 is transmitted to each server, the request ID 307 is stored in the queue acquisition management table 313 at 912, and the request ID 307 from the queue storage management table 309 is prioritized at 913. The rank determination key is deleted, and the process ends.

  In the case of the determination result of 902, there is a priority determination key, and it is necessary to maintain the priority of request transmission to each server. Therefore, information is acquired from the priority order control table 310 at 903.

  It is determined from the priority order control table 310 whether the request ID 307 acquired at 904 is the head.

  When the determination result is YES, since the request to be acquired is the first among the requests stored in the queue at the time of acquisition, the request is acquired from the queue 303 in 905, and the request is transmitted to each server in 906. In step 907, the request ID 307 is stored in the queue acquisition management table 313. In step 909, the request ID 307 and the priority determination key 308 are deleted from the queue storage management table 309, and the processing ends.

  If the determination result of 904 is NO, it means that the request to be acquired is not stored at the head, and there is a request to be transmitted with priority, so the processing is performed without executing anything after that. finish.

  Next, details of the process of deleting a request from the queue 303 by the queue information management unit 304 of the priority guarantee server 300 will be described with reference to the flowchart of FIG. In the request deletion process, the queue acquisition management table 313 information is acquired at 1001, the request ID 307 is deleted from the queue acquisition management table 313 at 1002, the information is acquired from the priority control table 310 at 1003, and the priority is acquired at 1004. The request ID 307 is deleted from the control table 310, the request is deleted from the queue 303 at 1005, and the process is terminated.

300: Priority guarantee server 303: Queue 304: Queue information management unit 309: Queue storage management table 310: Priority order control table 313: Queue acquisition management table

Claims (2)

A queue server that relays service requests received from a client server to a plurality of service realization servers,
A queue and a queue information management unit,
The queue information management unit
The received message addressed to any one of the service realization servers is stored in the queue with a key for associating the message with other interrelated messages,
The other messages that are not given the same key as the key with respect to the message obtained from the queue and the other message that is given the same key as the key attached to the message. A queue server characterized by independently performing a transmission process to any one of the service realization servers. The queue server according to claim 1,
The queue information management unit
When storing the message in the queue, the messages with the same key are associated with each other;
A queue server that refers to the association when acquiring the message from the queue.

Images