TW201742403A - 分散式系統中節點的處理方法和裝置 - Google Patents

分散式系統中節點的處理方法和裝置 Download PDF

Info

Publication number
TW201742403A
TW201742403A TW106105965A TW106105965A TW201742403A TW 201742403 A TW201742403 A TW 201742403A TW 106105965 A TW106105965 A TW 106105965A TW 106105965 A TW106105965 A TW 106105965A TW 201742403 A TW201742403 A TW 201742403A
Authority
TW
Taiwan
Prior art keywords
service node
node
status information
central
time
Prior art date
Application number
TW106105965A
Other languages
English (en)
Inventor
hai wen Fu
Si Yu Chen
Guo Zhao Wu
Original Assignee
Alibaba Group Services Ltd
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 Alibaba Group Services Ltd filed Critical Alibaba Group Services Ltd
Publication of TW201742403A publication Critical patent/TW201742403A/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0677—Localisation of faults
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0882—Utilisation of link capacity
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H04L41/064—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis involving time analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • General Engineering & Computer Science (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Hardware Redundancy (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申請實施例提供了一種分散式系統中節點的處理方法和裝置，所述節點包括服務節點和中心節點，所述的方法包括：獲取所述服務節點的存活狀態資訊；獲取所述中心節點的當前系統資訊；採用所述存活狀態資訊和所述當前系統資訊，確定所述服務節點是否存在異常；若所述服務節點存在異常，則獲取所述中心節點的中心狀態資訊；依據所述中心狀態資訊處理所述存在異常的服務節點。本申請實施例能夠綜合中心節點自身的狀態，適應性處理存在異常的服務節點，減少因為中心節點自身的問題導致服務節點狀態誤判情況，降低了中心節點出錯的機率。

Description

分散式系統中節點的處理方法和裝置
本申請係關於資料處理技術領域，特別是關於一種分散式系統中節點的處理方法和一種分散式系統中節點的處理裝置。
分散式系統是由地理上和物理上分散的各自獨立的一個或多個節點組成的系統，節點包括有服務節點和中心節點。中心節點能夠對於服務節點進行統籌調配。這些節點連接在一起可以實現對資源的共用，分散式系統相當於一個統一的整體。
在分散式系統運作過程中，對服務節點的存活狀態的監控是非常重要的一個環節，通常的做法是，在分散式系統中的每一個服務節點都以預定週期向中心節點發送存活狀態資訊，中心節點接收到存活狀態資訊後，用以更新其狀態資訊表。其中，狀態資訊表中記錄了服務節點的最新更新時間和下次更新時間。中心節點為了監控服務節點的存活狀態，將不時查看狀態資訊表確認服務節點的存活狀態，如果發現服務節點的下次更新時間小於當前系統時 間，便可以判定該服務節點狀態異常。
參照圖1所示的一種分散式系統中心節點和服務節點的工作流程示意圖，該系統的中心節點能夠對於服務節點進行管控，服務節點會定期將其存活狀態資訊上報給中心節點，中心節點則根據存活狀態資訊確認服務節點的存活狀態，如果發現狀態異常的服務節點時進行失效處理流程。然而，中心節點有可能因為網路延時而不能及時接收到服務節點上報的存活狀態資訊，或者，有可能因為系統資源負荷過大而不能及時處理存活狀態資訊，這些情況都有可能導致服務節點的存活狀態資訊丟失，或者，下次更新時間失效等問題，那麼可能會出現中心節點誤判服務節點存活狀態的情況。
鑒於上述問題，提出了本申請實施例以便提供一種克服上述問題或者至少部分地解決上述問題的一種分散式系統中節點的處理方法和相應的一種分散式系統中節點的處理裝置。
為了解決上述問題，本申請實施例公開了一種分散式系統中節點的處理方法，所述節點包括服務節點和中心節點，所述的方法包括：獲取所述服務節點的存活狀態資訊；獲取所述中心節點的當前系統資訊；採用所述存活狀態資訊和所述當前系統資訊，確定所 述服務節點是否存在異常；若所述服務節點存在異常，則獲取所述中心節點的中心狀態資訊；依據所述中心狀態資訊處理所述存在異常的服務節點。
較佳地，所述分散式系統中包括狀態資訊表，所述獲取服務節點的存活狀態資訊包括：接收所述服務節點上傳的存活狀態資訊；採用所述服務節點的存活狀態資訊更新所述狀態資訊表。
較佳地，所述存活狀態資訊包括服務節點的下次更新時間，所述當前系統資訊包括所述中心節點的當前系統時間，所述採用存活狀態資訊和所述當前系統資訊，確定所述服務節點是否存在異常的步驟包括：當達到預設時間時，遍歷所述狀態資訊表中的下次更新時間；採用所述下次更新時間和所述當前系統時間確定所述服務節點是否存在異常。
較佳地，所述採用下次更新時間和所述當前系統時間確定所述服務節點是否存在異常的步驟包括：判斷所述下次更新時間是否小於所述當前系統時間；若是，則將所述服務節點確定為存在異常；若否，則將所述服務節點確定為不存在異常。
較佳地，所述中心狀態資訊包括網路繁忙情況資料和 /或系統資源使用情況資料，所述依據中心狀態資訊處理所述存在異常的服務節點的步驟包括：採用所述網路繁忙情況資料和/或系統資源使用情況資料確定所述中心節點是否負荷過重；若是，則更新所述狀態資訊表中所述存在異常的服務節點的存活狀態資訊。
較佳地，所述網路繁忙情況資料包括網路吞吐量和網路丟包率，所述系統資源使用情況資料包括系統的平均負荷，所述採用網路繁忙情況資料和/或系統資源使用情況資料確定所述中心節點是否負荷過重的步驟包括：判斷所述網路吞吐量是否大於等於網路頻寬；判斷所述網路丟包率大於預設丟包率；判斷所述系統的平均負荷是否大於預設負荷閾值；若所述網路吞吐量大於等於網路頻寬，和/或，所述網路丟包率大於預設丟包率，和/或，所述系統的平均負荷大於預設負荷閾值，則確定所述中心節點負荷過重。
較佳地，所述更新狀態資訊表中所述存在異常的服務節點的存活狀態資訊的步驟包括：延長所述狀態資訊表中所述存在異常的服務節點的下次更新時間。
較佳地，所述更新狀態資訊表中所述存在異常的服務節點的存活狀態資訊的步驟包括：向所述服務節點發送更新請求；接收所述服務節點針對所述更新請求上傳的新的存活 狀態資訊；所述新的存活狀態資訊中包括新的下次更新時間；採用所述新的下次更新時間更新所述狀態資訊表中所述存在異常的服務節點的下次更新時間。
較佳地，所述的方法還包括：若所述服務節點不存在異常，則將所述服務節點作為失效的服務節點。
較佳地，所述將服務節點作為失效的服務節點的步驟之後，還包括：在所述中心節點中刪除所述失效的服務節點；通知所述分散式系統中其他服務節點所述失效的服務節點。
本申請實施例還公開了一種分散式系統中節點的處理裝置，所述節點包括服務節點和中心節點，所述的裝置包括：存活狀態資訊獲取模組，用於獲取所述服務節點的存活狀態資訊；當前系統資訊獲取模組，用於獲取所述中心節點的當前系統資訊；服務節點異常確定模組，用於採用所述存活狀態資訊和所述當前系統資訊，確定所述服務節點是否存在異常；若所述服務節點存在異常，則調用中心狀態資訊獲取模組；中心狀態資訊獲取模組，用於獲取所述中心節點的中 心狀態資訊；異常服務節點處理模組，用於依據所述中心狀態資訊處理所述存在異常的服務節點。
較佳地，所述分散式系統中包括狀態資訊表，所述存活狀態資訊獲取模組包括：存活狀態資訊接收子模組，用於接收所述服務節點上傳的存活狀態資訊；第一狀態資訊表更新子模組，用於採用所述服務節點的存活狀態資訊更新所述狀態資訊表。
較佳地，所述存活狀態資訊包括服務節點的下次更新時間，所述當前系統資訊包括所述中心節點的當前系統時間，所述服務節點異常確定模組包括：狀態資訊表遍歷子模組，用於當達到預設時間時，遍歷所述狀態資訊表中的下次更新時間；服務節點異常確定子模組，用於採用所述下次更新時間和所述當前系統時間確定所述服務節點是否存在異常。
較佳地，所述服務節點異常確定子模組包括：時間判斷單元，用於判斷所述下次更新時間是否小於所述當前系統時間；若是，則調用第一確定單元，若否，則調用第二確定單元；第一確定單元，用於將所述服務節點確定為存在異常；第二確定單元，用於將所述服務節點確定為不存在異常。
較佳地，所述中心狀態資訊包括網路繁忙情況資料和/或系統資源使用情況資料，所述異常服務節點處理模組包括：中心節點狀態確定子模組，用於採用所述網路繁忙情況資料和/或系統資源使用情況資料確定所述中心節點是否負荷過重；若是，則調用第二狀態資訊表更新子模組；第二狀態資訊表更新子模組，用於更新所述狀態資訊表中所述存在異常的服務節點的存活狀態資訊。
較佳地，所述網路繁忙情況資料包括網路吞吐量和網路丟包率，所述系統資源使用情況資料包括系統的平均負荷，所述中心節點狀態確定子模組包括：第一網路繁忙情況判斷單元，用於判斷所述網路吞吐量是否大於等於網路頻寬；第二網路繁忙情況判斷單元，用於判斷所述網路丟包率大於預設丟包率；系統資源使用情況判斷單元，用於判斷所述系統的平均負荷是否大於預設負荷閾值；中心節點負荷確定單元，用於在所述網路吞吐量大於等於網路頻寬，和/或，所述網路丟包率大於預設丟包率，和/或，所述系統的平均負荷大於預設負荷閾值時，確定所述中心節點負荷過重。
較佳地，所述第二狀態資訊表更新子模組包括：下次更新時間延長單元，用於延長所述狀態資訊表中所述存在異常的服務節點的下次更新時間。
較佳地，所述第二狀態資訊表更新子模組包括：更新請求發送單元，用於向所述服務節點發送更新請求；下次更新時間接收單元，用於接收所述服務節點針對所述更新請求上傳的新的存活狀態資訊；所述新的存活狀態資訊中包括新的下次更新時間；下次更新時間更新單元，用於採用所述新的下次更新時間更新所述狀態資訊表中所述存在異常的服務節點的下次更新時間。
較佳地，所述的裝置還包括：失效服務節點確定模組，用於在所述服務節點不存在異常時，將所述服務節點作為失效的服務節點。
較佳地，所述的裝置還包括：失效服務節點刪除模組，用於在所述中心節點中刪除所述失效的服務節點；失效服務節點通知模組，用於通知所述分散式系統中其他服務節點所述失效的服務節點。
本申請實施例包括以下優點：本申請實施例的分散式系統中，中心節點根據服務節點上報的存活狀態資訊以及中心節點自身的當前系統資訊，來確認服務節點是否存在異常，當確定服務節點存在異常時，中心節點將進一步根據自身的狀態資訊，對於存在異常的服務節點進行處理。應用本申請實施例，能夠綜合中心節點自身的狀態，適應性處理存在異常的服務節 點，減少因為中心節點自身的問題導致服務節點狀態誤判情況，降低了中心節點出錯的機率。
301‧‧‧存活狀態資訊獲取模組
302‧‧‧當前系統資訊獲取模組
303‧‧‧服務節點異常確定模組
304‧‧‧中心狀態資訊獲取模組
305‧‧‧異常服務節點處理模組
圖1是一種分散式系統中心節點和服務節點的工作流程示意圖；圖2是本申請的一種分散式系統中節點的處理方法實施例1的步驟流程圖；圖3是本申請的一種分散式系統中節點的處理方法實施例2的步驟流程圖；圖4是本申請的一種分散式系統中心節點和服務節點的工作步驟流程圖；圖5是本申請的一種分散式系統中心節點和服務節點的工作原理示意圖；圖6是本申請的一種分散式系統中節點的處理裝置實施例的結構框圖。
為使本申請的上述目的、特徵和優點能夠更加明顯易懂，下面結合附圖和具體實施方式對本申請作進一步詳細的說明。
參照圖2，示出了本申請的一種分散式系統中節點的處理方法實施例1的步驟流程圖，所述節點可以包括服務節點和中心節點，所述的方法具體可以包括如下步驟： 步驟101，獲取所述服務節點的存活狀態資訊；在具體實現中，服務節點是指分散式系統中具有儲存功能或者業務處理功能的節點，通常為伺服器等設備，中心節點則是指分散式系統中具有統籌調配服務節點功能的節點，通常為控制器等設備。需要說明的是，本申請實施例除了適用於分散式系統外，也適用於存在有節點能夠對於其他節點進行管控的系統，本申請實施例對此並不加以限制。
在本申請的一種較佳實施例中，所述分散式系統中可以包括狀態資訊表，所述步驟101可以包括如下子步驟：子步驟S11，接收所述服務節點上傳的存活狀態資訊；子步驟S12，採用所述服務節點的存活狀態資訊更新所述狀態資訊表。
在具體實現中，服務節點由中心節點統籌調配，故中心節點需要知道服務節點是否正常工作。可以理解，服務節點作為具有儲存、業務等功能的設備需要執行很多工，而在執行任務的過程中可能由於任務過多、剩餘記憶體過小等原因出現任務重複執行，系統故障等現象，因此服務節點需要上報存活狀態資訊，以告知中心節點是否存在異常或者失效，中心節點則將根據服務節點是否存在異常或者失效來進行相應的處理。
在本申請的一種示例中，中心節點處儲存有狀態資訊表，該表用於儲存能夠反映服務節點存活狀態的存活狀態 資訊。服務節點會定期上報其存活狀態資訊，中心節點則將存活狀態資訊保存到狀態資訊表，並據此對於該服務節點的節點狀態進行更新。當然，存活狀態資訊也可以由中心節點在空閒時發送請求至服務節點，以要求其上報其存活狀態資訊，本申請實施例對此不加以限制。
步驟102，獲取所述中心節點的當前系統資訊；步驟103，採用所述存活狀態資訊和所述當前系統資訊，確定所述服務節點是否存在異常；若所述服務節點存在異常，則執行步驟104；在本申請的一種較佳實施例中，所述存活狀態資訊可以包括服務節點的下次更新時間，所述當前系統資訊可以包括所述中心節點的當前系統時間，所述步驟103可以包括如下子步驟：子步驟S21，當達到預設時間時，遍歷所述狀態資訊表中的下次更新時間；子步驟S22，採用所述下次更新時間和所述當前系統時間確定所述服務節點是否存在異常。
在本申請的一種示例中，狀態資訊表中儲存有服務節點的下次更新時間，下次更新時間是服務節點根據自身任務調度情況，上報給中心節點，其下次進行存活狀態更新的時間。例如，服務節點根據自身任務調度情況，確定下次更新時間為2016.02.24，如果該服務節點無異常，應當於2016.02.24之前上報存活狀態資訊至中心節點。此外，當前系統資訊則可以包括中心節點對於服務節點進行異常 判斷時的當前系統時間，例如，當前系統時間可以為2016.02.25。
需要說明的是，上述對於下次更新時間和當前系統時間僅僅是作為舉例，在具體應用中，下次更新時間和當前系統時間的時間單位可以精確到時分秒，或者粗略到月年，本申請實施例對此並不加以限制。
當達到預設時間時，開始檢測服務節點是否存在異常。具體來說，中心節點開始獲取其當前系統時間，遍歷狀態資訊表中的下次更新時間並與當前系統時間一一進行比對，以此確定服務節點是否存在異常。其中，遍歷狀態資訊表的週期可以設定為固定的週期，例如：30秒，1分鐘，10分鐘，或者20分鐘等等，也可由業務需求來決定遍歷的時間。
在本申請的一種較佳實施例中，所述子步驟S22可以包括如下子步驟：子步驟S22-11，判斷所述下次更新時間是否小於所述當前系統時間；若是，則執行子步驟S22-12，若否，則執行子步驟S22-13；子步驟S22-12，將所述服務節點確定為存在異常；子步驟S22-13，將所述服務節點確定為不存在異常。
服務節點是否存在異常，可通過判斷服務節點的下次更新時間是否小於中心節點的當前系統時間，可以理解，下次更新時間是服務節點下一次上報存活狀態資訊的時間，因此，如果下次更新時間小於當前系統時間，則說明 該服務節點已經超過應當上報的時間，則可以確定為存在異常，如果下次更新時間大於或等於當前系統時間，則說明該服務節點尚未超過應當上報的時間，則可以確定為不存在異常。
步驟104，獲取所述中心節點的中心狀態資訊；步驟105，依據所述中心狀態資訊處理所述存在異常的服務節點。
本申請實施例在確定存在異常的服務節點時，考慮到中心節點自身的狀態也可能會影響到服務節點異常的判斷，因此，還將結合中心節點自身的中心狀態資訊，以此來進一步處理存在異常的服務節點。
本申請實施例的分散式系統中，中心節點根據服務節點上報的存活狀態資訊以及中心節點自身的當前系統資訊，來確認服務節點是否存在異常，當確定服務節點存在異常時，中心節點將進一步根據自身的中心狀態資訊，對於存在異常的服務節點進行處理。
應用本申請實施例，能夠綜合中心節點自身的狀態，適應性處理存在異常的服務節點，減少因為中心節點自身的問題導致服務節點狀態誤判情況，降低了中心節點出錯的機率。
參照圖3，示出了本申請的一種分散式系統中節點的處理方法實施例2的步驟流程圖，所述節點可以包括服務節點和中心節點，所述的方法具體可以包括如下步驟：步驟201，獲取所述服務節點的存活狀態資訊； 步驟202，獲取所述中心節點的當前系統資訊；步驟203，採用所述存活狀態資訊和所述當前系統資訊，確定所述服務節點是否存在異常；若所述服務節點存在異常，則執行步驟204，若所述服務節點不存在異常，則執行步驟207；步驟204，獲取所述中心節點的中心狀態資訊；所述中心狀態資訊可以包括網路繁忙情況資料和/或系統資源使用情況資料；步驟205，採用所述網路繁忙情況資料和/或系統資源使用情況資料確定所述中心節點是否負荷過重；若是，則執行步驟206；在本申請具體應用的一種示例中，所述網路繁忙情況資料可以體現為網路吞吐量和網路丟包率，所述系統資源使用情況資料可以體現為系統的平均負荷。
具體來說，網路吞吐量簡稱為吞吐量，是指任意給定時刻通過一個網路(或者某個通道、某個結點)所成功傳輸的資料量。吞吐量取決於中心節點網路當前的可用頻寬，並受網路頻寬的限制，吞吐量常常是在實際的網路工程中進行網路測試的一個重要指標，例如可用以衡量網路設備的性能。網路丟包率指所丟失資料量占所發送資料量的比率。丟包率與網路負荷、資料長度以及資料發送頻率等相關。系統平均負荷(load average)是指在特定時間間隔內，中心節點所運行佇列中的平均進程數。
在本申請的一種較佳實施例中，所述步驟205可以包 括如下子步驟：子步驟S31，判斷所述網路吞吐量是否大於等於網路頻寬；子步驟S32，判斷所述網路丟包率大於預設丟包率；子步驟S33，判斷所述系統的平均負荷是否大於預設負荷閾值；若所述網路吞吐量大於等於網路頻寬，和/或，所述網路丟包率大於預設丟包率，和/或，所述系統的平均負荷大於預設閾值，則執行子步驟S34；子步驟S34，確定所述中心節點負荷過重。
在本申請具體應用的一種示例中，計算中心節點網路繁忙情況的公式為：網路吞吐量頻寬，或者，網路丟包率>N%；其中：N的取值範圍為：1-100。
計算中心節點系統資源使用情況的公式為：系統資源使用情況=系統load average(平均負荷)值>N；其中：N為整數，一般N>1。
在本申請實施例中，基於中心節點的網路忙碌情況資料和系統資源使用情況資料進行判斷，若這這些資料中的某些或者全部達到某些臨界值，說明中心節點負荷過重，則其在先的判定為異常的服務節點不一定是失效的服務節點，那麼需要延長該服務節點的下次更新時間；反之，說明中心節點負荷正常，則其在先判定為異常的服務節點是應當是無效的服務節點。這樣通過結合中心節點自身狀 態，可減少由於中心節點自身原因所造成對服務節點的誤判。
步驟206，更新所述狀態資訊表中所述存在異常的服務節點的存活狀態資訊；在本申請的一種較佳實施例中，所述步驟206可以包括如下子步驟：子步驟S41，延長所述狀態資訊表中所述存在異常的服務節點的下次更新時間。
在本申請實施例中，中心節點結合自身的節點網路繁忙情況和系統資源使用情況來進行服務節點的失效判定，如果網路非常繁忙或者系統資源繁忙，則此時中心節點對於服務節點的失效判定可信度較低，例如有可能由於資源繁忙而對於存活狀態資訊表中服務節點存活狀態更新失效，此時可對於中心節點的判斷不予採納，判定中心節點處理失敗，同時相應延長狀態資訊表裡的在先判定為異常服務節點的下次更新時間。
在本申請的一種較佳實施例中，所述步驟206可以包括如下子步驟：子步驟S51，向所述服務節點發送更新請求；子步驟S52，接收所述服務節點針對所述更新請求上傳的新的存活狀態資訊；所述新的存活狀態資訊中包括新的下次更新時間；子步驟S53，採用所述新的下次更新時間更新所述狀態資訊表中所述存在異常的服務節點的下次更新時間。 中心節點可根據自身狀態來自動延長服務節點的下次更新時間，或者，主動向服務節點發起狀態更新的請求來延長服務節點的下次更新時間，減少因為中心節點自身問題導致服務節點狀態誤判情況出現。
本申請的一種示例中，針對在先判定為存在異常的服務節點的下次更新時間，可以由中心節點向該服務節點發送更新請求，服務節點接收到請求後，根據自身任務調度情況，重新上報新的下次更新時間，中心節點則採用該新的下次更新時間對於狀態資訊表進行更新，以延長服務節點的下次更新時間。
步驟207，將所述服務節點作為失效的服務節點。
在本申請的一種較佳實施例中，所述將服務節點作為失效的服務節點的步驟之後，還包括：在所述中心節點中刪除所述失效的服務節點；通知所述分散式系統中其他服務節點所述失效的服務節點。
在本申請實施例中，如果確定服務節點為失效，則可以將該失效的服務節點在中心節點中相關資訊刪除，例如註冊表。除此之外，還可以通知分散式系統內其他服務節點該失效的服務節點的相關資訊，例如，該失效的服務節點的IP位址，服務節點接到通知後，可以在本地清除該失效的服務節點的相關資訊。
為使本領域技術人員更好地理解本申請實施例，以下採用具體的實例對於分散式系統中節點狀態的監控處理方 式進行說明，參照圖4所示的本申請的一種分散式系統中心節點和服務節點的工作流程示意圖，以及，圖5所示的一種分散式系統中心節點和服務節點的工作原理示意圖，具體的步驟如下所示：S1、程式啟動；S2、服務節點將存活狀態資訊上報到中心節點；S3、中心節點根據服務節點上報的存活狀態資訊對於狀態資訊表進行更新，更新內容包括有：最新更新時間和下次更新時間；S4、中心節點掃描存活狀態資訊表；S5、判斷某個服務節點的下次更新時間是否小於當前系統時間，如果是，執行S6，如果否，則返回S4，繼續掃描存活狀態資訊表；S6、中心節點判斷自身的節點網路繁忙情況和系統資源使用情況，如果網路非常繁忙或者系統資源繁忙，延長存活狀態資訊表中服務節點的下次更新時間；S7、啟動服務節點的失效流程處理。
在本申請實施例中，中心節點結合自身狀態，對於服務節點進行失效判定，能夠減少因中心節點的網路擁堵或者系統資源問題導致沒有更新節點狀態資訊表所導致的誤判情況出現，降低了中心節點出錯的機率。
需要說明的是，對於方法實施例，為了簡單描述，故將其都表述為一系列的動作組合，但是本領域技術人員應該知悉，本申請實施例並不受所描述的動作順序的限制， 因為依據本申請實施例，某些步驟可以採用其他順序或者同時進行。其次，本領域技術人員也應該知悉，說明書中所描述的實施例均屬於較佳實施例，所涉及的動作並不一定是本申請實施例所必須的。
參照圖6，示出了本申請的一種分散式系統中節點的處理裝置實施例的結構框圖，所述節點包括服務節點和中心節點，所述的裝置具體可以包括如下模組：存活狀態資訊獲取模組301，用於獲取所述服務節點的存活狀態資訊；在本申請的一種較佳實施例中，所述分散式系統中包括狀態資訊表，所述存活狀態資訊獲取模組301可以包括如下子模組：存活狀態資訊接收子模組，用於接收所述服務節點上傳的存活狀態資訊；第一狀態資訊表更新子模組，用於採用所述服務節點的存活狀態資訊更新所述狀態資訊表。
當前系統資訊獲取模組302，用於獲取所述中心節點的當前系統資訊；服務節點異常確定模組303，用於採用所述存活狀態資訊和所述當前系統資訊，確定所述服務節點是否存在異常；若所述服務節點存在異常，則調用中心狀態資訊獲取模組；在本申請的一種較佳實施例中，所述存活狀態資訊包括服務節點的下次更新時間，所述當前系統資訊包括所述 中心節點的當前系統時間，所述服務節點異常確定模組303可以包括如下子模組：狀態資訊表遍歷子模組，用於當達到預設時間時，遍歷所述狀態資訊表中的下次更新時間；服務節點異常確定子模組，用於採用所述下次更新時間和所述當前系統時間確定所述服務節點是否存在異常。
在本申請的一種較佳實施例中，所述服務節點異常確定子模組包括：時間判斷單元，用於判斷所述下次更新時間是否小於所述當前系統時間；若是，則調用第一確定單元，若否，則調用第二確定單元；第一確定單元，用於將所述服務節點確定為存在異常；第二確定單元，用於將所述服務節點確定為不存在異常。
中心狀態資訊獲取模組304，用於獲取所述中心節點的中心狀態資訊；異常服務節點處理模組305，用於依據所述中心狀態資訊處理所述存在異常的服務節點。
在本申請的一種較佳實施例中，所述中心狀態資訊包括網路繁忙情況資料和/或系統資源使用情況資料，所述異常服務節點處理模組305包括：中心節點狀態確定子模組，用於採用所述網路繁忙情況資料和/或系統資源使用情況資料確定所述中心節點是 否負荷過重；若是，則調用第二狀態資訊表更新子模組；第二狀態資訊表更新子模組，用於更新所述狀態資訊表中所述存在異常的服務節點的存活狀態資訊。
在本申請的一種較佳實施例中，所述網路繁忙情況資料包括網路吞吐量，所述系統資源使用情況資料包括系統的平均負荷，所述中心節點狀態確定子模組包括： 第一網路繁忙情況判斷單元，用於判斷所述網路吞吐量是否大於等於網路頻寬；第二網路繁忙情況判斷單元，用於判斷所述網路丟包率大於預設丟包率；系統資源使用情況判斷單元，用於判斷所述系統的平均負荷是否大於預設負荷閾值；中心節點負荷確定單元，用於在所述網路吞吐量大於等於網路頻寬，和/或，所述網路丟包率大於預設丟包率，和/或，所述系統的平均負荷大於預設負荷閾值時，確定所述中心節點負荷過重。
在本申請的一種較佳實施例中，所述第二狀態資訊表更新子模組包括：下次更新時間延長單元，用於延長所述狀態資訊表中所述存在異常的服務節點的下次更新時間；在本申請的另一種較佳實施例中，所述第二狀態資訊表更新子模組包括：更新請求發送單元，用於向所述服務節點發送更新請求； 下次更新時間接收單元，用於接收所述服務節點針對所述更新請求上傳的新的存活狀態資訊；所述新的存活狀態資訊中包括新的下次更新時間；下次更新時間更新單元，用於採用所述新的下次更新時間更新所述狀態資訊表中所述存在異常的服務節點的下次更新時間。
在本申請的一種較佳實施例中，所述的裝置還包括：失效服務節點確定模組，用於在所述服務節點不存在異常時，將所述服務節點作為失效的服務節點。
在本申請的一種較佳實施例中，所述的裝置還包括：失效服務節點刪除模組，用於在所述中心節點中刪除所述失效的服務節點；失效服務節點通知模組，用於通知所述分散式系統中其他服務節點所述失效的服務節點。
對於裝置實施例而言，由於其與方法實施例基本相似，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。
本說明書中的各個實施例均採用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似的部分互相參見即可。
本領域內的技術人員應明白，本申請實施例的實施例可提供為方法、裝置、或電腦程式產品。因此，本申請實施例可採用完全硬體實施例、完全軟體實施例、或結合軟體和硬體方面的實施例的形式。而且，本申請實施例可採 用在一個或多個其中包含有電腦可用程式碼的電腦可用儲存媒體(包括但不限於磁碟記憶體、CD-ROM、光學記憶體等)上實施的電腦程式產品的形式。
在一個典型的配置中，所述電腦設備包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和記憶體。記憶體可能包括電腦可讀媒體中的非永久性記憶體，隨機存取記憶體(RAM)和/或非易失性記憶體等形式，如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。記憶體是電腦可讀媒體的示例。電腦可讀媒體包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存媒體的例子包括，但不限於相變記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可擦除可程式設計唯讀記憶體(EEPROM)、快閃記憶體或其他記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存、磁盒式磁帶，磁帶磁片儲存或其他磁性存放裝置或任何其他非傳輸媒體，可用於儲存可以被計算設備訪問的資訊。按照本文中的界定，電腦可讀媒體不包括非持續性的電腦可讀媒體(transitory media)，如調製的資料信號和載波。
本申請實施例是參照根據本申請實施例的方法、終端設備(系統)、和電腦程式產品的流程圖和/或方框圖來描 述的。應理解可由電腦程式指令實現流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結合。可提供這些電腦程式指令到通用電腦、專用電腦、嵌入式處理機或其他可程式設計資料處理終端設備的處理器以產生一個機器，使得通過電腦或其他可程式設計資料處理終端設備的處理器執行的指令產生用於實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。
這些電腦程式指令也可儲存在能引導電腦或其他可程式設計資料處理終端設備以特定方式工作的電腦可讀記憶體中，使得儲存在該電腦可讀記憶體中的指令產生包括指令裝置的製造品，該指令裝置實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。
這些電腦程式指令也可裝載到電腦或其他可程式設計資料處理終端設備上，使得在電腦或其他可程式設計終端設備上執行一系列操作步驟以產生電腦實現的處理，從而在電腦或其他可程式設計終端設備上執行的指令提供用於實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。
儘管已描述了本申請實施例的較佳實施例，但本領域內的技術人員一旦得知了基本創造性概念，則可對這些實施例做出另外的變更和修改。所以，所附申請專利範圍意欲解釋為包括較佳實施例以及落入本申請實施例範圍的所有變更和修改。
最後，還需要說明的是，在本文中，諸如第一和第二等之類的關係術語僅僅用來將一個實體或者操作與另一個實體或操作區分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關係或者順序。而且，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者終端設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者終端設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，並不排除在包括所述要素的過程、方法、物品或者終端設備中還存在另外的相同要素。
以上對本申請所提供的一種分散式系統中節點的處理方法和一種分散式系統中節點的處理裝置，進行了詳細介紹，本文中應用了具體個例對本申請的原理及實施方式進行了闡述，以上實施例的說明只是用於幫助理解本申請的方法及其核心思想；同時，對於本領域的一般技術人員，依據本申請的思想，在具體實施方式及應用範圍上均會有改變之處，綜上所述，本說明書內容不應理解為對本申請的限制。

Claims (20)

  1. 一種分散式系統中節點的處理方法，其特徵在於，所述節點包括服務節點和中心節點，所述的方法包括：獲取所述服務節點的存活狀態資訊；獲取所述中心節點的當前系統資訊；採用所述存活狀態資訊和所述當前系統資訊，確定所述服務節點是否存在異常；若所述服務節點存在異常，則獲取所述中心節點的中心狀態資訊；依據所述中心狀態資訊處理所述存在異常的服務節點。
  2. 根據申請專利範圍第1項所述的方法，其中，所述分散式系統中包括狀態資訊表，所述獲取服務節點的存活狀態資訊包括：接收所述服務節點上傳的存活狀態資訊；採用所述服務節點的存活狀態資訊更新所述狀態資訊表。
  3. 根據申請專利範圍第1或2項所述的方法，其中，所述存活狀態資訊包括服務節點的下次更新時間，所述當前系統資訊包括所述中心節點的當前系統時間，所述採用存活狀態資訊和所述當前系統資訊，確定所述服務節點是否存在異常的步驟包括：當達到預設時間時，遍歷所述狀態資訊表中的下次更 新時間；採用所述下次更新時間和所述當前系統時間確定所述服務節點是否存在異常。
  4. 根據申請專利範圍第3項所述的方法，其中，所述採用下次更新時間和所述當前系統時間確定所述服務節點是否存在異常的步驟包括：判斷所述下次更新時間是否小於所述當前系統時間；若是，則將所述服務節點確定為存在異常；若否，則將所述服務節點確定為不存在異常。
  5. 根據申請專利範圍第1或2項所述的方法，其中，所述中心狀態資訊包括網路繁忙情況資料和/或系統資源使用情況資料，所述依據中心狀態資訊處理所述存在異常的服務節點的步驟包括：採用所述網路繁忙情況資料和/或系統資源使用情況資料確定所述中心節點是否負荷過重；若是，則更新所述狀態資訊表中所述存在異常的服務節點的存活狀態資訊。
  6. 根據申請專利範圍第5項所述的方法，其中，所述網路繁忙情況資料包括網路吞吐量和網路丟包率，所述系統資源使用情況資料包括系統的平均負荷，所述採用網路繁忙情況資料和/或系統資源使用情況資料確定所述中心節點是否負荷過重的步驟包括：判斷所述網路吞吐量是否大於等於網路頻寬；判斷所述網路丟包率大於預設丟包率； 判斷所述系統的平均負荷是否大於預設負荷閾值；若所述網路吞吐量大於等於網路頻寬，和/或，所述網路丟包率大於預設丟包率，和/或，所述系統的平均負荷大於預設負荷閾值，則確定所述中心節點負荷過重。
  7. 根據申請專利範圍第5項所述的方法，其中，所述更新狀態資訊表中所述存在異常的服務節點的存活狀態資訊的步驟包括：延長所述狀態資訊表中所述存在異常的服務節點的下次更新時間。
  8. 根據申請專利範圍第5項所述的方法，其中，所述更新狀態資訊表中所述存在異常的服務節點的存活狀態資訊的步驟包括：向所述服務節點發送更新請求；接收所述服務節點針對所述更新請求上傳的新的存活狀態資訊；所述新的存活狀態資訊中包括新的下次更新時間；採用所述新的下次更新時間更新所述狀態資訊表中所述存在異常的服務節點的下次更新時間。
  9. 根據申請專利範圍第1項所述的方法，其中，還包括：若所述服務節點不存在異常，則將所述服務節點作為失效的服務節點。
  10. 根據申請專利範圍第1項所述的方法，其中，所述將服務節點作為失效的服務節點的步驟之後，還包括： 在所述中心節點中刪除所述失效的服務節點；通知所述分散式系統中其他服務節點所述失效的服務節點。
  11. 一種分散式系統中節點的處理裝置，其特徵在於，所述節點包括服務節點和中心節點，所述的裝置包括：存活狀態資訊獲取模組，用於獲取所述服務節點的存活狀態資訊；當前系統資訊獲取模組，用於獲取所述中心節點的當前系統資訊；服務節點異常確定模組，用於採用所述存活狀態資訊和所述當前系統資訊，確定所述服務節點是否存在異常；若所述服務節點存在異常，則調用中心狀態資訊獲取模組；中心狀態資訊獲取模組，用於獲取所述中心節點的中心狀態資訊；異常服務節點處理模組，用於依據所述中心狀態資訊處理所述存在異常的服務節點。
  12. 根據申請專利範圍第11項所述的裝置，其中，所述分散式系統中包括狀態資訊表，所述存活狀態資訊獲取模組包括：存活狀態資訊接收子模組，用於接收所述服務節點上傳的存活狀態資訊；第一狀態資訊表更新子模組，用於採用所述服務節點 的存活狀態資訊更新所述狀態資訊表。
  13. 根據申請專利範圍第11或12項所述的裝置，其中，所述存活狀態資訊包括服務節點的下次更新時間，所述當前系統資訊包括所述中心節點的當前系統時間，所述服務節點異常確定模組包括：狀態資訊表遍歷子模組，用於當達到預設時間時，遍歷所述狀態資訊表中的下次更新時間；服務節點異常確定子模組，用於採用所述下次更新時間和所述當前系統時間確定所述服務節點是否存在異常。
  14. 根據申請專利範圍第13項所述的裝置，其中，所述服務節點異常確定子模組包括：時間判斷單元，用於判斷所述下次更新時間是否小於所述當前系統時間；若是，則調用第一確定單元，若否，則調用第二確定單元；第一確定單元，用於將所述服務節點確定為存在異常；第二確定單元，用於將所述服務節點確定為不存在異常。
  15. 根據申請專利範圍第11或12項所述的裝置，其中，所述中心狀態資訊包括網路繁忙情況資料和/或系統資源使用情況資料，所述異常服務節點處理模組包括：中心節點狀態確定子模組，用於採用所述網路繁忙情況資料和/或系統資源使用情況資料確定所述中心節點是否負荷過重；若是，則調用第二狀態資訊表更新子模組； 第二狀態資訊表更新子模組，用於更新所述狀態資訊表中所述存在異常的服務節點的存活狀態資訊。
  16. 根據申請專利範圍第15項所述的裝置，其中，所述網路繁忙情況資料包括網路吞吐量和網路丟包率，所述系統資源使用情況資料包括系統的平均負荷，所述中心節點狀態確定子模組包括：第一網路繁忙情況判斷單元，用於判斷所述網路吞吐量是否大於等於網路頻寬；第二網路繁忙情況判斷單元，用於判斷所述網路丟包率大於預設丟包率；系統資源使用情況判斷單元，用於判斷所述系統的平均負荷是否大於預設負荷閾值；中心節點負荷確定單元，用於在所述網路吞吐量大於等於網路頻寬，和/或，所述網路丟包率大於預設丟包率，和/或，所述系統的平均負荷大於預設負荷閾值時，確定所述中心節點負荷過重。
  17. 根據申請專利範圍第15項所述的裝置，其中，所述第二狀態資訊表更新子模組包括：下次更新時間延長單元，用於延長所述狀態資訊表中所述存在異常的服務節點的下次更新時間。
  18. 根據申請專利範圍第15項所述的裝置，其中，所述第二狀態資訊表更新子模組包括：更新請求發送單元，用於向所述服務節點發送更新請求； 下次更新時間接收單元，用於接收所述服務節點針對所述更新請求上傳的新的存活狀態資訊；所述新的存活狀態資訊中包括新的下次更新時間；下次更新時間更新單元，用於採用所述新的下次更新時間更新所述狀態資訊表中所述存在異常的服務節點的下次更新時間。
  19. 根據申請專利範圍第11項所述的裝置，其中，還包括：失效服務節點確定模組，用於在所述服務節點不存在異常時，將所述服務節點作為失效的服務節點。
  20. 根據申請專利範圍第11項所述的裝置，其中，還包括：失效服務節點刪除模組，用於在所述中心節點中刪除所述失效的服務節點；失效服務節點通知模組，用於通知所述分散式系統中其他服務節點所述失效的服務節點。
TW106105965A 2016-03-31 2017-02-22 分散式系統中節點的處理方法和裝置 TW201742403A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610201955.2A CN107294799B (zh) 2016-03-31 2016-03-31 一种分布式系统中节点的处理方法和装置

Publications (1)

Publication Number Publication Date
TW201742403A true TW201742403A (zh) 2017-12-01

Family

ID=59963464

Family Applications (1)

Application Number Title Priority Date Filing Date
TW106105965A TW201742403A (zh) 2016-03-31 2017-02-22 分散式系統中節點的處理方法和裝置

Country Status (6)

Country Link
US (1) US20190036798A1 (zh)
EP (1) EP3439242A4 (zh)
CN (1) CN107294799B (zh)
SG (1) SG11201808551UA (zh)
TW (1) TW201742403A (zh)
WO (1) WO2017167099A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10659561B2 (en) * 2017-06-09 2020-05-19 Microsoft Technology Licensing, Llc Service state preservation across nodes
CN108881407A (zh) * 2018-05-30 2018-11-23 郑州云海信息技术有限公司 一种信息处理方法及装置
CN108833205B (zh) * 2018-06-05 2022-03-29 中国平安人寿保险股份有限公司 信息处理方法、装置、电子设备及存储介质
CN110708177B (zh) * 2018-07-09 2022-08-09 阿里巴巴集团控股有限公司 分布式系统中的异常处理方法、系统和装置
CN111342986B (zh) * 2018-12-19 2022-09-16 杭州海康威视系统技术有限公司 分布式节点管理方法及装置、分布式系统、存储介质
CN110213106B (zh) * 2019-06-06 2022-04-19 宁波三星医疗电气股份有限公司 一种设备信息管理方法、装置、系统及电子设备
CN110716985B (zh) * 2019-10-16 2022-09-09 北京小米移动软件有限公司 一种节点信息处理方法、装置及介质
CN110730110A (zh) * 2019-10-18 2020-01-24 深圳市网心科技有限公司 节点异常处理方法、电子设备、系统及介质
CN114257495A (zh) * 2021-11-16 2022-03-29 国家电网有限公司客户服务中心 一种云平台计算节点异常自动处置系统

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7003575B2 (en) * 2001-10-15 2006-02-21 First Hop Oy Method for assisting load balancing in a server cluster by rerouting IP traffic, and a server cluster and a client, operating according to same
JP4255366B2 (ja) * 2003-11-28 2009-04-15 富士通株式会社 ネットワーク監視プログラム、ネットワーク監視方法、およびネットワーク監視装置
JP2005293101A (ja) * 2004-03-31 2005-10-20 Pacific Ind Co Ltd 光ｌａｎ装置
CN101188527B (zh) * 2007-12-24 2012-03-14 杭州华三通信技术有限公司 一种心跳检测方法和装置
WO2010052028A1 (en) * 2008-11-07 2010-05-14 Nokia Siemens Networks Oy Inter-network carrier ethernet service protection
US8364775B2 (en) * 2010-08-12 2013-01-29 International Business Machines Corporation High availability management system for stateless components in a distributed master-slave component topology
CN102231681B (zh) * 2011-06-27 2014-07-30 中国建设银行股份有限公司 一种高可用集群计算机系统及其故障处理方法
CN102387210B (zh) * 2011-10-25 2014-04-23 曙光信息产业(北京)有限公司 一种基于快速同步网络的分布式文件系统监控方法
WO2013145325A1 (ja) * 2012-03-30 2013-10-03 富士通株式会社 情報処理システム、障害検知方法および情報処理装置
CN103001809B (zh) * 2012-12-25 2016-12-28 曙光信息产业(北京)有限公司 用于云存储系统的服务节点状态监控方法
CN104618466A (zh) * 2015-01-20 2015-05-13 上海交通大学 基于消息传递的负载均衡和过负荷控制系统及其控制方法
WO2016147281A1 (ja) * 2015-03-16 2016-09-22 株式会社日立製作所 分散型ストレージシステム及び分散型ストレージシステムの制御方法
CN104933132B (zh) * 2015-06-12 2019-11-19 深圳巨杉数据库软件有限公司 基于操作序列号的分布式数据库有权重选举方法
CN105357069A (zh) * 2015-11-04 2016-02-24 浪潮(北京)电子信息产业有限公司 分布式节点服务状态监测的方法、装置及系统

Also Published As

Publication number Publication date
WO2017167099A1 (zh) 2017-10-05
EP3439242A1 (en) 2019-02-06
EP3439242A4 (en) 2019-10-30
CN107294799B (zh) 2020-09-01
CN107294799A (zh) 2017-10-24
SG11201808551UA (en) 2018-10-30
US20190036798A1 (en) 2019-01-31

Similar Documents

Publication Publication Date Title
TW201742403A (zh) 分散式系統中節點的處理方法和裝置
US10511480B2 (en) Message flow management for virtual networks
WO2016184175A1 (zh) 数据库处理方法及装置
CN108737132B (zh) 一种告警信息处理方法及装置
CN110830283B (zh) 故障检测方法、装置、设备和系统
US11909613B2 (en) On-demand outages notification in a cloud environment
US20160092288A1 (en) Detect process health remotely in a realtime fashion
US11570075B2 (en) Reverse health checks
CN110727560A (zh) 云服务报警方法及装置
US20230269153A1 (en) Detecting outages in a multiple availability zone cloud environment
CN111124609A (zh) 数据采集方法、装置、数据采集设备及存储介质
US20170187575A1 (en) System and method for customizing standard device-orientated services within a high scale deployment
US20220255824A1 (en) Detecting outages in a cloud environment
US11477098B2 (en) Identification of candidate problem network entities
CN109324914B (zh) 服务调用方法、服务调用装置及中心服务器
CN110290210B (zh) 接口调用系统中不同接口流量比例自动调配方法及装置
CN108390770B (zh) 一种信息生成方法、装置及服务器
CN106713014B (zh) 一种监控系统中的被监控主机、监控系统以及监控方法
TW201800963A (zh) 資料處理方法及裝置
CN110955579A (zh) 一种基于Ambari的大数据平台的监测方法
CN113765686B (zh) 设备管理方法、装置、业务获取设备及存储介质
CN113377627B (zh) 一种业务服务器异常检测方法、系统、设备、存储介质
US12007738B2 (en) Dynamic monitoring
WO2017166438A1 (zh) 一种管理应用状态的方法和装置
WO2021052289A1 (zh) 事件通知方法、系统、服务器设备、计算机存储介质