白楊消息端口交換服務的制作方法
【專利摘要】本發(fā)明公開一種白楊消息端口交換服務(BYPSS),其特征在于：包括服務器集群和客戶端集群；所述服務器集群通過多數(shù)派算法來選舉出當前集群中的主節(jié)點，并以租期的形式確保所述主節(jié)點在指定期間內(nèi)唯一；所述客戶端集群包含了需要使用所述白楊消息端口交換服務的各個客戶端節(jié)點，且每個所述客戶端節(jié)點均可按需分別與所述的主節(jié)點建立連接；所述客戶端節(jié)點通過唯一的節(jié)點ID在所述服務器集群中標識自己。本發(fā)明本身是一個集成了故障檢測、服務選舉、服務發(fā)現(xiàn)和分布式鎖等分布式協(xié)調(diào)功能的消息路由服務。它通過犧牲極端條件下的可靠性，在保證了強一致、高可用、可伸縮(橫向擴展)的前提下，實現(xiàn)了極高的性能、容量和并發(fā)能力。
【專利說明】
白楊消息端口交換服務
技術領域
[0001] 本發(fā)明涉及一種分布式協(xié)調(diào)系統(tǒng)，尤其涉及一種白楊消息端口交換服務。
【背景技術】
[0002] 傳統(tǒng)的分布式協(xié)調(diào)服務通常使用Paxos或Raft之類基于多數(shù)派的強一致分布式算 法實現(xiàn)，主要負責為應用提供一個高可用、強一致的分布式元數(shù)據(jù)KV訪問服務。并以此為基 礎，提供分布式鎖、消息分發(fā)、配置共享、角色選舉、服務發(fā)現(xiàn)、故障檢測等分布式協(xié)調(diào)服務。 常見的分布式協(xié)調(diào)服務實現(xiàn)包括Google Chubby(Paxos)、Apache ZooKeeper(Fast Paxos)、etcd(Raft)、Consul(Raft+Gossip)等。
[0003] Pa x o s、Ra f t等分布式一致性算法的最大問題在于其極低的訪問性能和極高的網(wǎng) 絡開銷:對這些服務的每次訪問，無論讀寫，都會產(chǎn)生兩次在集群內(nèi)部的廣播一一以投票的 方式確定本次訪問經(jīng)過多數(shù)派確認(讀也需要如此，因為主節(jié)點需要確認本次操作發(fā)生時， 自己仍擁有多數(shù)票支持，仍是集群的合法主節(jié)點）。
[0004] 在實踐中，雖可通過降低系統(tǒng)整體一致性或加入租期機制來優(yōu)化讀操作的效率， 但其總體性能仍十分低下，并且對網(wǎng)絡10有很高的沖擊:Google、Facebook、Twitter等公司 的歷次重大事故中，很多都是由于發(fā)生網(wǎng)絡分區(qū)或人為配置錯誤導致Paxos、Raft等算法不 停廣播消息，致使整個網(wǎng)絡陷入廣播風暴而癱瘓。
[0005] 此外，由于Paxos、Raft等分布式一致性算法對網(wǎng)絡10的吞吐和延遲等方面均有較 高要求，而連接多座數(shù)據(jù)中心機房（IDC)的互聯(lián)網(wǎng)絡通常又很難滿足這些要求，因此導致依 賴分布式協(xié)調(diào)算法的強一致(抗腦裂)多活IDC高可用集群架構(gòu)難以以合理成本實現(xiàn)。作為 實例：2015年5月支付寶和2013年7月微信平臺分別長時間無法訪問的事故均是由于單個 IDC因市政施工(挖斷光纜)等原因下線，同時未能成功構(gòu)建多活IDC架構(gòu)，因此造成IDC單點 依賴所導致的。

【發(fā)明內(nèi)容】

[0006] 本發(fā)明的目的是：為了解決上述問題，提供了 一種白楊消息端口交換服務 (BYPSS)，同樣提供了故障檢測、服務選舉、服務發(fā)現(xiàn)和分布式鎖等分布式協(xié)調(diào)功能，以及相 同等級的強一致性、高可用性和抗腦裂(Split Brain)能力。在消除了幾乎全部網(wǎng)絡廣播和 磁盤10等高開銷操作的同時，提供了數(shù)千、甚至上萬倍于前者的訪問性能和并發(fā)處理能力。 可在對網(wǎng)絡吞吐和延遲等方面無附加要求的前提下，構(gòu)建跨多個IDC的大規(guī)模分布式集群 系統(tǒng)。
[0007] 為了實現(xiàn)上述目的，本發(fā)明的技術方案是：
[0008] -種白楊消息端口交換服務(BYPSS)，包括服務器集群和客戶端集群;所述服務器 集群通過多數(shù)派算法來選舉出當前集群中的主節(jié)點，并以租期的形式確保所述主節(jié)點在指 定期間內(nèi)唯一;所述客戶端集群包含了需要使用所述白楊消息端口交換服務的各個客戶端 節(jié)點，且每個所述客戶端節(jié)點均可按需分別與所述的主節(jié)點建立連接;所述客戶端節(jié)點通 過唯一的節(jié)點ID在所述服務器集群中標識自己。
[0009]進一步的，所述服務器集群采用一個主節(jié)點加多個從節(jié)點的模式或主節(jié)點加從節(jié) 點加仲裁節(jié)點的模式。
[0010]進一步的，每個所述客戶端節(jié)點至少與所述白楊消息端口交換服務保持一個TCP 長連接。
[0011]進一步的，每個所述連接上可以注冊任意多個消息端口；所述消息端口由一個 UTF-8字符串描述，且在全局范圍內(nèi)唯一。
[0012]進一步的，所述白楊消息端口交換服務對外提供的應用編程接口（API)原語包括： 等待消息(胃3；[丨188)、續(xù)租(1^161:)、注冊端口（1^8?01'1:)、注銷端口（1]111^8?〇1'1:)、消息發(fā)送 (3611(1]\188)、端口查詢（( >)11615^01'1：)、節(jié)點查詢（(>)11615^0(16)、清理((]16&1·)。
[0013] 進一步的，所述客戶端集群與所述白楊消息端口交換服務的連接包括消息接收連 接和消息發(fā)送連接。
[0014] 本發(fā)明由于采用了上述技術，使之與現(xiàn)有技術相比具有的積極效果是：
[0015] 本發(fā)明將標準的消息路由功能集成到了服務選舉(注冊端口）、服務發(fā)現(xiàn)(發(fā)送消 息和查詢端口信息）、故障檢測（續(xù)租超時）以及分布式鎖(端口注冊和注銷通知)等分布式 協(xié)調(diào)服務中，是帶有分布式協(xié)調(diào)能力的高性能消息轉(zhuǎn)發(fā)服務，通過消息發(fā)送連接的接口，也 可以將其單純地當作帶故障檢測的服務選舉和發(fā)現(xiàn)服務來使用。
[0016] 本發(fā)明將配置數(shù)據(jù)庫(CMDB)等無關功能排除的設計進一步地增強了系統(tǒng)的容量 和性能(相當于在傳統(tǒng)KV存儲機制中，僅保留了K:Key，去掉了V: Value的部分;或是在傳統(tǒng) 樹形數(shù)據(jù)結(jié)構(gòu)中，僅保留路徑信息，去掉了值）。
[0017] 本發(fā)明為每個連接維護一個消息緩沖隊列，將所有端口定義及待轉(zhuǎn)發(fā)消息均保存 在主節(jié)點內(nèi)存中（Fu 11 i n -memo ry);主從節(jié)點間無任何數(shù)據(jù)復制和狀態(tài)同步開銷;信息的 發(fā)送和接收均使用純異步10實現(xiàn)，因而可提供高并發(fā)和高吞吐的消息轉(zhuǎn)發(fā)性能。
[0018] 本發(fā)明具有可伸縮性，在單點性能遭遇瓶頸或需要跨地域部署時，可通過級聯(lián)上 級端口交換服務來進行擴展(類似IDC接入、匯聚、核心等多層交換體系）。
【附圖說明】
[0019] 圖1是本發(fā)明白楊消息端口交換服務的一個主節(jié)點加多個從節(jié)點結(jié)構(gòu)示意圖。 [0020]圖2是本發(fā)明白楊消息端口交換服務的主節(jié)點加從節(jié)點加仲裁節(jié)點結(jié)構(gòu)示意圖。 [0021]圖3是樹形結(jié)構(gòu)橫向擴展的BYPSS服務器集群和客戶端集群的結(jié)構(gòu)示意圖。
[0022]圖4是本發(fā)明的使用實例。
【具體實施方式】
[0023]以下結(jié)合附圖進一步說明本發(fā)明的實施例。
[0024]為了使本發(fā)明的目的、技術方案和優(yōu)點更加清楚明白，下面結(jié)合功能圖和流程圖， 對本發(fā)明做進一步詳細說明。以下的示意性實施方式及其說明用于解釋本發(fā)明，但并不作 為對本發(fā)明的限定。
[0025] -種白楊消息端口交換服務(BYPSS)，包括服務器集群和客戶端集群;所述服務器 集群通過多數(shù)派算法來選舉出當前集群中的主節(jié)點，并以租期的形式確保所述主節(jié)點在指 定期間內(nèi)唯一;所述客戶端集群包含了需要使用所述白楊消息端口交換服務的各個客戶端 節(jié)點，且每個所述客戶端節(jié)點均可按需分別與所述的主節(jié)點建立連接;所述客戶端節(jié)點通 過唯一的節(jié)點ID在所述服務器集群中標識自己。
[0026] 請參見圖1和圖2所示，優(yōu)選的，所述服務器集群采用一個主節(jié)點加多個從節(jié)點的 模式或主節(jié)點加從節(jié)點加仲裁節(jié)點的模式。
[0027] 優(yōu)選的，每個所述客戶端節(jié)點至少與所述白楊消息端口交換服務保持一個TCP長 連接。
[0028]優(yōu)選的，每個所述連接上可以注冊任意多個消息端口；所述消息端口由一個UTF-8 字符串描述，且在全局范圍內(nèi)唯一，若其它客戶端節(jié)點已注冊了相同的消息端口，則端口注 冊失敗，消息端口包含一個消息緩存隊列和一個端口注銷通知列表。
[0029] 優(yōu)選的，所述白楊消息端口交換服務對外提供的應用編程接口（API)原語包括:等 待消息（WaitMsg)、續(xù)租（Relet)、注冊端口（RegPort)、注銷端口（UnRegPort)、消息發(fā)送 (3611(1]\188)、端口查詢（( >)11615^01'1：)、節(jié)點查詢（(>)11615^0(16)、清理((]16&1·)。
[0030] 端口交換服務對外提供的API原語包括：
[0031]等待消息(WaitMsg):客戶端集群中的每個節(jié)點均應保持一個到端口交換服務的 TCP長連接，并調(diào)用此方法等待消息推送。此方法將當前客戶端連接由消息發(fā)送連接升級為 消息接收連接。
[0032 ]每個節(jié)點號只能對應一個消息接收連接，若一個節(jié)點嘗試同時發(fā)起兩個消息接收 連接，則較早的那個接收連接將被關閉，并且綁定到當前節(jié)點上的所有端口都將被注銷。 [0033]續(xù)租(Relet):若端口交換服務在指定的間隔內(nèi)未收到來自某個消息接收連接的 續(xù)租請求，則判定該節(jié)點已經(jīng)下線，并釋放所有屬于該節(jié)點的端口。續(xù)租操作用來周期性地 向端口交換服務提供心跳信號。
[0034]注冊端口（RegPort):連接成功建立后，客戶端應向端口交換服務注冊所有屬于當 前節(jié)點的消息端口?？梢栽谝粋€端口注冊請求中包含任意多個待注冊端口，端口交換服務 會返回所有注冊失敗（已被占用）的端口列表。調(diào)用者可以選擇是否需要為注冊失敗的端口 訂閱端口注銷通知。
[0035]每次調(diào)用WaitMsg重建消息接收連接后，都需要重新注冊當前節(jié)點上的所有端口。 [0036]注銷端口（UnRegPort):注銷數(shù)據(jù)當前節(jié)點的端口，可一次提交多個端口執(zhí)行批量 注銷。BYPSS服務為其下每個端口維護一個端口注銷通知列表，列表中記錄了對該端口注銷 事件感興趣的客戶端信息。當端口被注銷后（如論是主動注銷還是超時或故障造成的注 銷），BYPSS服務將依照該列表，依次向?qū)目蛻舳送扑投丝谧N通知。
[0037]消息發(fā)送(SendMsg):向指定的端口發(fā)送消息（BLOB)，消息格式對交換服務透明。 若指定的端口為空串，則向端口交換服務上的所有節(jié)點廣播此消息。若指定的端口不存在， 則安靜地丟棄該消息。
[0038] 端口查詢（QueryPort):查詢當前占用著指定端口的節(jié)點號，及其網(wǎng)絡地址(通常 為IP地址）。此操作主要用于實現(xiàn)帶故障檢測的服務發(fā)現(xiàn)，消息投遞時已自動執(zhí)行了相應操 作，故無需使用此方法。
[0039] 節(jié)點查詢(QueryNode):查詢指定節(jié)點的網(wǎng)絡地址(通常為IP地址)等信息。此操作 主要用于實現(xiàn)帶故障檢測的節(jié)點解析。
[0040] 清理(Clear):執(zhí)行消息接收連接的斷開前清理動作。類似于TCP協(xié)議四次揮手中 的FIN信令。未成功調(diào)用此信令即斷開的消息接收連接將被消息端口交換服務判定為異常 斷開，這時該客戶端所持有的所有消息端口都不會立刻釋放，而延遲到該客戶端節(jié)點超時 時才釋放。
[0041] 這保證了即使未使用TCP協(xié)議或客戶端通過網(wǎng)關、代理等中間節(jié)點連接到消息端 口交換服務，也可嚴格保證同一端口在任意給定時間最多只有一個屬主的強一致性。
[0042] 優(yōu)選的，所有端口和消息等數(shù)據(jù)僅存放在BYPSS服務器集群的主節(jié)點內(nèi)存中。 BYPSS主節(jié)點既不將端口信息寫入磁盤，也不會在從節(jié)點、仲裁節(jié)點等BYPSS服務器集群中 的其它節(jié)點間同步這些數(shù)據(jù)(單點全內(nèi)存模式，ful 1-in-memory)。
[0043] 優(yōu)選的，所述客戶端集群與所述白楊消息端口交換服務的連接包括消息接收連接 和消息發(fā)送連接。
[0044]消息接收連接（1:1):接收連接使用WaitMsg方法完成節(jié)點注冊并等待消息推送， 同時通過Relet接口保持屬于該節(jié)點的所有端口被持續(xù)占用，并在正常斷開前使用Clear信 令完成清理?？蛻舳思褐械拿總€節(jié)點應當并且僅能夠保持一個消息接收連接。此連接為 長連接，由于連接中斷重連后需要重新進行服務選舉(注冊端口），因此應盡可能一直保持 該連接有效并及時完成續(xù)租。
[0045]消息發(fā)送連接（1 :N):所有未使用WaitMsg API升級的客戶端連接均被視為發(fā)送連 接，發(fā)送連接無需通過1^161：保持心跳，也無需使用(：1631'命令執(zhí)行清理，僅使用1^8?01'1：、 UnRegPort、SendMsg以及QueryPort等原語完成非推送類的客戶端請求。客戶端集群中的每 個節(jié)點通常都會維護一個消息發(fā)送連接池，以方便各工作線程高效地與端口轉(zhuǎn)發(fā)服務保持 通信。
[0046] 消息端口交換服務器集群的橫向擴展模式請參見圖3所示，在級聯(lián)部署時，處于樹 形結(jié)構(gòu)的葉子節(jié)點的BYPSS服務器集群將分別對接各自的客戶端集群，并為其提供分布式 協(xié)調(diào)服務。這些葉子集群負責處理所有本地的請求，并將所有超出本地決策范圍的請求逐 級向上提交至更高級的服務器集群，直至該請求能夠被處理并逐級向下返回結(jié)果為止(為 提高效率，結(jié)果可以逐級緩存）。
[0047] 決策范圍由名空間來限定，規(guī)定一個客戶節(jié)點只能注冊其本地名空間及其上級名 空間下的端口，不能注冊其兄弟或旁系名空間下的端口。消息發(fā)送則無此限制:一個客戶節(jié) 點可以向系統(tǒng)中的任意端口和節(jié)點發(fā)送消息。
[0048]由于在實踐中，絕大部分由BYPSS客戶節(jié)點發(fā)出的請求均為本地請求(僅牽扯本地 BYPSS集群），因此這種級聯(lián)模式不但可以高效地實現(xiàn)橫向擴展，更能夠用于部署不同區(qū)域 (Region)間的超遠程異地集群。在此種情形下，跨區(qū)域的通信成本高昂，通過為每個區(qū)域分 別部署一套葉子集群(所有葉子集群統(tǒng)一連接到不同層次的上級集群），即可有效降低跨區(qū) 域通信的開銷。
[0049]請參見圖4所示，BYPSS服務器由三級級聯(lián)結(jié)構(gòu)的集群組成。其中頂級集群負責全 局名空間內(nèi)的端口變更(注冊、注銷等)操作和跨大區(qū)（亞太、北美等)間的消息轉(zhuǎn)發(fā)。
[0050]級聯(lián)結(jié)構(gòu)中的第二層則對應亞太、北美等各個大區(qū)，每個大區(qū)由一個對應的BYPSS 服務器集群來負責，其中每個集群可處理自己大區(qū)內(nèi)的端口變更和該大區(qū)內(nèi)各個區(qū)域間的 消息轉(zhuǎn)發(fā)請求。他們向上連接頂級集群，向下為屬于該大區(qū)內(nèi)不同區(qū)域中的BYPSS提供服 務。
[0051 ]級聯(lián)結(jié)構(gòu)中的第三層分別對應大區(qū)內(nèi)的各個區(qū)域，如:上海、北京、舊金山等。每個 區(qū)域由一個葉子級的BYPSS服務器集群負責管理。區(qū)域內(nèi)的端口變更和消息轉(zhuǎn)發(fā)請求均無 需通過上級集群，可由本地BYPSS服務器集群自行解決。僅超出本地范圍的請求才需要向上 提交給上級集群處理。如:北京內(nèi)部的消息交換和端口注冊請求均可由位于北京的BYPSS服 務器集群處理；由一個北京節(jié)點發(fā)往一個上海節(jié)點的消息需要經(jīng)過亞太集群中轉(zhuǎn);有一個 北京節(jié)點發(fā)往舊金山節(jié)點的消息需要經(jīng)過亞太-頂級-北美等途徑中轉(zhuǎn)。
[0052]對應地，位于北京的客戶節(jié)點可以注冊名空間屬于北京、亞太和全局（頂級）的端 口，但不能注冊名空間位于上海、北美、溫哥華等范圍的端口。（注:上述對于圖4的說明均為 舉例，實際情況中可根據(jù)需要使用包含任意層次的級聯(lián)結(jié)構(gòu)和任意的區(qū)域劃分規(guī)則）。
[0053] 從此可以看出本發(fā)明具有如下特性：
[0054] 可用性:兩秒內(nèi)完成故障檢測和主備切換的高可用保證，基于多數(shù)派的選舉算法， 避免由網(wǎng)絡分區(qū)引起的腦裂問題。
[0055] -致性:保證任意給定時間內(nèi)，最多只有一個客戶端節(jié)點可持有某一特定端口。不 可能出現(xiàn)多個客戶端節(jié)點同時成功注冊和持有相同端口的情況。
[0056]可靠性:所有發(fā)往未注冊(不存在、已注銷或已過期)端口的消息都將被安靜地丟 棄。
[0057]系統(tǒng)保證所有發(fā)往已注冊端口消息有序且不重復，但在極端情況下，可能發(fā)生消 息丟失：
[0058] 端口交換服務宕機引起主從切換:此時所有在消息隊列中排隊的待轉(zhuǎn)發(fā)消息均會 丟失;所有已注冊的客戶端節(jié)點均需要重新注冊;所有已注冊的端口（服務和鎖)均需要重 新進行選舉/獲取(注冊）。
[0059] 客戶端節(jié)點接收連接斷開重連:消息接收連接斷開或重連后，所有該客戶端節(jié)點 之前注冊的端口均會失效并需重新注冊。在接收連接斷開到重連的時間窗口內(nèi)，所有發(fā)往 之前與該客戶端節(jié)點綁定的，且尚未被其它節(jié)點重新注冊的端口之消息均被丟棄。
[0060] BYPSS在每次主節(jié)點故障掉線后，所有的已注冊端口都會被強制失效，所有活動的 端口都需要重新注冊。
[0061] 例如:若分布式Web服務器集群以用戶為最小調(diào)度單位，為每位已登陸用戶注冊一 個消息端口。則當BYPSS主節(jié)點因故障掉線后，每個服務器節(jié)點都會得知自己持有的所有端 口均已失效，并需要重新注冊當前自己持有的所有活動(在線）用戶。
[0062]這看似會讓系統(tǒng)性能產(chǎn)生劇烈波動，實則并無大礙：該操作可以被批量化地完 成一一通過批量端口注冊接口，可在一次請求中同時提交多達數(shù)百萬端口的注冊和注銷操 作，從而大大提升了請求處理效率和網(wǎng)絡利用率:在2013年出廠的至強處理器上(Haswell 2.0GHz)，BYPSS服務可實現(xiàn)每核(每線程）100萬端口/秒的處理速度。同時，得益于我方自主 實現(xiàn)的并發(fā)散列表(每個arena都擁有專屬的匯編優(yōu)化用戶態(tài)讀者/寫者高速鎖），因此可通 過簡單地增加處理器核數(shù)來實現(xiàn)處理能力的線性擴展。
[0063] 具體來說，在4核處理器+千兆網(wǎng)卡環(huán)境下，BYPSS可達成約每秒400萬端口注冊的 處理能力；而在48核處理器+萬兆網(wǎng)卡環(huán)境下，則可實現(xiàn)約每秒4000萬端口注冊的處理能力 (測試時每個端口名稱的長度均為16字節(jié)），網(wǎng)卡吞吐量和載荷比都接近飽和。再加上其發(fā) 生概率極低，并且恢復時只需要隨著對象的加載來逐步完成重新注冊，因此對系統(tǒng)整體性 能幾乎不會產(chǎn)生什么波動。
[0064]為了說明這個問題，考慮10億用戶同時在線的極端情形，即使應用程序為每個用 戶分別注冊一個專用端口（例如：用來確定用戶屬主、完成消息分發(fā)等），那么在故障恢復后 的第一秒內(nèi)，也不可能出現(xiàn)"全球10億用戶心有靈犀地同時按下刷新按鈕"的情況。相反，基 于Web等網(wǎng)絡應用的固有特性，這些在線用戶通常要經(jīng)過幾分鐘、幾小時甚至更久才會逐步 返回服務器（同時在線用戶數(shù)=每秒并發(fā)請求數(shù)X用戶平均思考時間）。即使按照比較嚴苛 的"1分鐘內(nèi)全部返回"（平均思考時間1分鐘）來計算，BYPSS服務每秒也僅需處理約1600萬 條端口注冊請求。也就是說，一臺配備了 16核至強處理器和萬兆網(wǎng)卡的入門級1U PC Server即可滿足上述需求。
[0065]作為對比實例：官方數(shù)據(jù)顯示，淘寶網(wǎng)2015年雙十一當天的日活用戶數(shù)(DAU)為 1.8億，同時在線用戶數(shù)峰值為4500萬。由此可見，目前超大型站點瞬時并發(fā)用戶數(shù)的最高 峰值仍遠低于前文描述的極端情況。即使再提高數(shù)十倍，BYPSS也足可輕松支持。
[0066] BYPSS和基于Paxos、Raft等傳統(tǒng)分布式一致性算法的分布式協(xié)調(diào)產(chǎn)品特性對比如 下：

[0070] 上述比較中，延遲和性能兩項主要針對寫操作。這是因為在常見的分布式協(xié)調(diào)任 務中，幾乎全部有意義的操作都是寫操作。
[0072] 上表中，BYPSS的端口注冊對應ZooKeeper等傳統(tǒng)分布式產(chǎn)品中的"寫/創(chuàng)建KV對"； 端口注銷對應"刪除KV對"；注銷通知則對應"變更通知"服務。
[0073] 由此可見，為了發(fā)揮最高效率，在生產(chǎn)環(huán)境中通常不會使用單純的查詢等只讀操 作。而是將查詢操作隱含在端口注冊等寫請求中，請求成功則當前節(jié)點自身成為屬主;注冊 失敗自然會返回請求服務的當前屬主，因此變相完成了屬主查詢(服務發(fā)現(xiàn)/名稱解析)等 讀操作。
[0074]就算是端口注冊等寫操作失敗，其實還是會伴隨一個成功的寫操作。因為仍然要 將發(fā)起請求的當前節(jié)點加入到指定條目的變更通知列表中，以便在端口注銷等變更事件發(fā) 生時，向各個感興趣的節(jié)點推送通知消息。因此寫操作的性能差異極大地影響了現(xiàn)實產(chǎn)品 的實際表現(xiàn)。
[0075]綜上所示，白楊消息端口交換服務本身是一個集成了故障檢測、服務選舉、服務發(fā) 現(xiàn)和分布式鎖等分布式協(xié)調(diào)功能的消息路由服務。它通過犧牲極端條件下的可靠性，在保 證了強一致、高可用、可伸縮(橫向擴展)的前提下，實現(xiàn)了極高的性能、容量和并發(fā)能力。
【主權項】
1. 一種白楊消息端口交換服務(BYPSS)，其特征在于:包括服務器集群和客戶端集群； 所述服務器集群通過多數(shù)派算法來選舉出當前集群中的主節(jié)點，并以租期的形式確保所述 主節(jié)點在指定期間內(nèi)唯一;所述客戶端集群包含了需要使用所述白楊消息端口交換服務的 各個客戶端節(jié)點，且每個所述客戶端節(jié)點均可按需分別與所述的主節(jié)點建立連接;所述客 戶端節(jié)點通過唯一的節(jié)點ID在所述服務器集群中標識自己；所述服務器集群采用一個主節(jié) 點加多個從節(jié)點的模式或主節(jié)點加從節(jié)點加仲裁節(jié)點的模式，所有數(shù)據(jù)僅存儲在主節(jié)點內(nèi) 存中。2. 根據(jù)權利要求1所述的白楊消息端口交換服務(BYPSS)，其特征在于:每個所述客戶 端節(jié)點至少與所述白楊消息端口交換服務保持一個TCP長連接。3. 根據(jù)權利要求2所述的白楊消息端口交換服務(BYPSS)，其特征在于:每個所述連接 上可以注冊任意多個消息端口；所述消息端口的名稱由一個UTF-8字符串描述，且在全局范 圍內(nèi)唯一;所述消息端口包含一個消息緩存隊列和一個端口注銷通知列表。4. 根據(jù)權利要求1所述的白楊消息端口交換服務(BYPSS)，其特征在于:所述白楊消息 端口交換服務對外提供的應用編程接口原語包括:等待消息、續(xù)租、注冊端口、注銷端口、消 息發(fā)送、端口查詢、節(jié)點查詢以及清理;其在所述注冊端口的消息注冊原語允許在一次通信 請求中，同時包含多個端口注冊命令;所述注銷端口的消息注銷原語允許在一次通信請求 中，同時包含多個端口注銷命令;所述消息發(fā)送的原語允許在一次通信請求中，同時包含多 條消息(批量消息發(fā)送）。5. 根據(jù)權利要求4所述的白楊消息端口交換服務(BYPSS)，其特征在于:所述客戶端集 群與所述白楊消息端口交換服務的連接包括消息接收連接和消息發(fā)送連接。6. 根據(jù)權利要求1所述的白楊消息端口交換服務(BYPSS)，其特征在于:所述服務器集 群可由名空間分割為子服務器集群，所述子服務集群之間通過樹形級聯(lián)結(jié)構(gòu)進行橫向擴 展;所述客戶端節(jié)點在其本地名空間及其上級名空間下的端口上進行注冊。
【文檔編號】H04L29/08GK106027634SQ201610323880
【公開日】2016年10月12日
【申請日】2016年5月16日
【發(fā)明人】白楊
【申請人】白楊