WO2022009415A1 - リクエスト配送装置、リクエスト配送方法、および、リクエスト配送プログラム - Google Patents

リクエスト配送装置、リクエスト配送方法、および、リクエスト配送プログラム Download PDF

Info

Publication number
WO2022009415A1
WO2022009415A1 PCT/JP2020/027012 JP2020027012W WO2022009415A1 WO 2022009415 A1 WO2022009415 A1 WO 2022009415A1 JP 2020027012 W JP2020027012 W JP 2020027012W WO 2022009415 A1 WO2022009415 A1 WO 2022009415A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
server
storage unit
completion
stored
Prior art date
Application number
PCT/JP2020/027012
Other languages
English (en)
French (fr)
Inventor
真生 上野
紀貴 堀米
健太 篠原
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2020/027012 priority Critical patent/WO2022009415A1/ja
Priority to US18/015,368 priority patent/US11968253B2/en
Priority to JP2022534868A priority patent/JP7424494B2/ja
Publication of WO2022009415A1 publication Critical patent/WO2022009415A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1014—Server selection for load balancing based on the content of a request
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests

Definitions

  • the present invention is a technology of a request delivery device, a request delivery method, and a request delivery program.
  • N-ACT Active
  • the load balancer After receiving the request from the client, the load balancer distributes the request to the registered distribution destination server to distribute the load.
  • Non-Patent Document 1 Message Queue (MQ), which handles message delivery between entities.
  • MQ Message Queue
  • FIG. 7 is a configuration diagram of a message communication system 100z using MQ.
  • the message communication system 100z has a publisher 1z, a message broker 2z, and a subscriber 3z.
  • the subscriber 3z clearly indicates to the message broker 2z the attribute (Topic) of the request that he / she wants to receive (can handle) in advance, and subscribes to the request.
  • the message broker 2z stores the subscriber 3z to be subscribed for each Topic.
  • the publisher 1z sets the Topic of the request to be transmitted by itself, and then publishes the request to the message broker 2z.
  • the message broker 2z receives the request published from the publisher 1z and delivers the request to any of the subscribers 3z who subscribe to the topic set in the request to distribute the load among the subscribers 3z. conduct.
  • N-ACT type load balancer message broker 2z in FIG. 7
  • a conventional load balancer does not detect whether or not the distribution destination server is currently in a processable state, so the request is distributed to a server that cannot process the request due to an application error or a hardware defect. There is a risk (no entrance guarantee).
  • the message broker 2z performs a periodic health check on the subscriber 3z who subscribes, and delivers the request only to the subscriber 3z who has succeeded in the health check. Further, the message broker 2z may monitor the life and death of the subscriber 3z to which the request is distributed. This makes it possible to reliably send the request to the subscriber 3z who can process the request (with guaranteed entrance). However, with the N-ACT type load balancer and MQ type message broker 2z, it cannot be guaranteed that the distributed requests have been processed normally by the server (no exit guarantee).
  • the main subject of the present invention is to provide a load balancing method that can guarantee the processing of distributed requests.
  • the request delivery device of the present invention has the following features.
  • the present invention has a request storage unit that stores requests to be sent to the server from now on.
  • a transmission unit that sends a request read from the request storage unit to the server that can process the request, and a transmission unit.
  • a receiver that receives a completion message indicating that the processing of the request is completed, and It has a completion list storage unit that stores the information of the completion message.
  • the transmission unit discards the request in which the information of the completion message is stored in the completion list storage unit without transmitting it to the server, while the information of the completion message is stored in the completion list storage unit. It is characterized in that a request that does not exist is transmitted to the server and stored again in the request storage unit.
  • FIG. 1 is a configuration diagram of a message communication system 100.
  • the message communication system 100 is configured by connecting a client 1, a load balancer (request delivery device) 2, and a server 3 via a network.
  • the server 3 subscribes to the load balancer 2 by clearly indicating the attribute (Topic) of the request that it wants to receive (handleable) in advance, as in the case of the subscriber 3z of FIG.
  • the load balancer 2 stores the IP address of the subscribing server 3 for each Topic.
  • the client 1 sets the Topic of the request to be transmitted by itself, and then publishes the request to the load balancer 2, as in the case of the publisher 1z of FIG. Then, the load balancer 2 receives the request published from the client 1 and delivers the request to any of the servers 3 subscribing to the topic set in the request to distribute the load among the servers 3. conduct. Further, unlike the publisher 1z of FIG. 7, the server 3 notifies the load balancer 2 that the processing of the request received from the load balancer 2 is completed as a completion message.
  • the load balancer 2 has a request queue (request storage unit) 21, a transmission unit 22, a completion list (completion list storage unit) 23, and a reception unit 24.
  • the request queue 21 is a temporary storage area that holds the requests received from the client 1 in the order of distribution to the server 3.
  • the transmission unit 22 fetches (pops) the first request from the request queue 21 and delivers the request to any of the servers 3 that subscribe to the topic set in the request.
  • the transmission unit 22 stores the transmitted request at the end of the request queue 21 until it is confirmed that the request has been normally processed by the server 3. (Push) to prepare for the delivery of the next request.
  • the request queue 21 and the transmission unit 22 are implemented by, for example, MQ middleware. As a result, the MQ of the load balancer 2 can be used in common by all applications that use it as middleware, so application implementation costs can be expected to be reduced.
  • the completion list 23 is a storage area for holding information on a completion message, which is a response from the server 3 to the effect that the processing of the request has been completed. It is assumed that the request information is stored in the completion message.
  • the request information allows any format in which the request can be specified, but from the viewpoint of reducing the table size held by the load balancer 2, it is desirable that the request information be hashed using MD5 (Message Digest Algorithm 5) or the like.
  • MD5 Message Digest Algorithm 5
  • FIG. 2 is a hardware configuration diagram of each device of the message communication system 100 of FIG.
  • Each device (client 1, load balancer 2, server 3) of the message communication system 100 includes a CPU 901, a RAM 902, a ROM 903, an HDD 904, a communication I / F 905, an input / output I / F 906, and a media I /. It is configured as a computer 900 with F907.
  • the communication I / F 905 is connected to an external communication device 915.
  • the input / output I / F 906 is connected to the input / output device 916.
  • the media I / F907 reads / writes data from the recording medium 917.
  • the CPU 901 controls each processing unit by executing a program (also referred to as an application or an abbreviation thereof) read into the RAM 902.
  • the program can also be distributed via a communication line, or recorded and distributed on a recording medium 917 such as a CD-ROM.
  • FIG. 3 is a flowchart showing a transmission process in the load balancer 2.
  • the transmission unit 22 pops the first request from the request queue 21.
  • the transmission unit 22 determines whether or not the popped request exists in the completion list 23. If S12 and Yes, proceed to S13, and if No, proceed to S14.
  • the transmission unit 22 confirms that the request has been completed normally, so the popped request is not transmitted and is deleted from the request queue 21.
  • the transmission unit 22 transmits the popped request to the server 3 that can process the popped request because the previously transmitted request has not been completed normally.
  • the server 3 capable of processing the request is, for example, the server 3 that has succeeded in the health check among the subscribers of the Topic of the request.
  • the transmission unit 22 adds the popped request to the end of the request queue 21. As a result, unless the processing on the server 3 is completed, the request is held in the request queue 21 in the load balancer 2, and the transmission to the server 3 is repeated.
  • the receiving unit 24 determines whether or not the completion message for the request transmitted in S14 has been received. If S21 and Yes, proceed to S22, and if No, return to S11. As S22, the receiving unit 24 determines whether or not the received completion message already exists in the completion list 23. If S22 and Yes, proceed to S23, and if No, proceed to S24. As S23, the receiving unit 24 discards the completed message received this time, and rolls back the request corresponding to the completed message to the server 3 on the transmitting side of the completed message (processing to return to the state before processing). To instruct. As S24, the receiving unit 24 adds the information of the received completion message to the completion list 23.
  • FIG. 4 is a timetable showing a case where the request is normally processed by the server 3.
  • This timetable has a first column of times that elapses toward the bottom of the table, a second column that shows the status of the request queue 21 at that time, and a third column that shows the status of request processing of the server 3. It is associated with the fourth column showing the status of the completion list 23 (the same format is used for FIGS. 5 and 6).
  • the load balancer 2 receives the following new request [M7] and stores it at the end of the request queue 21.
  • none of the requests are assigned to the server 3, and therefore none of the requests are stored in the completion list 23.
  • the transmission unit 22 transmits some requests including the request [M1] to the server 3. Then, the receiving unit 24 receives some completion messages (here, [M1], ..., [M4]) from the server 3 and registers them in the completion list 23. Then, the transmission unit 22 reads the request [M7] to be processed next from the beginning of the request queue 21 (S11). Then, the transmission unit 22 confirms that the read request [M7] does not yet exist in the completion list 23 (S12, No). As this confirmation method, for example, when the MD5 hash value calculated from the request [M7] does not match the MD5 hash value of any entry in the completion list 23, there is a method of determining that the MD5 hash value does not exist yet.
  • the transmission unit 22 sends a request [M7] to the server 3 (here, SA) that subscribes to topic: "aaa” (S14), and requests the request [M7] from the request queue 21. Return to the end (S15). Then, the receiving unit 24 receives the following completion message [M7] from the server 3 that has normally processed the request [M7] (S21, Yes). topic: "bbb” message: “I'm fine.” processed_message: "ee82180acb899fc9c6ddfbb9cc89d20d" The server 3 stores the MD5 hash value of the request [M7] in the processed_message field. The receiving unit 24 adds the MD5 hash value of this request [M7] to the completion list 23 (S22, No ⁇ S24).
  • the request identifier described in the processed_message field is an MD5 hash value, but the description format does not matter as long as the processed request can be specified.
  • the following is an example in which the request indicated by topic: "aaa” (lines 4 and 5 below) is described in the completion message indicated by topic: “bbb” (lines 1 to 3 below) without hashing. be. topic: “bbb” message: “I'm fine.”
  • the server 3 may add information such as a time stamp that can uniquely identify the request to the completion message.
  • the server 3 assigns a time stamp to the request and describes the request without hashing, the processing status of the request in the message communication system 100 can be monitored, and the effect in terms of maintenance and operation can be obtained. Therefore, the client 1 (or a management terminal (not shown) receives a completion message including a request described without hashing from the server 3 or the load balancer 2 and displays it on its own display screen.
  • the request [M7] added to the end at time t13 reaches the beginning of the request queue 21 again.
  • the transmission unit 22 confirms that the read request [M7] exists in the completion list 23 (S12, Yes).
  • the transmission unit 22 deletes the request [M7] at the head of the request queue 21 without transmitting it to the server 3 (S13).
  • the entry of [M7] may be deleted from the completion list 23 immediately, or may be deleted after waiting for a predetermined time. It may be retained permanently without being deleted.
  • FIG. 5 is a timetable showing a case where a request is not processed due to a failure of the server 3. Since the times t11 and t12 are the same as those in FIG. 4, the description thereof will be omitted.
  • the transmission unit 22 sends a request [M7] to the server 3 (here, SA) that subscribes to topic: "aaa” (S14), and the request [M7]. Is returned to the end of the request queue 21 (S15).
  • SA server 3
  • the execution fails at the time t21 due to the failure of the server 3 (SA). That is, since the request [M7] is lost in the server 3 (SA), the receiver 24 that cannot receive the completion message of the request [M7] cannot add the request [M7] to the completion list 23.
  • the request [M7] added to the end at time t21 reaches the beginning of the request queue 21 again.
  • the transmission unit 22 confirms that the read request [M7] does not yet exist in the completion list 23 (S12, No).
  • the transmitter 22 sends a request [M7] to a server 3 (here, SB) different from the previous destination to subscribe to topic: "aaa” (S14), and the request is made. [M7] is returned to the end of the request queue 21 (S15).
  • the receiving unit 24 receives the following completion message [M7] from the server 3 (SB) that has normally processed the request [M7] (S21, Yes).
  • the receiving unit 24 adds the MD5 hash value of this request [M7] to the completion list 23 (S22, No ⁇ S24).
  • the first transmission to the server 3 (SA) at time t21 and the second transmission to the server 3 (SB) at time t23 were explained in order. If the number of requests held in the request queue 21 is small, the transmitted request immediately returns to the top of the request queue 21. Therefore, a large number of messages are sent in a very short time, and the system load may become excessive.
  • the transmission unit 22 may perform backoff control so that the message once transmitted is not retransmitted for a predetermined period (so that the transmission interval is not too short).
  • the transmission unit 22 can wait for the timing of the current transmission from the previous transmission time to a predetermined period after the previous transmission time is added to the message as a time stamp. The message may be returned to the end of the request queue 21 at the meeting time.
  • the transmission unit 22 confirms that the read request [M7] exists in the completion list 23 (S12, Yes). At time t25, the transmission unit 22 deletes the request [M7] at the head of the request queue 21 without transmitting it to the server 3 (S13).
  • FIG. 6 is a timetable showing a case where a processing delay occurs in the server 3.
  • the times t11 and t12 are the same as in FIG.
  • the time t21B in FIG. 6 is replaced with the time t21 in FIG.
  • the request [M7] was permanently lost due to a failure of server 3 (SA), but at time t21B, the processing of server 3 (SA) was delayed, and the timing of execution completion was considerably delayed (time described later). t26). Therefore, since the processing is not completed at the time t21B (S21, No), the receiving unit 24 cannot add the request [M7] to the completion list 23 at this time.
  • Times t22 to t25 are the same as in Fig. 5. That is, when the server 3 (SB) that transmits the request [M7] for the second time at time t23 succeeds in the process, the receiving unit 24 can add the MD5 hash value of the request [M7] to the completion list 23.
  • the load balancer 2 notifies the server 3 (SA) that the processing of [M7] has already been completed by another server 3 (SB), so that the server 3 (SA) is duplicated.
  • the load balancer 2 of the present invention is The request queue 21 that stores the requests to be sent to the server 3 from now on, A transmission unit 22 that sends a request read from the request queue 21 to a server 3 that can process the request, and A receiver 24 that receives a completion message indicating that the processing of the request has been completed, and It has a completion list 23 in which a completion message is stored, and has a completion list 23.
  • the transmission unit 22 discards the request whose completion message is stored in the completion list 23 without sending it to the server 3, while transmitting the request whose completion message is not stored in the completion list 23 to the server 3. It is characterized in that it is stored in the request queue 21 again.
  • the completion message of the request read from the request queue 21 is the completion list. It is characterized in that it is determined that it is stored in 23.
  • the present invention is characterized in that the transmission unit 22 deletes the completion message from the completion list 23 after discarding the request whose completion message is stored in the completion list 23 without transmitting it to the server 3.
  • the present invention is characterized in that, when the transmission unit 22 reads a predetermined request from the request queue 21 a plurality of times, the transmission unit 22 transmits the predetermined request to the server 3 which has not previously transmitted the predetermined request.
  • the present invention is characterized in that when the transmission unit 22 reads a predetermined request from the request queue 21 a plurality of times, the back-off control is performed so that the timing of transmitting the predetermined request is set a predetermined period from the previous transmission time. ..
  • the receiving unit 24 when the receiving unit 24 receives the completion message of the same request from the second server 3 for the request for which the completion message from the first server 3 is already stored in the completion list 23, the completion message is the same.
  • the second server 3 is instructed to roll back the request.
  • Client 2 Load balancer (request delivery device) 3 Server 21 Request queue (request storage unit) 22 Transmitter 23 Completion list (completion list storage) 24 Receiver 100 Message communication system

Landscapes

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

Abstract

ロードバランサ（２）は、これからサーバ（３）に送信する予定のリクエストが格納される要求キュー（２１）と、要求キュー（２１）から読み取ったリクエストを処理可能なサーバ（３）に送信する送信部（２２）と、リクエストの処理が完了したことを示す完了メッセージを受信する受信部（２４）と、完了メッセージが格納される完了リスト（２３）とを有しており、送信部（２２）が、完了メッセージが完了リスト（２３）に格納されているリクエストについてはサーバ（３）に送信せずに廃棄する一方、完了メッセージが完了リスト（２３）に格納されていないリクエストについてはサーバ（３）に送信するとともに要求キュー（２１）に再び格納する。

Description

リクエスト配送装置、リクエスト配送方法、および、リクエスト配送プログラム
　本発明は、リクエスト配送装置、リクエスト配送方法、および、リクエスト配送プログラムの技術である。
　サーバ・クライアント型システムにおいて、同一機能を有する複数のサーバに対しリクエストを振り分けるN-ACT（Active）と呼ばれる方式が従来から知られている。従来のN-ACT型のシステムにおいては、事前にロードバランサと呼ばれる振り分け機能に対して、予めIPアドレスなどの振り分け先サーバの情報を登録する。ロードバランサはクライアントからのリクエストを受信した後、登録された振り分け先サーバに対してリクエストを振り分けることで、負荷分散を行う。
　また、近年ではメッセージキュー（MQ：Message Queue）と呼ばれるエンティティ間のメッセージ配送を担うミドルウェアの機能を用いて、サーバにメッセージを振り分け、負荷分散を実現する方式が存在する（非特許文献１）。
　図７は、MQを用いたメッセージ通信システム１００ｚの構成図である。
　メッセージ通信システム１００ｚは、パブリッシャ１ｚと、メッセージブローカ２ｚと、サブスクライバ３ｚとを有する。
　まず、サブスクライバ３ｚは、メッセージブローカ２ｚに対し、予め自身が受信したい（対処可能な）リクエストの属性（Topic）を明示して、リクエストを購読（Subscribe）する。メッセージブローカ２ｚは、購読するサブスクライバ３ｚをTopicごとに記憶する。
　次に、パブリッシャ１ｚは、自身が送信するリクエストのTopicを設定した上で、メッセージブローカ２ｚに対してリクエストを発行（Publish）する。
　そして、メッセージブローカ２ｚは、パブリッシャ１ｚからPublishされたリクエストを受け、そのリクエストに設定されたtopicを購読しているサブスクライバ３ｚのいずれかに対し、リクエストを配送することでサブスクライバ３ｚ間の負荷分散を行う。
NATS Docs、「The Importance of Messaging」、［online］、［2020年7月2日検索］、インターネット〈URL：https://docs.nats.io/〉
　従来の負荷分散方式では、仲介者（N-ACT型のロードバランサ、図７のメッセージブローカ２ｚ）がサーバにリクエストを振り分けるという簡単な機能だけが提供されているが、振り分けられたリクエストがサーバで正常に処理されたことを保証するまでには至っていない。
　例えば、従来のロードバランサは、振り分け先のサーバが現在処理可能な状態か否かを感知しないため、アプリケーションエラーやハードウェア不具合などでリクエストを処理できない状態にあるサーバに対し、リクエストを振り分けてしまう恐れがある（入口保証なし）。
　また、MQを用いたメッセージ通信システム１００ｚでは、メッセージブローカ２ｚは、購読しているサブスクライバ３ｚに対し定期的なヘルスチェックを行い、ヘルスチェックに成功したサブスクライバ３ｚへのみリクエストを配送する。さらに、メッセージブローカ２ｚは、リクエストの振り分け先のサブスクライバ３ｚの死活監視を行うこともある。これにより、リクエストを処理可能なサブスクライバ３ｚに対して確実にリクエストを送信できる（入口保証あり）。
　しかし、N-ACT型のロードバランサやMQ方式のメッセージブローカ２ｚでは、振り分けられたリクエストがサーバで正常に処理されたことを保証できない（出口保証なし）。
　そこで、本発明は、振り分けたリクエストの処理を保証できる負荷分散方式を提供することを主な課題とする。
　前記課題を解決するために、本発明のリクエスト配送装置は、以下の特徴を有する。
　本発明は、これからサーバに送信する予定のリクエストが格納される要求格納部と、
　前記要求格納部から読み取ったリクエストを処理可能な前記サーバに送信する送信部と、
　リクエストの処理が完了したことを示す完了メッセージを受信する受信部と、
　前記完了メッセージの情報が格納される完了リスト格納部とを有しており、
　前記送信部が、前記完了メッセージの情報が前記完了リスト格納部に格納されているリクエストについては前記サーバに送信せずに廃棄する一方、前記完了メッセージの情報が前記完了リスト格納部に格納されていないリクエストについては前記サーバに送信するとともに前記要求格納部に再び格納することを特徴とする。
　本発明によれば、振り分けたリクエストの処理を保証できる負荷分散方式を提供することができる。
本実施形態に係わるメッセージ通信システムの構成図である。 本実施形態に係わる図１のメッセージ通信システムの各装置のハードウェア構成図である。 本実施形態に係わるロードバランサでの送信処理を示すフローチャートである。 本実施形態に係わるサーバで正常にリクエストが処理される場合を示すタイムテーブルである。 本実施形態に係わるサーバの障害によってリクエストが処理されない場合を示すタイムテーブルである。 本実施形態に係わるサーバで処理の遅延が発生する場合を示すタイムテーブルである。 MQを用いたメッセージ通信システムの構成図である。
　以下、本発明の一実施形態について、図面を参照して詳細に説明する。
　図１は、メッセージ通信システム１００の構成図である。
　メッセージ通信システム１００は、クライアント１と、ロードバランサ（リクエスト配送装置）２と、サーバ３とがネットワークで接続されて構成される。
　まず、サーバ３は、図７のサブスクライバ３ｚと同様に、ロードバランサ２に対し、予め自身が受信したい（対処可能な）リクエストの属性（Topic）を明示して、リクエストを購読（Subscribe）する。ロードバランサ２は、図７のメッセージブローカ２ｚと同様に、購読するサーバ３のIPアドレスをTopicごとに記憶する。
　次に、クライアント１は、図７のパブリッシャ１ｚと同様に、自身が送信するリクエストのTopicを設定した上で、ロードバランサ２に対してリクエストを発行（Publish）する。
　そして、ロードバランサ２は、クライアント１からPublishされたリクエストを受け、そのリクエストに設定されたtopicを購読しているサーバ３のいずれかに対し、リクエストを配送することでサーバ３間の負荷分散を行う。
　さらに、図７のパブリッシャ１ｚとは違い、サーバ３はロードバランサ２から受信したリクエストの処理が完了したことをロードバランサ２へ完了メッセージとして通知する。
　ロードバランサ２は、要求キュー（要求格納部）２１と、送信部２２と、完了リスト（完了リスト格納部）２３と、受信部２４とを有する。
　要求キュー２１は、クライアント１から受信したリクエストを、これからサーバ３に振り分ける順に保持する一時的な格納領域である。
　送信部２２は、要求キュー２１から先頭のリクエストを取り出し（popし）、そのリクエストに設定されたtopicを購読しているサーバ３のいずれかに対し、リクエストを配送する。ここで、送信部２２は、サーバ３に１回送信したリクエストであっても、そのリクエストをサーバ３が正常に処理したことを確認するまでは、送信したリクエストを要求キュー２１の末尾に格納し（pushし）、次回のリクエストの配送に備える。
　要求キュー２１と、送信部２２とは、例えば、MQのミドルウェアにより実装される。これにより、ロードバランサ２のMQをミドルウェアとして使用するすべてのアプリケーションで共通して利用可能なため、アプリケーションの実装コスト削減が期待できる。
　完了リスト２３は、リクエストの処理を完了した旨のサーバ３からの応答である完了メッセージの情報を保持する格納領域である。なお、完了メッセージ内には、リクエストの情報が格納されるものとする。リクエストの情報は、リクエストが特定できる任意の形式を許容するが、ロードバランサ２が保持するテーブルサイズ縮小の観点から、MD5（Message Digest Algorithm 5）等を用いてハッシュ化されることが望ましい。
　受信部２４は、完了メッセージをサーバ３から受け取った際、その完了メッセージに格納されているリクエストの情報を読み出し、完了リスト２３に格納する。
　図２は、図１のメッセージ通信システム１００の各装置のハードウェア構成図である。
　メッセージ通信システム１００の各装置（クライアント１と、ロードバランサ２と、サーバ３）は、ＣＰＵ９０１と、ＲＡＭ９０２と、ＲＯＭ９０３と、ＨＤＤ９０４と、通信Ｉ／Ｆ９０５と、入出力Ｉ／Ｆ９０６と、メディアＩ／Ｆ９０７とを有するコンピュータ９００として構成される。
　通信Ｉ／Ｆ９０５は、外部の通信装置９１５と接続される。入出力Ｉ／Ｆ９０６は、入出力装置９１６と接続される。メディアＩ／Ｆ９０７は、記録媒体９１７からデータを読み書きする。さらに、ＣＰＵ９０１は、ＲＡＭ９０２に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部を制御する。そして、このプログラムは、通信回線を介して配布したり、ＣＤ－ＲＯＭ等の記録媒体９１７に記録して配布したりすることも可能である。
　図３は、ロードバランサ２での送信処理を示すフローチャートである。
　Ｓ１１として、送信部２２は、要求キュー２１から先頭のリクエストをpopする。Ｓ１２として、送信部２２は、popしたリクエストが完了リスト２３に存在するか否かを判定する。Ｓ１２,YesならＳ１３に進み、NoならＳ１４に進む。
　Ｓ１３として、送信部２２は、リクエストの正常完了を確認したので、popしたリクエストを送信せず、要求キュー２１から削除する。
　Ｓ１４として、送信部２２は、前回送信したリクエストがまだ正常完了されていないので、popしたリクエストを処理可能なサーバ３に送信する。リクエストを処理可能なサーバ３とは、例えば、リクエストのTopicの購読者のうちヘルスチェックに成功したサーバ３である。
　ここで、送信部２２は、今回送信するリクエストを、前回以前に送信済みのサーバ３とは別のサーバ３に送信することが望ましい。
　Ｓ１５として、送信部２２は、popしたリクエストを要求キュー２１の末尾に追加する。これにより、サーバ３での処理が完了しない限り、リクエストはロードバランサ２内の要求キュー２１に保持され、サーバ３への送信を繰り返す。
　Ｓ２１として、受信部２４は、Ｓ１４で送信したリクエストへの完了メッセージを受信したか否かを判定する。Ｓ２１,YesならＳ２２に進み、NoならＳ１１に戻る。
　Ｓ２２として、受信部２４は、受信した完了メッセージがすでに完了リスト２３に存在するか否かを判定する。Ｓ２２,YesならＳ２３に進み、NoならＳ２４に進む。
　Ｓ２３として、受信部２４は、今回受信した完了メッセージは破棄し、その完了メッセージの送信側のサーバ３に対して、完了メッセージに対応するリクエストのロールバック（処理を行う前の状態に戻す処理）を指示する。
　Ｓ２４として、受信部２４は、受信した完了メッセージの情報を完了リスト２３に追加する。
　以上、図１～図３を参照して、メッセージ通信システム１００の概要を説明した。以下は、適宜図３の各ステップ（Ｓ１１～Ｓ２４）を参照して、以下の３つのケースの処理を説明する。
　・［ケース１］サーバ３で正常にリクエストが処理される場合（図４の説明）。
　・［ケース２］サーバ３の障害によってリクエストが処理されない場合（図５の説明）。
　・［ケース３］サーバ３で処理の遅延が発生する場合（図６の説明）。
　図４は、サーバ３で正常にリクエストが処理される場合を示すタイムテーブルである。
　このタイムテーブルは、テーブルの下にいくほど経過する時刻の第１列と、その時刻での要求キュー２１の状態を示す第２列と、サーバ３のリクエスト処理の状態を示す第３列と、完了リスト２３の状態を示す第４列とを対応づける（図５，図６も同じ形式）。
　なお、図４～図６において、[M1],[M2]のようにカッコ付きのMi(i=1,2,…)という識別子で個々のリクエストを示す。iが小さいほど早くロードバランサ２に到着したリクエストである。そして、以下では[M7]のリクエストに着目して説明する。
　時刻t11では、ロードバランサ２は、以下の新たなリクエスト[M7]を受信し、要求キュー２１の末尾に格納する。
　topic:"aaa"
　message:"Hello,how are you?"
　よって、第２列の要求キュー２１には先頭の[M1]から末尾の[M7]まで各リクエストが順に格納されている。ここでは、どのリクエストもサーバ３に割り当てられておらず、よって、どのリクエストも完了リスト２３には格納されていない。
　時刻t12では、送信部２２は、リクエスト[M1]を含めていくつかのリクエストをサーバ３に送信する。そして、受信部２４は、いくつかの完了メッセージ（ここでは[M1]、…、[M4]）をサーバ３から受信し、完了リスト２３に登録する。そして、送信部２２は、次に処理をするリクエスト[M7]を要求キュー２１の先頭から読み取る（Ｓ１１）。
　そして、送信部２２は、読み取ったリクエスト[M7]が完了リスト２３にはまだ存在しないことを確認する（Ｓ１２,No）。この確認方法は、例えば、リクエスト[M7]から計算したMD5ハッシュ値が、完了リスト２３内のどのエントリのMD5ハッシュ値とも一致しないときに、まだ存在しないと判定する方法がある。
　時刻t13では、送信部２２は、topic:"aaa"を購読するサーバ３（ここではSAとする）に対してリクエスト[M7]を送信し（Ｓ１４）、そのリクエスト[M7]を要求キュー２１の末尾に戻す（Ｓ１５）。そして、受信部２４は、リクエスト[M7]を正常に処理したサーバ３から、以下の完了メッセージ[M7]を受信する（Ｓ２１,Yes）。
　topic:"bbb"
　message:"I'm fine."
　processed_message:"ee82180acb899fc9c6ddfbb9cc89d20d"
　サーバ３は、processed_messageフィールドに、リクエスト[M7]のMD5ハッシュ値を格納しておく。受信部２４は、このリクエスト[M7]のMD5ハッシュ値を、完了リスト２３に追加する（Ｓ２２,No→Ｓ２４）。
　なお、processed_messageフィールドに記述するリクエスト識別子をMD5ハッシュ値としているが、処理したリクエストを特定できる形式ならば、記述形式は問わない。以下は、topic:"bbb"で示す完了メッセージ（下記の１～３行目）に、topic:"aaa"で示すリクエスト（下記の４，５行目）をハッシュ化せずに記述した例である。
　topic:"bbb"
　message:"I'm fine."
　processed_message:
　　topic:"aaa"
　　message:"Hello,how are you?"
　また、前記のハッシュ化せずに記述した例では、topicとリクエスト内容が同じであれば、実際には異なるリクエストであっても同一のものだと認識される。これを避けるため、サーバ３は、タイムスタンプなどのリクエストを一意に特定できる情報を、完了メッセージに付加してもよい。
　サーバ３がタイムスタンプをリクエストに付与し、かつリクエストをハッシュ化せずに記述することで、メッセージ通信システム１００内でのリクエストの処理状況をモニタリングでき、保守運用面での効果も得られる。そのため、クライアント１（または図示しない管理用端末）は、ハッシュ化せずに記述されたリクエストを含む完了メッセージをサーバ３またはロードバランサ２から受信し、自身の表示画面に表示する。
　時刻t14では、時刻t13で末尾に追加されたリクエスト[M7]が再度要求キュー２１の先頭に到達する。送信部２２は、読み取ったリクエスト[M7]が完了リスト２３に存在することを確認する（Ｓ１２,Yes）。
　時刻t15では、送信部２２は、要求キュー２１の先頭のリクエスト[M7]を、サーバ３へ送信せずに削除する（Ｓ１３）。ここで、送信部２２は、リクエスト[M7]が正常に処理したことを確認できたので、[M7]のエントリを完了リスト２３からすぐに削除してもよいし、所定時間だけ待ってから削除してもよいし、削除せずに永続的に保有してもよい。
　完了リスト２３から正常にリクエストを廃棄したエントリを削除することで、ロードバランサ２自身が消費するメモリリソースを制約できる。
　図５は、サーバ３の障害によってリクエストが処理されない場合を示すタイムテーブルである。
　時刻t11,t12は図４と同じなので、説明を省略する。
　時刻t21では時刻t13と同様に、送信部２２は、topic:"aaa"を購読するサーバ３（ここではSAとする）に対してリクエスト[M7]を送信し（Ｓ１４）、そのリクエスト[M7]を要求キュー２１の末尾に戻す（Ｓ１５）。
　しかし、時刻t13とは異なり、時刻t21ではサーバ３（SA）の障害により、実行に失敗したとする。つまり、リクエスト[M7]がサーバ３（SA）内で失われてしまうので、リクエスト[M7]の完了メッセージを受け取れない受信部２４は、完了リスト２３にリクエスト[M7]を追加できない。
　時刻t22では、時刻t21で末尾に追加されたリクエスト[M7]が再度要求キュー２１の先頭に到達する。送信部２２は、読み取ったリクエスト[M7]が完了リスト２３にはまだ存在しないことを確認する（Ｓ１２,No）。
　時刻t23では、送信部２２は、topic:"aaa"を購読する前回の送信先とは別のサーバ３（ここではSBとする）に対してリクエスト[M7]を送信し（Ｓ１４）、そのリクエスト[M7]を要求キュー２１の末尾に戻す（Ｓ１５）。
　受信部２４は、リクエスト[M7]を正常に処理したサーバ３（SB）から、以下の完了メッセージ[M7]を受信する（Ｓ２１,Yes）。
　topic:"bbb"
　message:"I'm fine."
　processed_message:"ee82180acb899fc9c6ddfbb9cc89d20d"
　受信部２４は、このリクエスト[M7]のMD5ハッシュ値を、完了リスト２３に追加する（Ｓ２２,No→Ｓ２４）。
　なお、リクエストの送信処理について、時刻t21での１回目のサーバ３（SA）への送信と、時刻t23での２回目のサーバ３（SB）への送信とを順に説明した。なお、要求キュー２１内に保持されるリクエスト数が少ない場合、送信されたリクエストがすぐに要求キュー２１の先頭に戻る。そのため、ごく短い時間に大量のメッセージ送信が発生してしまい、システム負荷が過剰になってしまうこともある。
　そこで、送信部２２は、一度送信されたメッセージは、所定期間は再送信されないように（送信間隔が短くなりすぎないように）バックオフ制御を行ってもよい。バックオフ制御を行う場合、送信部２２は、前回の送信時刻をタイムスタンプとしてメッセージに付加することで、前回の送信時刻から所定期間後まで今回の送信のタイミングを待ちあわせることができる。なお、待ち合わせの時間に、要求キュー２１の末尾にそのメッセージを戻してもよい。
　時刻t24では、時刻t23で末尾に追加されたリクエスト[M7]が再度要求キュー２１の先頭に到達する。送信部２２は、読み取ったリクエスト[M7]が完了リスト２３に存在することを確認する（Ｓ１２,Yes）。
　時刻t25では、送信部２２は、要求キュー２１の先頭のリクエスト[M7]を、サーバ３へ送信せずに削除する（Ｓ１３）。
　図６は、サーバ３で処理の遅延が発生する場合を示すタイムテーブルである。
　時刻t11,t12は図４と同じである。
　図６の時刻t21Bは、図５の時刻t21から置き換わる。時刻t21ではサーバ３（SA）の障害によりリクエスト[M7]が永続的に失われたが、時刻t21Bではサーバ３（SA）の処理が遅延し、実行完了のタイミングがかなり遅くなる（後記の時刻t26）。よって、時刻t21Bの時点では処理が完了しないので（Ｓ２１,No）、受信部２４は、現時点で完了リスト２３にリクエスト[M7]を追加できない。
　時刻t22～t25は図５と同じである。つまり、時刻t23でリクエスト[M7]を２回目に送信したサーバ３（SB）が処理を成功させることで、受信部２４はリクエスト[M7]のMD5ハッシュ値を、完了リスト２３に追加できる。
　時刻t26では、サーバ３(SA)からの以下の[M7]の完了メッセージが遅延してロードバランサ２に届く（Ｓ２１,Yes）。
　topic:"bbb"
　message:"Not bad."
　processed_message:"ee82180acb899fc9c6ddfbb9cc89d20d"
　しかし、時刻t23で、完了リスト２３内にリクエスト[M7]のハッシュ値がすでに格納されているため（Ｓ２２,Yes）、送信部２２はサーバ３(SA)からの[M7]の完了メッセージを破棄する（Ｓ２３）。
　時刻t27では、ロードバランサ２は、既に別のサーバ３(SB)によって[M7]の処理が完了している旨を、サーバ３(SA)に通知することで、サーバ３(SA)が重複して実行してしまった[M7]の処理のロールバック（RB:Roll Back）処理（取り消し）を促す。
［効果］
　本発明のロードバランサ２は、
　これからサーバ３に送信する予定のリクエストが格納される要求キュー２１と、
　要求キュー２１から読み取ったリクエストを処理可能なサーバ３に送信する送信部２２と、
　リクエストの処理が完了したことを示す完了メッセージを受信する受信部２４と、
　完了メッセージが格納される完了リスト２３とを有しており、
　送信部２２が、完了メッセージが完了リスト２３に格納されているリクエストについてはサーバ３に送信せずに廃棄する一方、完了メッセージが完了リスト２３に格納されていないリクエストについてはサーバ３に送信するとともに要求キュー２１に再び格納することを特徴とする。
　これにより、リクエストを送信した後のサーバ３でのリクエスト処理が確実に完了したことを保証できる。
　本発明は、送信部２２が、読み取ったリクエストのハッシュ値が、完了リスト２３に格納されているハッシュ値のリストに含まれているときに、要求キュー２１から読み取ったリクエストの完了メッセージが完了リスト２３に格納されていると判定することを特徴とする。
　これにより、リクエストをハッシュ化して記述することで、メッセージ完了リスト内に保持されるエントリ毎のデータサイズを縮小できる。よって、システムを構築する際に要するメモリ量などを節約でき、よりコンパクトな環境でも本システムを稼働できる。
　本発明は、送信部２２が、完了メッセージが完了リスト２３に格納されているリクエストについてはサーバ３に送信せずに廃棄した後に、完了リスト２３から完了メッセージを削除することを特徴とする。
　これにより、消費するメモリリソースを制約できる。
　本発明は、送信部２２が、要求キュー２１から所定のリクエストを複数回読み取った場合、その所定のリクエストを以前送信していないサーバ３に送信することを特徴とする。
　これにより、障害中や処理遅延中などのリクエストの正常処理の見込みが薄いサーバ３に、リクエストを再送しなくて済む。
　本発明は、送信部２２が、要求キュー２１から所定のリクエストを複数回読み取った場合、その所定のリクエストを送信するタイミングを前回の送信時刻から所定期間空けるバックオフ制御を行うことを特徴とする。
　これにより、同じリクエストが短期間で送信され続けるような過剰な負荷を抑制できる。
　本発明は、受信部２４が、すでに第１のサーバ３からの完了メッセージが完了リスト２３に格納されているリクエストについて、同じリクエストの完了メッセージを第２のサーバ３から受信した場合には、その第２のサーバ３に対してリクエストのロールバックを指示することを特徴とする。
　これにより、同じリクエストが複数のサーバ３で実行されている場合でも、クライアント１・サーバ３間での不整合の発生を軽減できる。
　１　　　クライアント
　２　　　ロードバランサ（リクエスト配送装置）
　３　　　サーバ
　２１　　要求キュー（要求格納部）
　２２　　送信部
　２３　　完了リスト（完了リスト格納部）
　２４　　受信部
　１００　メッセージ通信システム

Claims (8)

  1. 　これからサーバに送信する予定のリクエストが格納される要求格納部と、
    　前記要求格納部から読み取ったリクエストを処理可能な前記サーバに送信する送信部と、
    　リクエストの処理が完了したことを示す完了メッセージを受信する受信部と、
    　前記完了メッセージの情報が格納される完了リスト格納部とを有しており、
    　前記送信部は、前記完了メッセージの情報が前記完了リスト格納部に格納されているリクエストについては前記サーバに送信せずに廃棄する一方、前記完了メッセージの情報が前記完了リスト格納部に格納されていないリクエストについては前記サーバに送信するとともに前記要求格納部に再び格納することを特徴とする
    　リクエスト配送装置。
  2. 　前記送信部は、読み取ったリクエストのハッシュ値が、前記完了リスト格納部に格納されているハッシュ値のリストに含まれているときに、要求格納部から読み取ったリクエストの前記完了メッセージの情報が前記完了リスト格納部に格納されていると判定することを特徴とする
    　請求項１に記載のリクエスト配送装置。
  3. 　前記送信部は、前記完了メッセージの情報が前記完了リスト格納部に格納されているリクエストについてはサーバに送信せずに廃棄した後に、前記完了リスト格納部から前記完了メッセージの情報を削除することを特徴とする
    　請求項１に記載のリクエスト配送装置。
  4. 　前記送信部は、前記要求格納部から所定のリクエストを複数回読み取った場合、その所定のリクエストを以前送信していないサーバに送信することを特徴とする
    　請求項１に記載のリクエスト配送装置。
  5. 　前記送信部は、前記要求格納部から所定のリクエストを複数回読み取った場合、その所定のリクエストを送信するタイミングを前回の送信時刻から所定期間空けるバックオフ制御を行うことを特徴とする
    　請求項１に記載のリクエスト配送装置。
  6. 　前記受信部は、すでに第１のサーバからの前記完了メッセージの情報が前記完了リスト格納部に格納されているリクエストについて、同じリクエストの前記完了メッセージを第２のサーバから受信した場合には、その第２のサーバに対してリクエストのロールバックを指示することを特徴とする
    　請求項１に記載のリクエスト配送装置。
  7. 　リクエスト配送装置は、要求格納部と、送信部と、受信部と、完了リスト格納部とを有しており、
    　前記要求格納部には、これからサーバに送信する予定のリクエストが格納されており、
    　前記送信部は、前記要求格納部から読み取ったリクエストを処理可能な前記サーバに送信し、
    　前記受信部は、リクエストの処理が完了したことを示す完了メッセージを受信し、
    　前記完了リスト格納部には、前記完了メッセージの情報が格納されており、
    　前記送信部は、前記完了メッセージの情報が前記完了リスト格納部に格納されているリクエストについては前記サーバに送信せずに廃棄する一方、前記完了メッセージの情報が前記完了リスト格納部に格納されていないリクエストについては前記サーバに送信するとともに前記要求格納部に再び格納することを特徴とする
    　リクエスト配送方法。
  8. 　コンピュータを、請求項１ないし請求項６のいずれか１項に記載のリクエスト配送装置として機能させるためのリクエスト配送プログラム。
PCT/JP2020/027012 2020-07-10 2020-07-10 リクエスト配送装置、リクエスト配送方法、および、リクエスト配送プログラム WO2022009415A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2020/027012 WO2022009415A1 (ja) 2020-07-10 2020-07-10 リクエスト配送装置、リクエスト配送方法、および、リクエスト配送プログラム
US18/015,368 US11968253B2 (en) 2020-07-10 2020-07-10 Request delivery device, request delivery method, and request delivery program
JP2022534868A JP7424494B2 (ja) 2020-07-10 2020-07-10 リクエスト配送装置、リクエスト配送方法、および、リクエスト配送プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/027012 WO2022009415A1 (ja) 2020-07-10 2020-07-10 リクエスト配送装置、リクエスト配送方法、および、リクエスト配送プログラム

Publications (1)

Publication Number Publication Date
WO2022009415A1 true WO2022009415A1 (ja) 2022-01-13

Family

ID=79552389

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/027012 WO2022009415A1 (ja) 2020-07-10 2020-07-10 リクエスト配送装置、リクエスト配送方法、および、リクエスト配送プログラム

Country Status (3)

Country Link
US (1) US11968253B2 (ja)
JP (1) JP7424494B2 (ja)
WO (1) WO2022009415A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005293147A (ja) * 2004-03-31 2005-10-20 Nec Corp データ保存システムおよび該システムの制御方法
JP2005354475A (ja) * 2004-06-11 2005-12-22 Mitsubishi Electric Corp 電子制御装置
JP2018157466A (ja) * 2017-03-21 2018-10-04 日本電気株式会社 電文送受信システム、電文送信装置、電文受信装置、電文送受信方法およびプログラム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112010005499T5 (de) * 2010-04-19 2013-03-28 International Business Machines Corp. Steuern der Nachrichtenübermittlung beim Publish/Subscribe-Nachrichtenaustausch
US9654571B2 (en) * 2014-01-21 2017-05-16 Time Warner Cable Enterprises Llc Publish-subscribe messaging in a content network
US10853153B2 (en) * 2017-04-24 2020-12-01 Telefonaktiebolaget Lm Ericsson (Publ) Message queue performance monitoring
US11888952B2 (en) * 2019-12-10 2024-01-30 VMware LLC Topic-based data routing in a publish-subscribe messaging environment

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005293147A (ja) * 2004-03-31 2005-10-20 Nec Corp データ保存システムおよび該システムの制御方法
JP2005354475A (ja) * 2004-06-11 2005-12-22 Mitsubishi Electric Corp 電子制御装置
JP2018157466A (ja) * 2017-03-21 2018-10-04 日本電気株式会社 電文送受信システム、電文送信装置、電文受信装置、電文送受信方法およびプログラム

Also Published As

Publication number Publication date
US20230319134A1 (en) 2023-10-05
US11968253B2 (en) 2024-04-23
JP7424494B2 (ja) 2024-01-30
JPWO2022009415A1 (ja) 2022-01-13

Similar Documents

Publication Publication Date Title
AU2019201592B2 (en) Exactly-once transaction semantics for fault tolerant FPGA based transaction systems
US7979563B2 (en) Method and system for dynamic client/server network management using proxy servers
US20210176310A1 (en) Data synchronization method and system
US8892768B2 (en) Load balancing apparatus and load balancing method
US10069642B2 (en) Method of autonomic representative selection in local area networks
US8543692B2 (en) Network system
JP2006031063A (ja) 優先制御装置
US20080310423A1 (en) Synchronization of Message Stream in a Multi-tier Messaging System
US9609031B1 (en) Propagating state information to network nodes
JP2018508072A (ja) メッセージをプッシュするための方法および装置
US20150039676A1 (en) Messaging api over http protocol to establish context for data exchange
CN109151056B (zh) 基于Canal的消息推送方法和***
JP2005521945A (ja) 共通作業キュー環境における最適格サーバ
CN110650097B (zh) 一种数据传播方法、装置以及计算机可读存储介质
WO2024109810A1 (zh) 虚拟桌面性能探测方法、装置、设备及存储介质和程序
WO2024074091A1 (zh) 一种sip动态负载均衡方法、***、设备和存储介质
WO2022009415A1 (ja) リクエスト配送装置、リクエスト配送方法、および、リクエスト配送プログラム
CN113259408A (zh) 数据传输方法和***
WO2023185796A1 (zh) 一种信息推送方法及服务器、客户端、存储介质
JP2010086137A (ja) メッセージキューイング方法及びプログラム
US20190238637A1 (en) Data replication in scalable messaging system
JP4305364B2 (ja) Ｗｅｂサービス要求中継システム、Ｗｅｂサービス要求中継方法、中継サーバ、及びそのプログラム
WO2024082882A1 (zh) 多媒体内容的传输方法、装置、设备及存储介质
US11985072B2 (en) Multimedia data stream processing method, electronic device, and storage medium
KR100801318B1 (ko) 메시지 전송 시스템

Legal Events

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

Ref document number: 20944044

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022534868

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20944044

Country of ref document: EP

Kind code of ref document: A1