TWI506980B - The queuing system, the device and the method for the network service - Google Patents

Description

Queue processing system, device and method for network service

A network system, device and processing method, in particular, a queue processing system, device and method for a network service.

With the rapid development of the Internet, it has also driven many Internet services. For example, online booking or online shopping is different from previous Internet services. Users do not need to go out to the physical storefront, they can achieve the purpose of consumption at home. However, these network services are often limited by factors such as the external bandwidth of the website or the performance of the background server, which may cause delays in the user's network service. What's more, there may be cases where the device providing the network service is down or damaged.

Please refer to FIG. 1 , which is a schematic diagram of the architecture of a network service of the prior art. The conventional technology can solve the problem that all the clients 110 can use the network service provided when they are connected at the same time. Therefore, a load balancing device 120 is further disposed between the plurality of backend servers 130 and the plurality of clients 110. The load balancing manager 120 will assign the connection request issued by the client 110 to any of the backend servers 130. Although such an approach can reduce the latency of the client 110 and the load of the backend server 130.

However, the load balancer of the prior art can only perform load detection and connection assignment to each backend server 130 by static law. Therefore, on the one hand, it cannot flexibly increase or decrease the number of backend servers 130, and on the other hand, it cannot automatically slow down the number of connections to the backend server 130. Therefore, when a large number of clients 110 send out the connection When the momentary influx occurs, all the backend servers 130 will be blocked or even crashed, and the client 110 connected to the backend server 130 will not be able to obtain the corresponding service. When the backend server 130 is repaired, when the original client 110 re-issues the connection request, the requested items, such as tickets or tickets, may have been acquired by other clients at the instant of server repair, thus causing the first connection. The line is not able to get the service.

In view of the above problems, the present invention provides a queue processing system for a network service, which is applied to an output of a plurality of clients waiting for a network service.

The queue processing system of the network service disclosed by the present invention includes at least one backend server, a load balancing manager and a load controller. The backend server requests the corresponding network service for the dialogue sent by the client, and responds to the processed output result; the load balancing manager is connected to the client and the backend server, and the load balancing manager receives each client's The dialog request and assign the dialog request to the backend server; the load controller is connected to the load balancing manager and the backend server, and the load controller obtains the running status information of the backend server, and the server is listed in the state after the good state is available. Immediately provide a list of services and notify the load balancing manager to select these backend servers that can provide services to serve the client's conversational requirements.

The load balancing manager detects that there is queue identification information in the dialog request, and the load balancing manager transmits the dialog request to the selected backend server. If the queue identification information does not exist in the dialog request, the load balancing manager will The received dialog request is forwarded to the load controller, and the load controller adds the queue identification information to the dialog. The requester replies the queue identification information to the client, and the client stores the queue identification information and then returns the dialog request to the load balancing manager, and the load balancing manager adds the dialog request to the queue unit, so that the dialog request is queued. The unit is waiting to be assigned to the backend server.

The invention further provides a queue processing device for a network service, comprising: a first interface, a second interface and a processing unit. The first interface receives the dialog request of each client; the second interface receives the running status information of each backend server; the processing unit is electrically connected to the load balancing manager through the first interface; the processing unit adds the queue identification information to the dialog request And returning to the client; the processing unit determines whether each backend server is enabled or disabled according to the received operating state.

A method for processing a queue of a network service according to the present invention includes the following steps: determining, by the load controller, an operating state of each backend server to determine whether it is enabled or disabled; and receiving by the load balancing manager The end server enables/disables the running state and the client's dialogue request; determines whether the dialog request has queue identification information; if the dialog requires queue identification information, the load balancing manager selects the information from the queue unit according to the order of the queue identification information The dialog request is taken out, and the dialog request is distributed to the corresponding backend server according to the enabled/disabled running state; the backend server discards the dialog request note after completing the service, and notifies the load controller; When the request does not have the queue identification information, the dialog request is forwarded to the load controller; after the queue identification information is added to the dialog request, the dialog request is sent to the client; the client stores the queue identification information according to the dialog request that has been added to the queue identification information. And forward this conversation request back to the load balancing manager.

The queue processing system, apparatus and method for the network service proposed by the invention enable the server of the back end to ensure the fairness of the queue order when the client is in the queue. The features and implementations of the present invention are described in detail below with reference to the drawings.

The network service of the present invention may be, but is not limited to, online ticketing, online auction, or a service that needs to provide a fair queuing of the client. Please refer to FIG. 2A, which is a schematic diagram of the network connection architecture of the present invention. The queue processing system of the network service of the present invention mainly includes the following parts, which are a client 210, a load balancing device 220, a load controller 230, and a backend server 240. The client 210 is connected to the queue processing device via a network. The client 210 may be an electronic device having an internet browser such as a personal computer, a smart phone, a tablet or a notebook computer.

The client 210 will make a session request to a website providing a web service through a browser or an application. The dialog requirements of the client 210 are directed to any of the plurality of backend servers 240 connected to the backend of the website. The load balancing manager 220 distributes the dialog requests issued by the different clients 210 to the corresponding backend server 240 for processing of the network service (the allocation process will be described later in detail).

Please refer to FIG. 2B, which is a schematic diagram of the structure of the load controller of the present invention. The load balancing manager 220 of the present invention further includes a queue unit 221. The queue unit 221 can record the dialog requirements in sequence. The queue unit 221 can be implemented by a storage device, such as a hard disk or a flash memory. A fixed area is divided into the array unit 221 of the present invention, and the entire flash memory can also be regarded as a queue unit 221. In general, the queue unit 221 having the function of First In First Out (FIFO) can be implemented by means of a Queue or a Pointer.

The load controller 230 of the present invention includes a first interface 231, a second interface 232, and a processing unit 233. The processing unit 233 is electrically connected to the first interface 231 and the second interface 232. The type of the first interface 231 (the same for the second interface 232) can be transmitted through an Ethernet network, a fiber network, a storage area network (Storage Access Network), and an Internet type. Internet Small Computer System Interface (iSCSI) or other cable for communication connection.

The first interface 231 receives the dialog request from the client 210 through the load balancing manager 220. The load balancing manager 220 detects whether there is queue identification information in the input dialog request. If there is no queue identification information in the dialog request, the load balancing manager 220 will forward the pen dialog request to the load controller 230. The processing unit 233 of the load controller 230 may be based on any one or a combination of a time stamp, an IP address, a MAC address, or a User ID. Generate unique queue identification information. The queue identification information is used to identify the queue order in which the client 210 obtains the network service. The processing unit 233 can write the queue identification information into the dialog request by means of small text files (cookies).

After the processing unit 233 completes the writing of the queue identification information, the processing unit 233 The processed dialog request will be replied to the client 210. The client 210 stores the queue identification information and forwards the dialog request back to the load balancing manager 220. The queue unit 221 is used to record the dialog request when the backend server 240 is blocked.

The processing unit 233 receives the operating status information from the backend server 240 through the second interface 232. The operational status information is the processor load (CPU loading), memory utilization, session number, and response time of the backend server 240. Further, heartbeat information may also be added to the running status information, so that the processing unit 233 can detect whether the backend server 240 is alive. The processing unit 233 can determine, according to the running status information, whether the backend server 240 is in a busy state or a network congestion.

When the backend server 240 is in a busy state or a network congestion, more clients 210 influx appear on the backend server 240. Therefore, the processing unit 233 determines whether to temporarily stop assigning the dialog request to the backend server 240 based on the running status information. In this case, the action of temporarily stopping the allocation is defined as disable. What is relatively disabled is that the action of unblocking the suspended backend server 240 is defined as enable.

When the backend server 240 is deemed disabled, the load controller 230 transmits the determined information of the backend server 240 to the load balancing manager 220. The load balancing manager 220 will begin to stop assigning session requests to the backend server 240 based on the received message. If the operational state of the disabled backend server 240 is reduced to a working condition, the processing unit 233 will reissue the load balancing manager 220. The enable request of the backend server 240. After the load balancing manager 220 receives the enable request, the load balancing manager 220 will again reassign the dialog request to the backend server 240.

In order to fully explain the operation process of the present invention, please also refer to FIG. 3 and FIG. 4, which are schematic diagrams and timing diagrams of the operational flow of the present invention. The queue processing method of the present invention includes the following steps: Step S310: The load controller obtains the running status of each back-end server; Step S320: The load balancing manager receives the dialog requirements of the running status and the client; Step S330: Load balancing The manager determines whether there is queue identification information in the dialog request; step S340: if the dialog request has queue identification information, the load balancing manager distributes the dialog request to the corresponding one according to the status of enabling or disabling of each backend server. End server; step S350: if the dialog request does not have queue identification information, then forward the dialog request to the load controller; step S360: after adding the queue identification information to the dialog request, the load controller replies the dialog request to the client; And step S370: the client stores the queue identification information according to the dialog request that has been added to the queue identification information, and returns the dialog request to the load balancing manager.

First, the load balancing manager 220 receives the dialog request of the client 210, negative The load controller 230 receives operational status information of the backend server 240. The processing order of these two steps is not limited, and the two can be executed in parallel or sequentially (refer to the arrow at the top of Figure 4A). When the load balancing manager 220 receives the dialog request, the load balancing manager 220 detects whether the queue identification information exists in the dialog request. Since the client 210 is communicating with the load balancing manager 220 for the first time, the dialog request of the client 210 necessarily does not have queue identification information.

When there is no queue identification information in the dialog request, the load balancing manager 220 forwards the dialog request to the load controller 230. The load controller 230 generates queue identification information based on the aforementioned time stamp, network address, media access control address, or user information. The load controller 230 adds the generated queue identification information to the dialog request. The load controller 230 returns the processed dialog request to the client 210 (as shown in Figure 4A). The client 210 then loops back to the load balancing manager 220 based on the processed dialog requirements. The load balancing manager 220 can determine whether to temporarily store the dialog request in the queue unit 221 according to the congestion status of the backend server 240.

The load controller 230 will immediately obtain the running status information of the backend server 240. The obtained method can be implemented by monitoring the backend server 240 or installing an agent on the backend server 240. For example, when the agent is installed in the backend server 240, the agent can periodically report the running status information such as the processor load, the memory usage, the number of conversations, and the network response time to the load controller 230.

When the running status information of the backend server 240 is abnormal, the load controller 230 will mark the abnormality of the backend server 240 as disabled, and notify the load balancing manager 220 which backend server 240 is to be Prohibited. When the load balancing manager 220 allocates the dialog request, the load balancing manager 220 will not assign the dialog request to the disabled backend servers 240.

In addition, if all of the backend servers 240 are disabled, the load balancing manager 220 will sequentially record these dialog requests in the queue unit 221. It can be avoided that the client 210 is assigned to the backend server 240 that is being blocked. If the load controller 230 determines that any of the backend servers 240 can be enabled, the load controller 230 will transmit a message that can be enabled to the load balancing manager 220.

The load balancing manager 220 will sequentially fetch the dialog request from the queue unit 221 and assign the selected dialog request to the backend server 240 that is operational. Although the client 210 will remain in the waiting state, when the part of the backend server 240 is enabled, the client 210 can be provided with the corresponding network service again, thereby ensuring that all the clients 210 can use the network service. .

While the client 210 is waiting for the network service, the load balancing manager 220 can periodically send a prompt signal to the client 210. For example, load balancing manager 220 can communicate the expected completion time of the current queuing to client 210. The display of the client 210 will display how long it will take to obtain the network service. Alternatively, the load controller 230 can write the expected completion time to the small file file and send it to the client 210 together to prompt the client 210 for a predetermined time.

The following is a schematic illustration of an example, and is not limited to this number. Please also refer to the 5A-5D diagram, which is a schematic diagram of the queue processing of the present invention. In FIG. 5A, there are a client A 511, a client B 512 and a client C 513 and a first backend server 551, a second backend server 552, a third backend server 553, and a fourth backend server 554. It is assumed that a dialog request is issued in the following order: client A 511 issues a dialog request a 521 to load balancing manager 530, client B 512 issues a dialog request b 522 to load balancing manager 530, and client C 513 issues a dialog request to load balancing manager 530 c523 As shown in Figure 5A. And the queue unit 531 at this time does not record any conversation record.

Since these dialogs require that a521, b522, and c523 are issued for the first time, there is no queue identification information in the dialog requests a521, b522, and c523. Therefore, the load balancing manager 530 forwards the dialog request to a521, b522, c523 to the load controller 540. The load controller 540 will add the corresponding queue identification information to the dialog request a521, b522, c523 according to the received order, and return the processed dialog request to the clients A511, B512 and C513, after the client stores the queue identification information. The conversation request with queue identification information is transferred back to the load balancing manager 530. The load balancing manager 530 is further recorded in the queue unit 531 according to the order of the queue identification information, as shown in FIG. 5B.

The load controller 540 receives the running status information α from the first backend server 551, the running status information β of the second backend server 552, the running status information γ of the third backend server 553, and the fourth back. The running status information δ of the end server 554. Please refer to Table 1 below for the contents of the operational status information.

As can be seen from Table 1, the processor load of the second backend server 552 has exceeded the alert condition (please refer to the bold black font in Table 1), and the processor load and response time of the fourth backend server 554 are both exceeded. Warning conditions. Therefore, the operational status of the second backend server 552 and the fourth backend server 554 has been determined by the load controller 540 to be disabled. Therefore, the load controller 540 will disable the second backend server 552 and the fourth backend server 554, and notify the load balancing manager 530 of the disabled backend server. Referring to FIG. 5B, in FIG. 5B, the disabled second backend server 552 and fourth backend server 554 are denoted by "X".

While the second backend server 552 and the fourth backend server 554 are in the disabled state, the second backend server 552 and the fourth backend server 554 continue to send the running status information. When the load of the second backend server 552 or the fourth backend server 554 is below the alert condition, the load controller 540 enables the backend server.

It can be known from the new running status information that the load of the second backend server 552 has not met the alert condition. Therefore, the load controller 540 will unblock the second backend server 552 and notify the load balancing manager 530 to enable the second backend server 552. At the same time, the load balancing manager 530 determines to allocate the dialog request to the corresponding backend server according to the operating state of each of the backend servers 551, 552, 553, 554.

As can be seen from Table 2, the operational state of the first backend server 551 is the lightest of all backend servers. Therefore, the load balancing manager 530 will assign the dialog request a521 to the first backend server 551, as shown in FIG. 5C. Therefore, the dialog request a521 is removed from the queue unit 531. After the first backend server 551 completes the dialog request a521, the first backend server 551 will respond to the client A511 with the result of the service, please refer to FIG. 5D. The other dialog requests b522 and c523 that are also queued in the queue unit 531 also perform the assignment of the backend server according to the running status information. Once the running status information of the backend servers 551, 552, 553, 554 appears When the alert condition is exceeded, the load controller 540 will require the load balancing manager 530 to disable the backend server 240 that exceeds the alert condition.

In addition to the above-described embodiments, the present invention proposes another mode of operation. Since client 210 may utilize the conversations that have been queued, it is required to re-insert the queue that is being queued again. Therefore, in order to achieve the purpose that the client 210 can be queuing fairly, a mechanism for judging whether there is repeated queuing is added in this embodiment. After the client 210 has queued up and obtained the corresponding network service, the load balancing manager 220 will ask the client 210 to queue again. In this embodiment, the dialog requirements that have been completed are marked as obsolete. In other words, the completed dialogue requirement is that the network service cannot be proposed again. Please refer to FIG. 6, which is a schematic diagram of the operation of another embodiment of the present invention. The implementation aspect includes the following steps: Step S610: the load controller obtains the running status of each back-end server; Step S620: The load balancing manager receives the dialogue request of the running status and the client; Step S630: Load balancing management The device determines whether the dialog request has been discarded. If the dialog request has been discarded, step S680 is performed; step S640: if the dialog request has not been discarded, the load balancing manager determines whether the dialog request has queue identification information; step S650: if the dialog request is If there is queue identification information, the load balancing manager extracts the dialog request from the queue unit according to the order of the queue identification information, and distributes the dialog request to the corresponding backend server according to the running status; Step S660: the backend server discards the note request note after completing the service, and notifies the load controller; step S670: the load controller sends the abolition command to the client or the load balance manager to clear the queue identification of the pen session request Information; step S680: if there is no queue identification information in the dialog request, forwarding the dialog request to the load controller; step S690: adding the queue identification information to the dialog request, replying the dialog request to the load client; and step S710: the client The queue identification information is stored according to the dialog request that has been added to the queue identification information, and the conversation request is transferred back to the load balancing manager.

First, the load controller 230 obtains the operational status of each of the backend servers 240. The load balancing manager 220 receives the dialog requirements of these operational states with the client 210. Next, the load balancing manager 220 will detect if the dialog request has been discarded. If the conversation request has been discarded, then on behalf of the client 210 may be queuing again with the previous conversation request. Therefore, the load balancing manager 220 will forward this dialog request to the load controller 230, causing the pen session to request processing for obtaining new queue identification information.

If the dialog request is not discarded, it indicates that the client 210 may perform a reloading action. In general, the dialog requirements are not broken during the reorganization of the browser page. Therefore, the client 210 will still present the service to the load balancing manager 220 with the existing dialog requirements. When the client 210's dialog request has been made by the backend servo After the server 240 completes the network service, the backend server 240 returns the output to the client 210 and notifies the load controller 230 to note the pen dialog request as obsolete. The load controller 230 can send an abort command to the client 210 (as shown in FIG. 4A), causing the client 210 to clear the queue identification information requested by the pen session to achieve the purpose of discarding the pen session request at the client 210; The load controller 230 can also send an abort command to the load balancing manager 220 (as shown in FIG. 4B), causing the load balancing manager 220 to note the pen dialog request as obsolete, which has the advantage of being set in the load balancing manager 220. On the line of defense, the dialogue that has completed the service is not required to be used to queue again to avoid unfair service.

In addition to the above, the dialogue request will be discarded, and in another case the conversation request will be discarded. After the client 210's dialog request has been completed by the backend server 240, the backend server 240 is unable to return the output to the client 210. To avoid wasting the operational resources of the backend server 240. If the backend server 240 does not receive a response from the client 210 after a predetermined time has elapsed, the backend server 240 will respond to the load controller 230, and the load controller 230 will also discard the pen session request.

The queue processing system, apparatus and method for the network service proposed by the present invention enable the server at the back end of the client to ensure the fairness of the queue order when the client is in the queue.

While the present invention has been described above in terms of the preferred embodiments thereof, it is not intended to limit the invention, and the invention may be modified and modified without departing from the spirit and scope of the invention. The patent protection scope of the invention is subject to the definition of the scope of the patent application attached to the specification.

110‧‧‧Client

120‧‧‧Load Balancing Manager

130‧‧‧Backend server

210‧‧‧ Client

220‧‧‧Load Balancing Manager

221‧‧‧ 伫 单元 unit

230‧‧‧Load controller

231‧‧‧ first interface

232‧‧‧second interface

233‧‧‧Processing unit

240‧‧‧Backend server

511‧‧‧Client A

512‧‧‧Client B

513‧‧‧Client C

521‧‧‧Dialogue request a

522‧‧‧Dialogue request b

523‧‧‧Dialogue request c

530‧‧‧Load Balancing Manager

531‧‧‧ 伫 单元 unit

540‧‧‧Load controller

551‧‧‧First backend server

552‧‧‧Second backend server

553‧‧‧ third backend server

553‧‧‧ fourth backend server

Figure 1 is a schematic diagram of the architecture of a network service of the prior art.

Figure 2A is a schematic diagram of the network connection architecture of the present invention.

Figure 2B is a schematic diagram of the architecture of the load controller of the present invention.

Figure 3 is a schematic diagram of the operational flow of the present invention.

Figure 4A is a timing diagram of the operation of the present invention.

Figure 4B is an operational timing diagram of another embodiment of the present invention.

Figure 5A is a schematic diagram of the queue processing of the present invention.

Figure 5B is a schematic diagram of the queue processing of the present invention.

Figure 5C is a schematic diagram of the queue processing of the present invention.

Figure 5D is a schematic diagram of the queue processing of the present invention.

Figure 6 is a schematic view of the operation of another embodiment of the present invention.

Claims (10)

A queue processing system for a network service is applied to an output of a plurality of clients waiting for a network service, the queue processing system comprising: at least one backend server, the backend server sending the client A dialog requires a corresponding network service and responds to the processed output result; a load balancing manager is coupled to the client and the backend servers, and the load balancing manager receives each of the The session of the client requests and allocates the dialog request to the backend server; and a load controller is connected to the load balancing manager and the backend servers, and the load controller obtains the backend servos An operation status information of the device; wherein, when the load balancing manager detects that there is a queue identification information in the dialog request, wherein the queue identification information is a unique identification information, the load controller according to the operation status information Selecting the corresponding backend server, the load balancing manager transmitting the dialog request to the selected backend server, if the dialog request is not When the queue identifies the information, the load balancing manager forwards the received dialog request to the load controller, and the load controller adds the queue identification information to the dialog request and then returns the queue identification information to the client. End, after the client stores the queue identification information, the conversation request with the queue identification information is transferred back to the load balancing manager, and the load balancing manager adds the dialog request to a queue unit to make the conversation It is required to wait in the queue unit for allocation to the backend server. The queue processing system of the network service according to claim 1, wherein the queue identification information is determined according to a time stamp, a network address, a media access control address, or user information, and the queue identification information is small. The text file (cookies), the running status information includes processor load, memory usage, number of conversations and network response time. The queue processing system of the network service of claim 2, wherein the load controller disables the backend server according to the running status information, and notifies the load balancing manager of the disabled The server is enabled, and the load controller enables the disabled backend servers according to the running status information, and notifies the load balancing manager of the enabled backend servers. The queue processing system of the network service as claimed in claim 1, wherein the backend server notifies the load controller after completing the dialog request, and the load controller discards the current dialog request. The queue processing system of the network service according to claim 4, wherein the load balancing manager determines whether the dialog request has been discarded, and if the dialog request has been discarded, transferring the dialog request to the load controller to obtain The new queue identifies the information. A queue processing device for a network service, comprising: a first interface, which receives a dialog request of a client; and a second interface, which receives an operation status information of each backend server; a processing unit, coupled to the first interface and the second interface, the processing unit adds a queue identification information to the dialog request, the processing unit transmits the dialog request to the corresponding client, and the processing unit receives the The running status information determines whether each of the backend servers is enabled or disabled, and the processing unit transmits the enabling or disabling status of the backend servers to a load balancing manager; wherein The queue identification information is a unique identification information. The queue processing device of the network service of claim 6, wherein the processing unit enables the disabled backend servers according to the running status information, so that the enabled backend server can be The conversation request is assigned. A method for processing a queue of a network service includes the following steps: determining, by a load controller, whether each of the backend servers is enabled according to an operating state of each backend server and according to the running state Disabling; notifying a load balancing manager of each enabled or disabled state of the backend server; receiving, by the load balancing manager, a dialog request of a client; the load balancing manager determining whether the dialog request is Having a queue identification information, and the queue identification information is a unique identification information; if the conversation request has the queue identification information, the load balancing manager extracts the corresponding conversation request of the client according to the queue identification information And distributing the dialog request to the corresponding backend server according to the running status information; If the dialog request does not have the queue identification information, the dialog request is forwarded to the load controller; and after the queue identification information is added to the dialog request, the dialog request is replied to the client. The queue processing method of the network service according to claim 8, wherein after the client receives the dialog request that has joined the queue identification information, the client sends the load to the load according to the dialog request that has joined the queue identification information. The balance manager is connected. The method for processing a network service according to claim 9, wherein the backend server discards the dialog request after the session request is completed.