[go: up one dir, main page]

TWI894110B - 處理資訊之電子裝置之動作方法及支持其之電子裝置 - Google Patents

處理資訊之電子裝置之動作方法及支持其之電子裝置

Info

Publication number
TWI894110B
TWI894110B TW114107719A TW114107719A TWI894110B TW I894110 B TWI894110 B TW I894110B TW 114107719 A TW114107719 A TW 114107719A TW 114107719 A TW114107719 A TW 114107719A TW I894110 B TWI894110 B TW I894110B
Authority
TW
Taiwan
Prior art keywords
request information
processing model
processing
information processing
service
Prior art date
Application number
TW114107719A
Other languages
English (en)
Other versions
TW202526783A (zh
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
Priority claimed from KR1020220116220A external-priority patent/KR102918498B1/ko
Application filed by 韓商韓領有限公司 filed Critical 韓商韓領有限公司
Publication of TW202526783A publication Critical patent/TW202526783A/zh
Application granted granted Critical
Publication of TWI894110B publication Critical patent/TWI894110B/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/48—Program initiating; Program switching, e.g. by interrupt
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
    • G06F9/4831—Task transfer initiation or dispatching by interrupt, e.g. masked with variable priority
    • G06F9/4837—Task transfer initiation or dispatching by interrupt, e.g. masked with variable priority time dependent
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5022—Workload threshold

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • General Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer And Data Communications (AREA)
  • Stored Programmes (AREA)
  • Input From Keyboards Or The Like (AREA)

Abstract

根據本發明，揭示了一種資訊處理方法，其係藉由電子裝置而處理請求資訊者，其包括如下步驟：設定與藉由服務而獲得之請求資訊之處理相關之請求資訊處理模型；及基於上述請求資訊處理模型中包括之至少一個處理模型，處理藉由上述服務而獲得之請求資訊。

Description

處理資訊之電子裝置之動作方法及支持其之電子裝置
本發明係關於一種處理資訊之方法及裝置，更具體而言，係關於一種用於處理藉由服務而獲得之請求資訊之方法及其電子裝置。
隨著電子技術之發展，電子商務已成為購物之一個領域。顧客即便不直接去購物中心或市場，亦可於網上購買物品，於網上購買之物品將配送至顧客請求之配送地。
於電子商務方面，由於對商品之詳細、準確之資訊之處理會對服務滿意度產生相當大之影響，故而正在討論更詳細、更準確地處理資訊之各種方案。
相關內容可參照KR101756594B1或KR101500849B1等先前文獻。
[發明所欲解決之問題] 根據本發明之方法，電子裝置可藉由設定請求資訊處理模型而處理藉由服務而獲得之請求資訊。
本發明所欲實現之技術課題並不限於上述技術課題，本發明所屬之技術領域內具有常識者可根據以下記載而明確地理解未提及之其他技術課題。 [解決問題之技術手段]
各種實施例可提供一種用於資訊處理之電子裝置之動作方法及支持其之電子裝置。
各種實施例之一種資訊處理方法，其係藉由電子裝置而處理請求(request)資訊者，其包括：設定與藉由服務而獲得之請求資訊之處理相關之請求資訊處理模型；及基於上述請求資訊處理模型中包括之至少一個處理模型，處理藉由上述服務而獲得之請求資訊，且上述請求資訊處理模型可包括如下模型：第1處理模型，其在與上述服務相關聯之一個以上之伺服器(server)中包括之各伺服器中，將每單位時間要處理之請求資訊之個數限制為第1臨界個數以下；第2處理模型，其對應於將與上述服務對應之複數個APIs(Application Programming Interfaces，應用程式介面)根據重要度來分類之複數個第一API組中之特定API組，於上述各伺服器中將每單位時間要處理之請求資訊之個數限制為第2臨界個數以下；及第3處理模型，其對應於將上述複數個APIs根據資源(resource)使用量來分類之複數個第二API組中包括之各API組，將要處理之各請求資訊之個數限制為為了上述各API組而設定之各臨界個數以下。
於示例之實施例中，上述請求資訊處理模型可包括如下模型：第4處理模型，其對應於上述服務之用戶，而將每單位時間要處理之請求資訊之個數限制為第3臨界個數以下。
於示例之實施例中，可藉由與上述一個以上之伺服器共同對應之一個外部快取(Cache)而確認自上述用戶每單位時間獲得之請求資訊之個數。
於示例之實施例中，可基於上述用戶之識別資訊及上述用戶正在使用中之API之資訊，確認自上述用戶每單位時間獲得之請求資訊之個數。
於示例之實施例中，上述資訊處理方法可進而包括如下步驟：藉由API標識符(Identifier)而確認上述API之資訊。
於示例之實施例中，上述請求資訊處理模型可包括如下模型：第5處理模型，其中斷藉由上述服務而獲得之全部請求資訊之處理。
於示例之實施例中，可拒絕對如下之請求資訊進行處理：超過基於上述請求資訊處理模型中包括之各處理模型而限制之臨界個數。
於示例之實施例中，上述資訊處理方法可進而包括如下步驟：設定與上述請求資訊處理模型中包括之各處理模型對應之各處理模型狀態識別資訊；及基於上述各處理模型狀態識別資訊，根據上述各處理模型而確認拒絕處理之請求資訊之個數。
於示例之實施例中，上述至少一個處理模型可基於與上述電子裝置對應之管理者之第1輸入而選擇。
於示例之實施例中，上述第1臨界個數、上述第2臨界個數、及用於上述各API組之上述各臨界個數可基於與上述電子裝置對應之管理者之第2輸入而設定。
於示例之實施例中，上述第1臨界個數、上述第2臨界個數、及用於上述各API組之上述各臨界個數可基於與上述服務相關之環境參數資訊而設定。
於示例之實施例中，上述環境參數資訊可包括上述一個以上之伺服器之個數之資訊、用於上述服務之總資源容納量之資訊、及是否於預計請求資訊會增減之上述服務上進行促銷之資訊中的至少一者。
於示例之實施例中，上述資訊處理方法進而包括如下步驟：設定與上述請求資訊處理模型對應之層(layer)構造；且基於上述層構造，上述請求資訊處理模型可應用於用於上述電子裝置之動作之演算法(Algorithm)中。
各種實施例之一種非暫時性電腦可讀記錄媒體，其係記錄用以於電腦中執行資訊處理方法之程式者，上述資訊處理方法包括如下步驟：設定與藉由服務而獲得之請求資訊之處理相關之請求資訊處理模型；及基於上述請求資訊處理模型中包括之至少一個處理模型，處理藉由上述服務而獲得之請求資訊；且上述請求資訊處理模型可包括如下模型：第1處理模型，其在與上述服務相關聯之一個以上之伺服器(server)中包括之各伺服器中，將每單位時間要處理之請求資訊之個數限制為第1臨界個數以下；第2處理模型，其對應於將與上述服務對應之複數個APIs(Application Programming Interfaces，應用程式介面)根據重要度來分類之複數個第一API組中之特定API組，於上述各伺服器中將每單位時間將處理之請求資訊之個數限制為第2臨界個數以下；及第3處理模型，其對應於將上述複數個APIs根據資源(resource)使用量來分類之複數個第二API組中包括之各API組，將要處理之各請求資訊之個數限制為為了上述各API組而設定之各臨界個數以下。
各種實施例之一種電子裝置，其係處理請求(request)資訊者，其包括：處理器(processor)；及一個以上之記憶體(memory)，其儲存一個以上之指令(instruction)；上述一個以上之指令於執行時，控制上述處理器以便實行如下步驟：設定與藉由服務而獲得之請求資訊之處理相關之請求資訊處理模型；及基於上述請求資訊處理模型中包括之至少一個處理模型，處理藉由上述服務而獲得之請求資訊；上述請求資訊處理模型可包括如下模型：第1處理模型，其在與上述服務相關聯之一個以上之伺服器(server)中包括之各伺服器中，將每單位時間要處理之請求資訊之個數限制為第1臨界個數以下；第2處理模型，其對應於將與上述服務對應之複數個APIs(Application Programming Interfaces，應用程式介面)根據重要度來分類之複數個第一API組中之特定API組，於上述各伺服器中將每單位時間要處理之請求資訊之個數限制為第2臨界個數以下；及第3處理模型，其對應於將上述複數個APIs根據資源(resource)使用量來分類之複數個第二API組中包括之各API組，將要處理之各請求資訊之個數限制為為了上述各API組而設定之各臨界個數以下。
上述本發明之各種實施例僅為本發明之較佳之實施例中之一部分，該技術領域內具有常識者可基於以下詳述之詳細說明來導出並理解反映本發明之各種實施例之技術特徵之各種實施例。 [發明之效果]
本發明提出了一種電子裝置藉由設定請求資訊處理模型而處理藉由服務而獲得之請求資訊之方法，具有可有效率地實行請求資訊之處理之方面之技術效果。
本發明中可獲得之效果並不限於上述效果，本發明所屬之技術領域內具有常識者可根據以下記載而明確地理解未提及之其他技術效果。
以下之實施例係將各種實施例之構成要素與特徵以特定之形態結合。除非另有明確說明，否則可認為各構成要素或特徵具有選擇性。各構成要素或特徵能夠以不與其他構成要素或特徵結合之形態實施。又，亦可結合一部分構成要素及特徵來構成各種實施例。各種實施例中說明之動作之順序可改變。某個實施例之部分構成或特徵可包括於其他實施例中，或者可替換其他實施例之對應之構成或特徵。
於對圖式之說明中，未記述可能混淆各種實施例之主旨之程序或步驟，亦未記述以該技術領域內具有常識者之水準能夠理解之程序或步驟。
於整篇說明書中，於記載為某個部分「包括(comprising或including)」某個構成要素時，若未特別記載相反之內容，則意味著可進而包括其他構成要素，而並非排除其他構成要素。又，說明書中記載之「...部」、「...器」、「模組」等用語係指對至少一個功能或動作進行處理之單位，其可由硬體、軟體、或硬體與軟體之組合來實現。又，於記述各種實施例之文中(特別是以下之發明申請專利範圍中)，若未於本說明書中另作指示或未於文中明確地反駁，則「一(a或an)」、「一個(one)」、「該(the)」及相似之相關詞能夠以包括單數及複數兩者之含義來使用。
以下，參照附圖，詳細地對各種實施例之較佳之實施方式進行說明。連同附圖一併揭示於下文中之詳細說明係對各種實施例之例示性之實施方式進行說明，並非意欲表示唯一之實施方式。
又，各種實施例中使用之特定(specific)用語係為了有助於理解各種實施例而提供者，此種特定用語之使用可於不脫離各種實施例之技術思想之範圍內變更為其他形態。
圖1係用以說明能夠實現各種實施例之用於資訊處理之電子裝置之動作方法的資訊處理系統之圖。
參照圖1，各種實施例之資訊處理系統可於各種類型之裝置中實現。例如，資訊處理系統可在與服務相關之電子裝置100、能夠利用服務之用戶裝置200及用於服務之伺服器裝置300中實現。換言之，與服務相關之電子裝置100、用戶裝置200及伺服器裝置300可基於各個裝置中實現之資訊處理系統，實行本發明之各種實施例之動作。另一方面，各種實施例之資訊處理系統不僅侷限於上述圖1所示，亦可於更多樣之裝置中實現。
各種實施例之電子裝置100可對應於如下裝置，其實行與服務相關之本發明中提議之資訊處理方法，且管理於用戶裝置200、伺服器裝置300及服務之間收發之資訊之處理。於本發明中，電子裝置100可構成為包含用戶裝置200或伺服器裝置300之功能。
各種實施例之用戶裝置200可為諸如台式電腦、平板電腦、行動終端之類之能夠被個人用戶利用之裝置。此外，實行類似之功能之其他裝置亦可用作用戶裝置200。
各種實施例之伺服器裝置300可為如下裝置：與複數個用戶裝置200實行無線及有線通訊，且包括具有大單位之儲存容量之儲存器。例如，伺服器裝置300可包括與複數個用戶裝置200連接之雲設備(Cloud Device)。
各種實施例之資訊處理系統可包括用於動作之各種模組。資訊處理系統中包括之模組可為實現資訊處理系統之(或者，包括於物理裝置中之)物理裝置(例如：電子裝置100、用戶裝置200及伺服器裝置300)能夠實行之指定動作之電腦代碼或一個以上之指令(instruction)。換言之，實現資訊處理系統之物理裝置以電腦代碼之形態將複數個模組儲存於記憶體中，且於執行儲存於記憶體中之複數個模組時，複數個模組可由物理裝置實行對應於複數個模組之指定動作。
圖2係示出各種實施例之裝置節點之構成之圖。
圖2之裝置節點可包括構成圖1之資訊處理系統之電子裝置100、用戶裝置200及伺服器裝置300，且圖2之裝置節點可包括輸入/輸出部210、通訊部220、儲存器230及處理器240。
輸入/輸出部210可為接收用戶輸入或向用戶輸出資訊之各種介面或連接埠等。輸入/輸出部210可包括輸入模組及輸出模組，輸入模組自用戶接收用戶輸入。用戶輸入能夠以鍵輸入、觸控輸入、語音輸入等各種形態實現。作為可接收此種用戶輸入之輸入模組之示例，當然包括傳統形態之小鍵盤或鍵盤、滑鼠，此外亦包括感知用戶之觸控之觸控感測器、接收聲音信號之麥克風、藉由影像識別來識別手勢等之相機、包括感知用戶接近之照度感測器或紅外線感測器中之至少一者之接近感測器、藉由加速度感測器或陀螺儀感測器等而識別用戶動作之運動感測器及感知或接收其他各種形態之用戶輸入之各種形態的輸入機構，本發明之實施例之輸入模組可包括以上所列出之裝置中之至少一者。此處，觸控感測器可藉由如下方式實現，即，藉由貼附於顯示器面板上之觸控面板或觸控膜來感知觸控之壓電式或靜電式觸控感測器、藉由光學方式來感知觸控之光學式觸控感測器等。此外，輸入模組亦能夠以與接收用戶輸入之外部輸入裝置連接之輸入介面(USB(Universal Serial Bus，通用序列匯流排)埠、PS/2(Personal System 2，第2代個人系統)埠等)形態來實現，以此代替自身感知用戶輸入之裝置。又，輸出模組可輸出各種資訊。輸出模組可包括輸出影像之顯示器、輸出聲音之揚聲器、產生振動之觸覺裝置及其他各種形態之輸出機構中之至少一者。進而，輸出模組亦能夠以連接上述各個輸出機構之埠型輸出介面之形態實現。
作為一例，顯示器形態之輸出模組可顯示文本、靜態圖像及視訊。顯示器可包括液晶顯示器(LCD：Liquid Crystal Display)、發光二極體(LED：Light Emitting Diode)顯示器、有機發光二極體(OLED：Organic Light Emitting Diode)顯示器、平板顯示器(FPD：Flat Panel Display)、透明顯示器(Transparent Display)、曲面顯示器(Curved Display)、可撓式顯示器(Flexible Display)、三維顯示器(3D Display)、全像顯示器(Holographic Display)、投影儀等可實行影像輸出功能之各種形態之裝置中之至少一種。此種顯示器亦可為與輸入模組之觸控感測器一體地構成之觸控顯示器之形態。
通訊部220可與其他裝置進行通訊。因此，與服務相關之裝置節點可藉由通訊部而與其他裝置收發資訊。例如，裝置節點可利用通訊部來實行彼此間之通訊，或與其他裝置實行通訊。
此處，通訊即資料之收發可藉由有線或無線來實現。為此，通訊部可構成為：經由LAN(Local Area Network，區域網路)而連接網際網路等之有線通訊模組、經由行動通訊基地台而連接行動通訊網路來收發資料之行動通訊模組、利用如無線保真(Wi-Fi)之WLAN(Wireless Local Area Network，無線區域網路)系通訊方式或如藍牙(Bluetooth)、紫蜂(Zigbee)之WPAN(Wireless Personal Area Network，無線個人區域網路)系通訊方式之近距離通訊模組、利用如GPS(Global Positioning System，全球定位系統)之GNSS(Global Navigation Satellite System，全球導航衛星系統)之衛星通訊模組或其等之組合。
儲存器230可儲存各種資訊。儲存器230可暫時或半永久性地儲存資料。例如，裝置節點之儲存器230中可儲存與用以驅動裝置節點之作業系統(OS：Operating System)、用以代管網站之資料或用以產生點字之程式或應用程式(例如，網站應用程式)相關之資料等。又，儲存器230可如上所述以電腦代碼之形態儲存模組。
作為儲存器230之示例，可包括：硬式磁碟機(HDD：Hard Disk Drive)、SSD(Solid State Drive，固態硬碟)、快閃記憶體(Flash Memory)、唯讀記憶體(ROM：Read-Only Memory)、隨機存取記憶體(RAM：Random Access Memory)等。此種儲存器230能夠以內置類型或可裝卸類型提供。
處理器240對裝置節點之整體動作進行控制。為此，處理器240可實行各種資訊之運算及處理，並對裝置節點之各構成要素之動作進行控制。例如，處理器240可執行用於資訊處理之程式及應用程式。處理器240可根據硬體、軟體或其等之組合，藉由電腦或與其類似之裝置來實現。於硬體方面而言，處理器240能夠以對電信號進行處理並實行控制功能之電路之形態來實現，於軟體方面而言，能夠以驅動硬體處理器240之程式之形態來實現。另一方面，於以下之說明中未特別提及之情形時，裝置節點之動作可解釋為藉由處理器240之控制來實行。即，可解釋為於執行上述資訊處理系統中實現之模組之情形時，模組控制處理器240來使裝置節點實行以下之動作。
簡言之，各種實施例可藉由各種機構實現。例如，各種實施例可藉由硬體、韌體(firmware)、軟體或其等之組合來實現。
於藉由硬體實現之情形時，各種實施例之方法可藉由一個或一個以上之ASICs(application specific integrated circuits，特定應用積體電路)、DSPs(digital signal processors，數位信號處理器)、DSPDs(digital signal processing devices，數位信號處理裝置)、PLDs(programmable logic devices，可程式邏輯裝置)、FPGAs(field programmable gate arrays，場域可程式閘陣列)、處理器、控制器、微控制器、微處理器等實現。
於藉由韌體或軟體實現之情形時，各種實施例之方法可由實行以下說明之功能或動作之模組、程序或函數等形態實現。例如，軟體代碼可儲存於記憶體中並由處理器驅動。上述記憶體可位於處理器之內部或外部，可藉由公知之各種機構而與上述處理器交換資料。
以下，基於上述技術思想而對各種實施例進行更詳細之說明。以下說明之各種實施例可應用上述內容。例如，於以下說明之各種實施例中未定義之動作、功能、用語等可基於上述說明之內容來實行並加以說明。
於以下之說明中，以與服務相關之電子裝置100實行用於資訊處理方法之動作為前提，記述了各種實施例。
圖3係示出實行本發明所提議之資訊處理方法之電子裝置之構造圖。
於圖3中，實行資訊處理方法之電子裝置100可包括通訊設備301、控制部303及記憶體305。圖3之電子裝置100中包括之各構成要素可對應於圖2之裝置節點之構成，或者圖3之電子裝置100可包括圖2之裝置節點之構成。作為一例，圖3之電子裝置100中包括之通訊設備301可對應於圖2之裝置節點之構成中包括之通訊部220。
圖3之電子裝置100可具有如下功能：藉由通訊設備301而與其他裝置進行通訊。
控制部303可控制電子裝置100，以便實行包括下文敍述之圖4至圖14之各種實施例之資訊輸出方法。作為一例，控制部303可控制電子裝置100實行下文敍述之圖4之各動作401至403，且控制電子裝置100儲存及收發實行圖4之動作401至403所需之各種資訊。
記憶體305可為揮發性記憶體或非揮發性記憶體，使控制部303執行用以實行資訊輸出方法之程式所需之程式之代碼可儲存於記憶體305中。
於本發明中，實行資訊輸出方法之電子裝置100並不限定於圖3之構成，且除圖3所示之各種構成要素之外，本發明之電子裝置100中亦可包括其他通用之構成要素。
圖4係示出各種實施例之用於資訊處理之電子裝置之動作方法的圖。
根據圖4，電子裝置100可為了處理請求資訊，而實行處理請求資訊之動作，可設定與藉由服務而獲得之請求資訊之處理相關之請求資訊處理模型401，且可基於請求資訊處理模型中包括之至少一個處理模型，處理藉由服務而獲得之請求資訊403。
根據圖4，電子裝置100設定請求資訊處理模型並處理請求資訊之動作可為了與電子裝置100相關之服務而實行，且上述服務可對應於利用服務之複數個用戶訂購及購買服務中銷售之複數個物品之服務。於服務中銷售之複數個物品可包括賣方為了銷售物品而註冊之各種種類或類型之物品，而不限制於物品之類型或類型。
根據各種實施例，於動作401中，電子裝置100可設定與藉由服務而獲得之請求資訊之處理相關之請求資訊處理模型。
例如，根據動作401由電子裝置100設定之請求資訊處理模型可包括第1處理模型，該第1處理模型在與服務相關聯之一個以上之伺服器(server)中所包括之各伺服器中，將每單位時間將處理之請求資訊之個數限制為第1臨界個數以下。以下，下文敍述之一個以上之伺服器或各伺服器可理解為與圖1中之伺服器裝置300對應之概念。
如上所述之第1處理模型相當於用以防止在與服務相關聯之一個以上之伺服器(server)中包括之各伺服器中處理請求資訊時產生之負荷之處理模型，且第1處理模型能夠設定為根據應用第1處理模型之管理者之選擇輸入來應用。作為一例，於一個以上之伺服器每單位時間要處理之請求資訊之個數被確認為固定個數以上，且電子裝置100之管理者判斷各伺服器中每單位時間要處理之請求資訊之個數過多之情形時，管理者可進行選擇輸入以應用第1處理模型，藉由利用管理者之選擇輸入來應用第1處理模型，可將各伺服器中每單位時間要處理之請求資訊之個數限制為第1臨界個數以下。
或者，除了管理者之選擇輸入之外，電子裝置100亦能夠以如下方式設定：於滿足一定條件之情況下應用第1處理模型。作為一例，可將一個以上之伺服器每單位時間要處理之請求資訊之個數設定成固定個數以上之條件而用於第1處理模型，電子裝置100能夠以如下方式管理：於滿足上述之條件之情形時，自動應用第1處理模型，將各伺服器中每單位時間要處理之請求資訊之個數限制為第1臨界個數以下。
此處，為了第1處理模型而設定之第1臨界個數可為藉由管理者之輸入而設定之值。
圖5係示出設定請求資訊處理模型中包括之第1處理模型之一示例之圖。
於圖5中，電子裝置100係以如下方式管理：藉由與服務相關聯之一個以上之伺服器對自利用服務之複數個用戶獲得之請求資訊進行處理(500)，此時，第1處理模型能夠以與501相同之形態應用，該第1處理模型將在各伺服器中每單位時間要處理之請求資訊之個數限制為特定之臨界個數以內。
於圖5中，藉由應用第1處理模型，可將各伺服器每1分鐘要處理之請求資訊之個數限制為10,000個以內，且此種第1處理模型亦能夠基於如下情況藉由管理者之選擇輸入或自動應用而設定：一個以上之伺服器每1分鐘要處理之請求資訊之個數被確認為30,000個以上。
例如，根據動作401由電子裝置100設定之請求資訊處理模型可包括第2處理模型，該第2處理模型對應於將與服務對應之複數個APIs(Application Programming Interfaces，應用程式介面)根據重要度來分類之複數個第一API組中之特定API組，於上述各伺服器中將每單位時間將處理之請求資訊之個數限制為第2臨界個數以下。
如上所述之第2處理模型相當於用以防止在與服務相關聯之一個以上之伺服器(server)中包括之各伺服器中處理與具有特定之重要度之API組對應之請求資訊時產生的負荷之處理模型，且第2處理模型能夠設定為根據應用第2處理模型之管理者之選擇輸入來應用。
服務上之各種APIs可具有相互不同之重要度，電子裝置100以如下方式管理非常重要，即，能夠主要處理由具有較高重要度之APIs獲得之請求資訊。因此，電子裝置100根據服務上之各種APIs之重要度而區分為具有較高重要度之API組與具有較低重要度之API組，且可限制對應於具有較低重要度之API組而獲得之請求資訊之處理，以便可主要處理對應於具有較高重要度之API組而獲得之請求資訊。
作為一例，於對應於具有較低重要度之API組，一個以上之伺服器每單位時間要處理之請求資訊之個數被確認為固定個數以上，電子裝置100之管理者判斷於各伺服器中對應於具有較低重要度之API組而處理之請求資訊的個數增加，從而在與具有較高重要度之API組對應之請求資訊之處理中產生負荷之情形時，管理者可進行選擇輸入以應用第2處理模型，藉由利用管理者之選擇輸入來應用第2處理模型，可於各伺服器中對應於具有較低重要度之API組，將每單位時間要處理之請求資訊之個數限制為第2臨界個數以下。藉由應用此種第2處理模型，可於各伺服器中確保用於與具有較高重要度之API組對應之請求資訊之一定水準以上的每單位時間處理容量。
或者，除了管理者之選擇輸入之外，電子裝置100亦能夠以如下方式設定：於滿足一定條件之情況下應用第2處理模型。作為一例，可對應於具有較低重要度之API組，將一個以上之伺服器每單位時間要處理之請求資訊之個數設定為固定個數以上之條件而用於第2處理模型，電子裝置100能夠以如下方式管理：於滿足上述之條件之情形時，自動應用第2處理模型，對應於各伺服器中具有較低重要度之API組，將每單位時間要處理之請求資訊之個數限制為第2臨界個數以下。
此處，為了第2處理模型而設定之第2臨界個數可為藉由管理者之輸入而設定之值。又，為了第2處理模型，電子裝置100可預先確認並管理關於各API之重要度之資訊，且亦可基於關於各API之重要度之資訊來實行如下動作，即，將服務上之各種APIs區分為具有較高重要度之API組與具有較低重要度之API組。
關於第2處理模型，重要度較高之API之示例包括購買物品時用於提供結算頁面之API、用於向購物車追加物品之API等，重要度較低之API之示例包括用於確認用戶之結算機制之API、用於物品訂購時請求保鮮袋之API等。
圖6係示出設定請求資訊處理模型中包括之第2處理模型之一示例之圖。
於圖6中，電子裝置100能夠以如下方式管理：將自利用服務之複數個用戶獲得之請求資訊區分為於服務上對應於具有較高重要度之API組而獲得之請求資訊、及對應於具有較低重要度之API組而獲得之請求資訊，且可藉由與服務相關聯之一個以上之伺服器對對應於各API組而獲得之請求資訊進行處理(600)。此時，第2處理模型能夠以與601相同之形態應用，該第2處理模型於各伺服器中對應於具有較低重要度之API組，將每單位時間要處理之請求資訊之個數限制為特定之臨界個數以內。
於圖6中，藉由應用第2處理模型，可於各伺服器中對應於具有較低重要度之API組，將每1分鐘要處理之請求資訊之個數限制為8,000個以內，且此種第2處理模型亦能夠基於如下情況根據管理者之選擇輸入或自動應用而設定：一個以上之伺服器對應於具有較低重要度之API組每1分鐘要處理之請求資訊之個數被確認為24,000個以上。藉由應用與601相同之第2處理模型，可於各伺服器中確保用於與具有較高重要度之API組對應之請求資訊之一定水準以上的每單位時間處理容量。
例如，根據動作401由電子裝置100設定之請求資訊處理模型可包括第3處理模型，該第3處理模型對應於將複數個APIs(Application Programming Interfaces，應用程式介面)根據資源(resource)使用量來分類之複數個第二API組中包括之各API組，將要處理之各請求資訊之個數限制為為了上述各API組而設定之各臨界個數以下。
如上所述之第3處理模型相當於在與服務相關聯之一個以上之伺服器(server)中包括之各伺服器中，處理與根據資源使用量來分類之複數個第二API組分別對應之請求資訊之過程中，用以防止所管理之各API組之剩餘資源容量為0之處理模型，且第3處理模型能夠設定為根據應用第3處理模型之管理者之選擇輸入來應用。
服務上之各種APIs可消耗相互不同之資源使用量，電子裝置100以不超過用於各APIs之資源使用量之方式管理可能非常重要。因此，電子裝置100能夠以如下方式管理：根據其資源使用量將服務上之各種APIs區分為具有較高資源使用量之API組、具有中等資源使用量之API組、及具有較低資源使用量之API組，可對應於API組而分配固定之資源容量，且可於不超過所分配之資源容量之範圍內主要處理對應於各API組而獲得之請求資訊。
作為一例，可1）為具有較高資源使用量之API組分配固定之資源容量，確認可根據所分配之資源容量來處理之請求資訊之臨界個數l值；2）為具有中等資源容量之API組分配固定之資源容量，確認可根據所分配之資源容量來處理之請求資訊之臨界個數n值；3）為具有較低資源使用量之API組分配固定之資源容量，確認可根據所分配之資源容量來處理之請求資訊之臨界個數m值。於電子裝置100之管理者欲管理不超過分配至各API組之資源容量之情形時，管理者可進行選擇輸入以應用第3處理模型，藉由利用管理者之選擇輸入來應用第3處理模型，可對應於各API組將已處理之請求資訊之個數限制為已確認之各API組之各臨界個數以內。
此處，為了第3處理模型而設定之各臨界個數可為藉由管理者之輸入而設定之值。又，為了第3處理模型，電子裝置100可預先確認並管理關於各API之資源使用量之資訊，且亦可基於關於各API之資源使用量之資訊來實行如下動作，即，將服務上之各種APIs區分為具有較高資源使用量之API組、具有中等資源使用量之API組、及具有較低資源使用量之API組。
關於第3處理模型，具有較高資源使用量之API之示例可包括著陸API、用於與購買按鈕輸入對應之購買進行API等，具有中等資源使用量之API之示例可包括用於設定配送預定日期等日程之API等。又，具有較低資源使用量之API之示例可包括變更配送地址之API、用以輸入與海外直購相關之個人通關編碼之API等。
圖7係示出設定請求資訊處理模型中包括之第3處理模型之一示例之圖。
於圖7中，電子裝置100能夠以如下方式管理：將自利用服務之複數個用戶獲得之請求資訊區分為於服務上對應於具有較高資源使用量之API組而獲得之請求資訊、對應於具有中高等資源使用量之API組而獲得之請求資訊、及對應於具有較低資源使用量之API組而獲得之請求資訊，且藉由與服務相關聯之一個以上之伺服器對對應於各API組而獲得之請求資訊進行處理(700)。此時，第3處理模型能夠以與701相同之形態應用，該第3處理模型對應於各API組將要處理之請求資訊之個數限制為為了各API組而設定之各臨界個數以內。
於圖7中，藉由應用第3處理模型，可對應於具有較高資源使用量之API組將要處理之請求資訊之個數限制為1,000個以內，可對應於具有中等資源使用量之API組將要處理之請求資訊之個數限制為5,000個以內，可對應於具有較低資源使用量之API組將要處理之請求資訊之個數限制為10,000個以內，因此，用於各API組之資源容量能夠以不能為0之方式管理。又，此種第3處理模型能夠設定為藉由管理者之選擇輸入來應用。
例如，根據動作401由電子裝置100設定之請求資訊處理模型可包括第4處理模型，該第4處理模型對應於服務之用戶而將每單位時間要處理之請求資訊之個數限制為第3臨界個數以下。
如上所述之第4處理模型相當於在與服務相關聯之一個以上之伺服器(server)中包括之各伺服器中，用於防止因特定用戶之重複輸入而於短時間內獲得過多之請求資訊所產生負荷之處理模型，且第4處理模型能夠設定為根據應用第4處理模型之管理者之選擇輸入來應用。
於服務上，用戶可藉由各種APIs進行各種輸入，產生與用戶之輸入對應之請求資訊，由各伺服器進行處理，但若用戶進行反覆多次點擊(click)或觸摸(touch)等輸入、或使用宏(macro)等而於短時間內產生大量之請求資訊，即便放任伺服器全部處理，亦會產生不必要之負荷，因此電子裝置100以避免出現相同之問題之方式管理可能非常重要。因此，電子裝置100能夠以如下方式管理：對應於服務上之各用戶，確認每單位時間獲得之請求資訊之個數，必要時將各用戶之每單位時間要處理之請求資訊之個數限制為第3臨界個數以下。
此處，為了第4處理模型而設定之第3臨界個數可為藉由管理者之輸入來設定之值。
例如，自用戶每單位時間獲得之請求資訊之個數可藉由與服務相關聯之一個以上之伺服器共同對應之一個外部快取(Cache)而進行確認。即，於應用其他處理模型時，與在一個以上之伺服器中包括之各伺服器中分別設定之快取有所不同，於第4處理模型之情況下，設定了與一個以上之伺服器共同對應之一個外部快取，從而可容易地追蹤自用戶獲得之請求資訊之個數。
例如，自用戶每單位時間獲得之請求資訊之個數可基於用戶之識別資訊及用戶正在使用中之API之資訊而進行確認。即，由於用戶藉由重複輸入而產生大量之請求資訊很可能為在特定之API中實行之動作，因此電子裝置100可有效利用用戶之識別資訊與用戶正在使用中之API之資訊來追蹤藉由與此相同之用戶之動作而確認之請求資訊。
例如，電子裝置100可藉由API標識符(Identifier)而確認與上述相同之用戶正在使用中之API之資訊。各API中使用之用語之定義、資訊處理途徑、事件名稱等可能會有所不同，因此電子裝置100可設定識別各API之標識符，且藉由已設定之標識符來追蹤用戶正在使用中之API之資訊。
圖8係示出設定請求資訊處理模型中包括之第4處理模型之一示例之圖。
於圖8中，電子裝置100能夠以如下方式管理：可將自利用服務之複數個用戶獲得之請求資訊區分為對應於各用戶而獲得之請求資訊，且藉由與服務相關聯之一個以上之伺服器對對應於各用戶而獲得之請求資訊進行處理(800)。
於圖8中，藉由應用第4處理模型，而以如下方式進行管理，即，對應於根據識別資訊區分之特定用戶而獲得之請求資訊之個數不超過每1分鐘20個(801)，為了確認各用戶每單位時間獲得之請求資訊，可設定與一個以上之伺服器共同對應之一個外部快取(803)。此種第4處理模型能夠以根據管理者之選擇輸入來應用之方式設定。
例如，根據動作401由電子裝置100設定之請求資訊處理模型可包括第5處理模型，該第5處理模型中斷藉由服務而獲得之全部請求資訊之處理。
如上所述之第5處理模型相當於在發生藉由與服務相關聯之一個以上之伺服器(server)來處理請求資訊之問題時，中斷用以處理全部請求資訊之處理模型，且第5處理模型能夠設定為根據應用第5處理模型之管理者之選擇輸入來應用。
第5處理模型能夠以如下方式設定：於各伺服器單位中指示中斷請求資訊處理，以免於各伺服器中處理請求資訊，或者對於在請求資訊傳達至各伺服器之前之前端指示中斷請求資訊處理，以免於各伺服器中處理請求資訊。
圖9係示出設定請求資訊處理模型中包括之第5處理模型之一示例之圖。
於圖9中，電子裝置100能夠以如下方式藉由第5處理模型而進行管理，即，防止藉由各伺服器對藉由服務而獲得之全部請求資訊進行處理(900)，且此種第5處理模型能夠設定為根據管理者之選擇輸入來應用。
例如，可拒絕對如下之請求資訊進行處理：超過基於請求資訊處理模型中包括之各處理模型而限制之臨界個數。
例如，電子裝置100可根據請求資訊處理模型中包括之各處理模型而確認拒絕處理之請求資訊之個數。具體而言，電子裝置100可設定與請求資訊處理模型中包括之各處理模型對應之各處理模型狀態識別資訊，且基於各處理模型狀態識別資訊，根據各處理模型而確認拒絕處理之請求資訊之個數。
根據各種實施例，於動作403中，電子裝置100可基於請求資訊處理模型中包括之至少一個處理模型，處理藉由服務而獲得之請求資訊。
例如，根據動作403，電子裝置100可有效利用處理請求資訊之至少一個處理模型，於上述第1處理模型至上述第5處理模型中藉由電子裝置100之管理者之第1輸入來選擇。即，電子裝置100之管理者可根據情況而選擇應用處理請求資訊之處理模型。
例如，根據動作403，電子裝置100可基於電子裝置100之管理者之第2輸入，而設定在為了處理請求資訊而設定之請求資訊處理模型中包括之各處理模型中限制之各臨界個數。即，電子裝置100之管理者可根據情況而設定用於各處理模型之請求資訊處理之臨界個數。
例如，根據動作403，電子裝置100可基於與服務相關之環境參數資訊，而設定在為了處理請求資訊而設定之請求資訊處理模型中包括之各處理模型中限制之各臨界個數。即，電子裝置100能夠以如下方式管理：電子裝置100之管理者不設定用於各處理模型之請求資訊處理之臨界個數，而根據與服務相關之環境參數資訊來設定用於各處理模型之請求資訊處理之臨界個數。
例如，如上所述之環境參數資訊可包括能夠影響伺服器之請求資訊處理之參數之資訊中之至少一種資訊，例如上述一個以上之伺服器之個數之資訊、用於上述服務之總資源容納量之資訊、及/或是否於預計請求資訊會增減之上述服務上進行促銷之資訊。
另一方面，電子裝置100亦可設定層(layer)構造，將根據圖4為了處理請求資訊而設定之請求資訊處理模型應用於通用演算法(Algorithm)中。即，電子裝置100可設定與請求資訊處理模型對應之層(layer)構造，且根據已設定之層構造，請求資訊處理模型可應用於用於電子裝置100之動作之通用演算法中。
圖10係示出用以將請求資訊處理模型應用於用於電子裝置100之動作之演算法中之層構造的一示例之圖。
於圖10中，於電子裝置100為了處理請求資訊而設定第1處理模型至第5處理模型之情形時(1001)，可在用於電子裝置100之動作之演算法中之一個示例演算法、即Bucket4J核心(core)演算法1005中設定可應用上述第1處理模型至上述第5處理模型之展示層(Facade Layer)構造(1003)。
由圖10可知，第1處理模型對應於「伺服器速率限制(Server Rate Limit)」，第2處理模型對應於「保留速率限制(Reserved Rate Limit)」，第3處理模型對應於「並發速率限制(Concurrent Rate Limit)」，第4處理模型對應於「API+客戶端速率限制(API+Client Rate Limit)」，第5處理模型對應於「自毀開關(Kill Switch)」。
毋庸贅言，根據圖4至圖10，電子裝置100在用於實行資訊處理之動作方法之過程中設定或處理之各資訊能夠以各種形態來結合。
圖11至圖14係示出基於包括第1處理模型至第5處理模型之請求資訊處理模型而處理請求資訊之一示例之圖。例如，圖11至圖14之示例可於伺服器裝置300中處理對應於用戶裝置200之輸入而產生之請求資訊，且可於圖4至圖10中基於上述電子裝置100之動作而實行以下圖式中說明之各實施例。
具體而言，以下圖式中說明之各實施例能夠以如下形態實行：於用戶裝置200自用戶接收輸入資訊並將與上述輸入資訊相關之請求資訊傳輸至伺服器裝置300時，伺服器裝置300可於圖4至圖10中基於電子裝置100之動作來處理請求資訊。然而，以下圖式中說明之各實施例並不限定於此種形態，能夠以可實現各實施例之所有形態實行。
圖11係示出基於各種實施例之請求資訊處理模型而處理請求資訊之一示例的圖。
於圖11中，可確認基於請求資訊處理模型，應用相當於「自毀開關」之第5處理模型與相當於「伺服器速率限制」之第1處理模型。與電子裝置100對應之管理者將第5處理模型設定為關(off)(1101)，於視需要中斷對全部請求資訊之處理之情形時，可再次將其設定為開(on)。
又，於圖11中，與電子裝置100對應之管理者於可確認各伺服器中之請求資訊之處理將產生負荷，例如於每1分鐘需要處理之請求資訊之個數為100,000個以上之情形時(1103-1)，基於第1處理模型，可在各伺服器中將每1分鐘要處理之請求資訊之個數限制為10,000個以下(1103-2)。
此時，如上所述之各處理模型之應用並不限制於圖11中所示之順序，可根據與電子裝置100對應之管理者之輸入或各處理模型是否滿足預設之條件等來應用各處理模型。
圖12係示出基於各種實施例之請求資訊處理模型而處理請求資訊之另一示例的圖。為了方便起見，圖12之示例示出了追加應用至圖11之示例之第4處理模型，但第4處理模型之應用形態並不限定於圖12，第4處理模型可單獨應用或與各種其他處理模型組合而一併應用。
於圖12中，可確認基於請求資訊處理模型，應用相當於「自毀開關」之第5處理模型、相當於「伺服器速率限制」之第1處理模型及相當於「API+客戶端速率限制」之第4處理模型。與圖11中記述同樣地，圖12中與電子裝置100對應之管理者：1)將第5處理模型設定為關(1201)，2）對應於每1分鐘要處理之請求資訊之個數為100,000個以上之情形，可根據第1處理模型，於各伺服器中將每1分鐘要處理之請求資訊之個數限制為10,000個以內(1203-1、1203-2)。
又，於圖12中，與電子裝置100對應之管理者於自用戶獲得之請求資訊之個數為每1分鐘20個以上、或用於自用戶獲得之請求資訊之輸入為每1分鐘20次以上之情形時(1205-1)，基於第4處理模型，可將對應於該用戶之每1分鐘要處理之請求資訊之個數限制為20個以下(1205-2)。
此時，如上所述之各處理模型之應用並不限制於圖12中所示之順序，可根據與電子裝置100對應之管理者之輸入或各處理模型是否滿足預設之條件等來應用各處理模型。
圖13係示出基於各種實施例之請求資訊處理模型而處理請求資訊之另一示例的圖。為了方便起見，圖13之示例示出了追加應用至圖12之示例之第2處理模型，但第2處理模型之應用形態並不限定於圖13，第2處理模型可單獨應用或與各種其他處理模型組合而一併應用。
於圖13中，可確認基於請求資訊處理模型，應用相當於「自毀開關」之第5處理模型、相當於「伺服器速率限制」之第1處理模型、相當於「API+客戶端速率限制」之第4處理模型及相當於「保留速率限制」之第2處理模型。與圖12中記述同樣地，圖13中與電子裝置100對應之管理者：1)將第5處理模型設定為關(1301)，2）於每1分鐘要處理之請求資訊之個數為100,000個以上之情形時，根據第1處理模型，於各伺服器中將每1分鐘要處理之請求資訊之個數限制為10,000個以內(1303-1、1303-2)，3)於自用戶獲得之請求資訊之個數為每1分鐘20個以上、或用於自用戶獲得之請求資訊之輸入為每1分鐘20次以上之情形時，基於第4處理模型，可將對應於該用戶之每1分鐘要處理之請求資訊之個數限制為20個以下(1305-1、1305-2)。
又，於圖13中，與電子裝置100對應之管理者能夠以如下方式管理：將與服務對應之複數個APIs(Application Programming Interfaces，應用程式介面)根據重要度分類為具有較高重要度之API組與具有較低重要度之API組時，由於對應於具有較低重要度之API組而處理之請求資訊之個數為8,000個以上，故而判斷為超過需要(1307-1)，基於第2處理模型，可對應於具有較低重要度之API組，於各伺服器中將每單位時間要處理之請求資訊之個數限制為8,000個以下，對應於具有較高重要度之API組，於各伺服器中可每單位時間處理2,000個請求資訊(1307-2)。
此時，如上所述之各處理模型之應用並不限制於圖13中所示之順序，可根據與電子裝置100對應之管理者之輸入或各處理模型是否滿足預設之條件等來應用各處理模型。
圖14係示出基於各種實施例之請求資訊處理模型而處理請求資訊之另一示例的圖。為了方便起見，圖14之示例示出了追加應用至圖13之示例之第3處理模型，但第3處理模型之應用形態並不限定於圖14，第3處理模型可單獨應用或與各種其他處理模型組合而一併應用。
於圖14中，可確認基於請求資訊處理模型，應用相當於「自毀開關」之第5處理模型、相當於「伺服器速率限制」之第1處理模型、相當於「API+客戶端速率限制」之第4處理模型、相當於「保留速率限制」之第2處理模型及相當於「並發限制(Concurrent Limit)」之第3處理模型。與圖13中記述同樣地，圖14中與電子裝置100對應之管理者：1)將第5處理模型設定為關(1401)，2）於每1分鐘要處理之請求資訊之個數為100,000個以上之情形時，根據第1處理模型，可於各伺服器中將每1分鐘要處理之請求資訊之個數限制為10,000個以內(1403-1、1403-2，3)於自用戶獲得之請求資訊之個數為每1分鐘20個以上、或自用戶獲得之請求資訊之輸入為每1分鐘20次以上之情形時，基於第4處理模型，可將對應於該用戶之每1分鐘要處理之請求資訊之個數限制為20個以下(1405-1、1405-2)。又，與電子裝置100對應之管理者能夠以如下方式管理：4)確認對應於具有較低重要度之API組而處理之請求資訊之個數為8,000個以上時，根據第2處理模型，對應於具有較低重要度之API組，於各伺服器中將每單位時間要處理之請求資訊之個數限制為8,000個以下，對應於具有較高重要度之API組，於各伺服器中可每單位時間處理2,000個請求資訊(1407-1、1407-2)。
此外，於圖14中，與電子裝置100對應之管理者能夠以如下方式管理：根據資源使用量，將與服務對應之複數個APIs(Application Programming Interfaces，應用程式介面)分類為具有較高資源使用量之API組、具有中等資源使用量之API組及具有較低資源使用量之API組時，根據對應於具有較高資源使用量之API組而處理之請求資訊之個數，判斷為超過分配給具有較高資源使用量之API組之資源容量(1409-1)，基於第3處理模型，對應於分配給具有較高資源使用量之API組之資源容量，以可處理之請求資訊之臨界個數為1,000個以內之方式限制該API組之請求資訊處理，對應於具有較高資源使用量之API組，最多可處理1,000個請求資訊(1409-2)。
此時，如上所述之各處理模型之應用並不限制於圖14中所示之順序，可根據與電子裝置100對應之管理者之輸入或各處理模型是否滿足預設之條件等來應用各處理模型。
圖11至圖14之示例可與圖4至圖10中記述之電子裝置100之動作相關聯地實行，圖11至圖14之示例係用於揭示本發明之一個示例，本發明之各種實施例不限定於圖11至圖14之示例形態，可根據能夠實現本發明之各種實施例之所有形態來實行。
本說明書與圖式中所公開之本發明之實施例僅為用以容易地說明本發明之技術內容且幫助理解本發明之特定例，並非為了限定本發明之範圍。即，對於本發明所屬之技術領域內具有常識者而言，當然明白可實施基於本發明之技術思想之其他變化例。又，上述每個實施例可視需要而相互組合並運用。例如，本發明之所有實施例中，可將一部分相互組合，藉由系統而實現。
又，本發明之系統等之方法能夠以藉由各種電腦機構而實行之程式命令形態來實現，且記錄於電腦可讀媒體。
如上所述，於特定觀點下，本發明之各種實施例可於電腦可讀記錄媒體(computer readable recording medium)中實現為電腦可讀代碼(computer readable code)。電腦可讀記錄媒體係能夠儲存可藉由電腦系統而讀取之資料之任意資料儲存設備。電腦可讀記錄媒體之示例可包括：唯讀記憶體(read only memory，ROM)、隨機存取記憶體(random access memory，RAM)、光碟唯讀記憶體(compact disk-read only memory，CD-ROM)、磁帶(magnetic tape)、軟碟(floppy disk)、光資料儲存設備及載波(carrier wave)(藉由網際網路進行之資料發送等)。電腦可讀記錄媒體亦可藉由連接於網路之電腦系統而分散，因此以分散方式儲存並執行電腦可讀代碼。又，用以達成本發明之各種實施例之功能性程式、代碼及片段(segment)可由應用本發明之領域之熟練程式設計師容易地解釋。
又，可知本發明之各種實施例之裝置及方法能夠以硬體、軟體、或硬體與軟體之組合之形態來實現。此種軟體例如可與是否可刪除或可再次記錄無關地儲存於如ROM等儲存裝置之揮發性或非揮發性儲存裝置、或例如RAM、記憶體晶片、裝置或積體電路之記憶體、或例如光碟(compact disk，CD)、DVD(Digital Versatile Disc，數位多功能光碟)、磁碟或磁帶等可光學或磁性地記錄並且可由機器(例如電腦)讀取之儲存媒體。可知本發明之各種實施例之方法可藉由包括控制部及記憶體之電腦或包括如上所述之記憶體或電腦之車輛等而實現，此種記憶體係包括實現本發明之實施例之命令之程式或可由適於儲存程式之機器讀取之儲存媒體的一例。
因此，本發明包括：用以實現本說明書之發明申請專利範圍中記載之裝置或方法之代碼的程式、及可由儲存此種程式之機器(電腦等)讀取之儲存媒體。又，此種程式可藉由如藉由有線或無線連接來傳輸之通訊信號之任意媒體而進行電子移送，本發明適當地包括其均等物。
又，可理解為上述說明之本發明之實施例僅為示例，於本領域內具有常識者可據此實現各種變化及均等範圍之實施例。因此，本發明之真正之技術保護範圍應根據以下之發明申請專利範圍而界定。
100: 電子裝置 200: 用戶裝置 210: 輸入/輸出部 220: 通訊部 230: 儲存器 240: 處理器 300: 伺服器裝置 301: 通訊設備 303: 控制部 305: 記憶體 401: 動作 403: 動作 500: 藉由與服務相關聯之一個以上之伺服器對自利用服務之複數個用戶獲得之請求資訊進行處理 600: 將自利用服務之複數個用戶獲得之請求資訊區分為於服務上對應於具有較高重要度之API組而獲得之請求資訊、及對應於具有較低重要度之API組而獲得之請求資訊，且可藉由與服務相關聯之一個以上之伺服器對對應於各API組而獲得之請求資訊進行處理 700: 將自利用服務之複數個用戶獲得之請求資訊區分為於服務上對應於具有較高資源使用量之API組而獲得之請求資訊、對應於具有中高等資源使用量之API組而獲得之請求資訊、及對應於具有較低資源使用量之API組而獲得之請求資訊，且藉由與服務相關聯之一個以上之伺服器對對應於各API組而獲得之請求資訊進行處理 800: 將自利用服務之複數個用戶獲得之請求資訊區分為對應於各用戶而獲得之請求資訊，且藉由與服務相關聯之一個以上之伺服器對對應於各用戶而獲得之請求資訊進行處理 801: 對應於根據識別資訊區分之特定用戶而獲得之請求資訊之個數不超過每1分鐘20個 803: 設定與一個以上之伺服器共同對應之一個外部快取 900: 防止藉由各伺服器對藉由服務而獲得之全部請求資訊藉由各伺服器進行處理 1001: 設定第1處理模型至第5處理模型之情形 1003: 設定可應用上述第1處理模型至上述第5處理模型之展示層(Facade Layer)構造 1005: Bucket4J核心(core)演算法 1101: 將第5處理模型設定為關(off) 1103-1: 每1分鐘需要處理之請求資訊之個數為100,000個以上之情形 1103-2: 將每1分鐘要處理之請求資訊之個數限制為10,000個以下 1201: 將第5處理模型設定為關 1203-1: 將每1分鐘要處理之請求資訊之個數限制為10,000個以內 1203-2: 將每1分鐘要處理之請求資訊之個數限制為10,000個以內 1205-1: 自用戶獲得之請求資訊之個數為每1分鐘20個以上、或用於自用戶獲得之請求資訊之輸入為每1分鐘20次以上之情形 1205-2: 將對應於該用戶之每1分鐘要處理之請求資訊之個數限制為20個以下 1301: 將第5處理模型設定為關 1303-1: 將每1分鐘要處理之請求資訊之個數限制為10,000個以內 1303-2: 將每1分鐘要處理之請求資訊之個數限制為10,000個以內 1305-1: 將對應於該用戶之每1分鐘要處理之請求資訊之個數限制為20個以下 1305-2: 將對應於該用戶之每1分鐘要處理之請求資訊之個數限制為20個以下 1307-1: 判斷為超過需要 1307-2: 將每單位時間要處理之請求資訊之個數限制為8,000個以下，對應於具有較高重要度之API組，於各伺服器中可每單位時間處理2,000個請求資訊 1401: 將第5處理模型設定為關 1403-1: 將每1分鐘要處理之請求資訊之個數限制為10,000個以內 1403-2: 將每1分鐘要處理之請求資訊之個數限制為10,000個以內 1405-1: 將對應於該用戶之每1分鐘要處理之請求資訊之個數限制為20個以下 1405-2: 將對應於該用戶之每1分鐘要處理之請求資訊之個數限制為20個以下 1407-1: 將每單位時間要處理之請求資訊之個數限制為8,000個以下，對應於具有較高重要度之API組，於各伺服器中可每單位時間處理2,000個請求資訊 1407-2: 將每單位時間要處理之請求資訊之個數限制為8,000個以下，對應於具有較高重要度之API組，於各伺服器中可每單位時間處理2,000個請求資訊 1409-1: 判斷為超過分配給具有較高資源使用量之API組之資源容量 1409-2: 基於第3處理模型，對應於分配給具有較高資源使用量之API組之資源容量，以可處理之請求資訊之臨界個數為1,000個以內之方式限制該API組之請求資訊處理，對應於具有較高資源使用量之API組，最多可處理1,000個請求資訊
圖1係用以說明能夠實現各種實施例之用於資訊處理之電子裝置之動作方法的資訊處理系統之圖。 圖2係示出各種實施例之裝置節點之構成之圖。 圖3係示出實行本發明所提議之資訊處理方法之電子裝置之構造圖。 圖4係示出各種實施例之用於資訊處理之電子裝置之動作方法的圖。 圖5係示出設定請求資訊處理模型中包括之第1處理模型之一示例之圖。 圖6係示出設定請求資訊處理模型中包括之第2處理模型之一示例之圖。 圖7係示出設定請求資訊處理模型中包括之第3處理模型之一示例之圖。 圖8係示出設定請求資訊處理模型中包括之第4處理模型之一示例之圖。 圖9係示出設定請求資訊處理模型中包括之第5處理模型之一示例之圖。 圖10係示出用以將請求資訊處理模型應用於用於電子裝置100之動作之演算法中之層構造的一示例之圖。 圖11至圖14係示出基於包括第1處理模型至第5處理模型之請求資訊處理模型而處理請求資訊之一示例之圖。
401: 動作 403: 動作

Claims (13)

  1. 一種資訊處理方法，其係藉由電子裝置而處理請求資訊者，其包括如下步驟： 設定與藉由服務而獲得之請求資訊之處理相關之請求資訊處理模型；及 基於上述請求資訊處理模型中包括之至少一個處理模型，處理藉由上述服務而獲得之請求資訊； 上述請求資訊處理模型包括如下模型： 第1處理模型，其基於一個以上之伺服器中每單位時間被處理之請求資訊之個數等於或大於一第一數目之一第一條件被滿足，在與上述服務相關聯之該一個以上之伺服器中包括之各伺服器中，將每單位時間要處理之請求資訊之該個數限制為第1臨界個數以下；及 第2處理模型，基於對應於特定API組中每單位時間被處理之請求資訊之個數等於或大於一第二數目之一第二條件被滿足，其對應於將與上述服務對應之複數個APIs根據重要度來分類之複數個第一API組中之特定API組，於上述各伺服器中將每單位時間要處理之請求資訊之個數限制為第2臨界個數以下。
  2. 如請求項1之資訊處理方法，其中上述請求資訊處理模型包括如下模型： 第3處理模型，其對應於將上述複數個APIs根據資源使用量來分類之複數個第二API組中包括之各API組，將要處理之各請求資訊之個數限制為為了上述各API組而設定之各臨界個數以下。
  3. 如請求項1之資訊處理方法，其中上述請求資訊處理模型包括如下模型： 第4處理模型，其對應於上述服務之用戶而將每單位時間要處理之請求資訊之個數限制為第3臨界個數以下。
  4. 如請求項3之資訊處理方法，其中藉由與上述一個以上之伺服器共同對應之一個外部快取而確認自上述用戶每單位時間獲得之請求資訊之個數。
  5. 如請求項3之資訊處理方法，其中基於上述用戶之識別資訊及上述用戶正在使用中之API之資訊，確認自上述用戶每單位時間獲得之請求資訊之個數。
  6. 如請求項5之資訊處理方法，其進而包括如下步驟： 藉由API標識符而確認上述API之資訊。
  7. 如請求項1之資訊處理方法，其中上述請求資訊處理模型包括如下模型： 第5處理模型，其中斷藉由上述服務而獲得之全部請求資訊之處理。
  8. 如請求項1之資訊處理方法，其中拒絕對如下之請求資訊進行處理：超過基於上述請求資訊處理模型中包括之各處理模型而限制之臨界個數。
  9. 如請求項1之資訊處理方法，其進而包括如下步驟： 設定與上述請求資訊處理模型中包括之各處理模型對應之各處理模型狀態識別資訊；及 基於上述各處理模型狀態識別資訊，根據上述各處理模型而確認拒絕處理之請求資訊之個數。
  10. 如請求項1之資訊處理方法，其中上述至少一個處理模型係基於與上述電子裝置對應之管理者之第1輸入而選擇。
  11. 如請求項1之資訊處理方法，其中上述第1臨界個數及上述第2臨界個數係基於與上述電子裝置對應之管理者之第2輸入而設定。
  12. 如請求項1之資訊處理方法，其進而包括如下步驟： 設定與上述請求資訊處理模型對應之層構造；且 基於上述層構造，上述請求資訊處理模型應用於用於上述電子裝置之動作之演算法中。
  13. 一種電子裝置，其係處理請求資訊者，其包括： 處理器；及 一個以上之記憶體，其儲存一個以上之指令； 上述一個以上之指令於執行時，控制上述處理器以便實行如下步驟： 設定與藉由服務而獲得之請求資訊之處理相關之請求資訊處理模型；及 基於上述請求資訊處理模型中包括之至少一個處理模型，處理藉由上述服務而獲得之請求資訊； 上述請求資訊處理模型包括如下模型： 第1處理模型，其基於一個以上之伺服器中每單位時間被處理之請求資訊之個數等於或大於一第一數目之一第一條件被滿足，在與上述服務相關聯之該一個以上之伺服器中包括之各伺服器中，將每單位時間要處理之請求資訊之該個數限制為第1臨界個數以下；及 第2處理模型，基於對應於特定API組中每單位時間被處理之請求資訊之個數等於或大於一第二數目之一第二條件被滿足，其對應於將與上述服務對應之複數個APIs根據重要度來分類之複數個第一API組中之特定API組，於上述各伺服器中將每單位時間要處理之請求資訊之個數限制為第2臨界個數以下。
TW114107719A 2022-09-15 2023-09-08 處理資訊之電子裝置之動作方法及支持其之電子裝置 TWI894110B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020220116220A KR102918498B1 (ko) 2022-09-15 정보를 처리하는 전자 장치의 동작 방법 및 이를 지원하는 전자 장치
KR10-2022-0116220 2022-09-15

Publications (2)

Publication Number Publication Date
TW202526783A TW202526783A (zh) 2025-07-01
TWI894110B true TWI894110B (zh) 2025-08-11

Family

ID=90275355

Family Applications (2)

Application Number Title Priority Date Filing Date
TW112134201A TWI879074B (zh) 2022-09-15 2023-09-08 處理資訊之電子裝置之動作方法及支持其之電子裝置
TW114107719A TWI894110B (zh) 2022-09-15 2023-09-08 處理資訊之電子裝置之動作方法及支持其之電子裝置

Family Applications Before (1)

Application Number Title Priority Date Filing Date
TW112134201A TWI879074B (zh) 2022-09-15 2023-09-08 處理資訊之電子裝置之動作方法及支持其之電子裝置

Country Status (2)

Country Link
TW (2) TWI879074B (zh)
WO (1) WO2024058294A1 (zh)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040024817A1 (en) * 2002-07-18 2004-02-05 Binyamin Pinkas Selectively restricting access of automated agents to computer services
TW200731136A (en) * 2005-10-20 2007-08-16 Microsoft Corp Load balancing
US20090307353A1 (en) * 2008-06-10 2009-12-10 International Business Machines Corporation Requester-Side Autonomic Governor Method
US9313215B2 (en) * 2011-09-26 2016-04-12 Visa International Service Association Monitoring and limiting requests to access system resources
TW201722109A (zh) * 2015-12-01 2017-06-16 廣達電腦股份有限公司 伺服器資源之管理系統及其管理方法
WO2020000944A1 (zh) * 2018-06-25 2020-01-02 星环信息科技（上海）有限公司 基于抢占式调度的资源共享使用方法、系统及设备
CN113326107A (zh) * 2020-02-28 2021-08-31 中科星图股份有限公司 一种基于Kubernetes集群周期性任务调度的方法及电子设备

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7634542B1 (en) * 2005-07-01 2009-12-15 Sprint Communications Company L.P. System and method to manage service instances for request processing
KR20080079343A (ko) * 2006-12-15 2008-09-01 주식회사 케이티프리텔 이동통신망의 미들웨어 서버를 모니터링하는 서버 및 그방법

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040024817A1 (en) * 2002-07-18 2004-02-05 Binyamin Pinkas Selectively restricting access of automated agents to computer services
TW200731136A (en) * 2005-10-20 2007-08-16 Microsoft Corp Load balancing
US20090307353A1 (en) * 2008-06-10 2009-12-10 International Business Machines Corporation Requester-Side Autonomic Governor Method
US9313215B2 (en) * 2011-09-26 2016-04-12 Visa International Service Association Monitoring and limiting requests to access system resources
TW201722109A (zh) * 2015-12-01 2017-06-16 廣達電腦股份有限公司 伺服器資源之管理系統及其管理方法
WO2020000944A1 (zh) * 2018-06-25 2020-01-02 星环信息科技（上海）有限公司 基于抢占式调度的资源共享使用方法、系统及设备
CN113326107A (zh) * 2020-02-28 2021-08-31 中科星图股份有限公司 一种基于Kubernetes集群周期性任务调度的方法及电子设备

Also Published As

Publication number Publication date
TWI879074B (zh) 2025-04-01
TW202526783A (zh) 2025-07-01
KR20240037558A (ko) 2024-03-22
WO2024058294A1 (ko) 2024-03-21
TW202422451A (zh) 2024-06-01

Similar Documents

Publication Publication Date Title
TWI901037B (zh) 提供資訊之電子裝置之動作方法及支持該方法之電子裝置
KR20240110915A (ko) 아이템 관련 정보 제공을 위한 동작 방법 및 이를 지원하는 전자 장치
TWI890093B (zh) 提供會員資格頁面之方法、支援該方法之電子裝置及包括用於執行該方法之程式之非暫時性電腦可讀記錄媒體
TWI894110B (zh) 處理資訊之電子裝置之動作方法及支持其之電子裝置
TWI900910B (zh) 提供資訊之電子裝置之動作方法及支持其之電子裝置
TWI875282B (zh) 提供資訊之電子裝置之動作方法及支持該動作方法之電子裝置
KR102918498B1 (ko) 정보를 처리하는 전자 장치의 동작 방법 및 이를 지원하는 전자 장치
TWI871045B (zh) 提供資訊之電子裝置之動作方法及支持該動作方法之電子裝置
TWI897071B (zh) 提供資訊之電子裝置之動作方法及支持其之電子裝置
TWI862111B (zh) 提供資訊之電子裝置之動作方法及支持其之電子裝置
TWI897086B (zh) 提供服務之電子裝置之動作方法及支持其之電子裝置
KR102369857B1 (ko) 광고 메시지 제공을 위한 전자 장치의 동작 방법 및 이를 지원하는 전자 장치
TWI899784B (zh) 設定配送任務之分配之電子裝置之動作方法及支持該方法之電子裝置
TWI884898B (zh) 實行快取更新之電子裝置之動作方法及支持其之電子裝置
TWI905682B (zh) 提供物品資訊之方法及用於其之電子裝置
TWI900978B (zh) 提供資訊之電子裝置之動作方法及支援該方法之電子裝置
TWI908492B (zh) 物品信息提供方法及裝置
TWI904908B (zh) 用於設定測試之實行之電子裝置的動作方法及支持其的電子裝置
TWI902645B (zh) 用於組態資訊之電子設備的操作方法及支持其之電子設備
TWI907574B (zh) 用於提供廣告訊息之電子設備的操作方法及支援該操作方法之電子設備
TWI864836B (zh) 提供資訊之電子裝置之動作方法及支持其之電子裝置
TW202501272A (zh) 傳輸資料之電子裝置之動作方法及支持該方法之電子裝置
TW202601489A (zh) 設定配送任務之分配之電子裝置之動作方法及支持該方法之電子裝置
TW202533144A (zh) 提供資訊之電子裝置之動作方法及支持其之電子裝置
TW202441419A (zh) 管理資訊之傳輸之電子裝置之動作方法及支持其之電子裝置