白杨消息端口交换服务的制作方法
【专利摘要】本发明公开一种白杨消息端口交换服务(BYPSS),其特征在于：包括服务器集群和客户端集群；所述服务器集群通过多数派算法来选举出当前集群中的主节点，并以租期的形式确保所述主节点在指定期间内唯一；所述客户端集群包含了需要使用所述白杨消息端口交换服务的各个客户端节点，且每个所述客户端节点均可按需分别与所述的主节点建立连接；所述客户端节点通过唯一的节点ID在所述服务器集群中标识自己。本发明本身是一个集成了故障检测、服务选举、服务发现和分布式锁等分布式协调功能的消息路由服务。它通过牺牲极端条件下的可靠性，在保证了强一致、高可用、可伸缩(横向扩展)的前提下，实现了极高的性能、容量和并发能力。
【专利说明】
白杨消息端口交换服务
技术领域
[0001] 本发明涉及一种分布式协调系统，尤其涉及一种白杨消息端口交换服务。
【背景技术】
[0002] 传统的分布式协调服务通常使用Paxos或Raft之类基于多数派的强一致分布式算 法实现，主要负责为应用提供一个高可用、强一致的分布式元数据KV访问服务。并以此为基 础，提供分布式锁、消息分发、配置共享、角色选举、服务发现、故障检测等分布式协调服务。 常见的分布式协调服务实现包括Google Chubby(Paxos)、Apache ZooKeeper(Fast Paxos)、etcd(Raft)、Consul(Raft+Gossip)等。
[0003] Pa x o s、Ra f t等分布式一致性算法的最大问题在于其极低的访问性能和极高的网 络开销:对这些服务的每次访问，无论读写，都会产生两次在集群内部的广播一一以投票的 方式确定本次访问经过多数派确认(读也需要如此，因为主节点需要确认本次操作发生时， 自己仍拥有多数票支持，仍是集群的合法主节点）。
[0004] 在实践中，虽可通过降低系统整体一致性或加入租期机制来优化读操作的效率， 但其总体性能仍十分低下，并且对网络10有很高的冲击:Google、Facebook、Twitter等公司 的历次重大事故中，很多都是由于发生网络分区或人为配置错误导致Paxos、Raft等算法不 停广播消息，致使整个网络陷入广播风暴而瘫痪。
[0005] 此外，由于Paxos、Raft等分布式一致性算法对网络10的吞吐和延迟等方面均有较 高要求，而连接多座数据中心机房（IDC)的互联网络通常又很难满足这些要求，因此导致依 赖分布式协调算法的强一致(抗脑裂)多活IDC高可用集群架构难以以合理成本实现。作为 实例：2015年5月支付宝和2013年7月微信平台分别长时间无法访问的事故均是由于单个 IDC因市政施工(挖断光缆)等原因下线，同时未能成功构建多活IDC架构，因此造成IDC单点 依赖所导致的。
【发明内容】
[0006] 本发明的目的是：为了解决上述问题，提供了 一种白杨消息端口交换服务 (BYPSS)，同样提供了故障检测、服务选举、服务发现和分布式锁等分布式协调功能，以及相 同等级的强一致性、高可用性和抗脑裂(Split Brain)能力。在消除了几乎全部网络广播和 磁盘10等高开销操作的同时，提供了数千、甚至上万倍于前者的访问性能和并发处理能力。 可在对网络吞吐和延迟等方面无附加要求的前提下，构建跨多个IDC的大规模分布式集群 系统。
[0007] 为了实现上述目的，本发明的技术方案是：
[0008] -种白杨消息端口交换服务(BYPSS)，包括服务器集群和客户端集群;所述服务器 集群通过多数派算法来选举出当前集群中的主节点，并以租期的形式确保所述主节点在指 定期间内唯一;所述客户端集群包含了需要使用所述白杨消息端口交换服务的各个客户端 节点，且每个所述客户端节点均可按需分别与所述的主节点建立连接;所述客户端节点通 过唯一的节点ID在所述服务器集群中标识自己。
[0009]进一步的，所述服务器集群采用一个主节点加多个从节点的模式或主节点加从节 点加仲裁节点的模式。
[0010]进一步的，每个所述客户端节点至少与所述白杨消息端口交换服务保持一个TCP 长连接。
[0011]进一步的，每个所述连接上可以注册任意多个消息端口；所述消息端口由一个 UTF-8字符串描述，且在全局范围内唯一。
[0012]进一步的，所述白杨消息端口交换服务对外提供的应用编程接口（API)原语包括： 等待消息(胃3；[丨188)、续租(1^161:)、注册端口（1^8?01'1:)、注销端口（1]111^8?〇1'1:)、消息发送 (3611(1]\188)、端口查询（( >)11615^01'1：)、节点查询（(>)11615^0(16)、清理((]16&1·)。
[0013] 进一步的，所述客户端集群与所述白杨消息端口交换服务的连接包括消息接收连 接和消息发送连接。
[0014] 本发明由于采用了上述技术，使之与现有技术相比具有的积极效果是：
[0015] 本发明将标准的消息路由功能集成到了服务选举(注册端口）、服务发现(发送消 息和查询端口信息）、故障检测（续租超时）以及分布式锁(端口注册和注销通知)等分布式 协调服务中，是带有分布式协调能力的高性能消息转发服务，通过消息发送连接的接口，也 可以将其单纯地当作带故障检测的服务选举和发现服务来使用。
[0016] 本发明将配置数据库(CMDB)等无关功能排除的设计进一步地增强了系统的容量 和性能(相当于在传统KV存储机制中，仅保留了K:Key，去掉了V: Value的部分;或是在传统 树形数据结构中，仅保留路径信息，去掉了值）。
[0017] 本发明为每个连接维护一个消息缓冲队列，将所有端口定义及待转发消息均保存 在主节点内存中（Fu 11 i n -memo ry);主从节点间无任何数据复制和状态同步开销;信息的 发送和接收均使用纯异步10实现，因而可提供高并发和高吞吐的消息转发性能。
[0018] 本发明具有可伸缩性，在单点性能遭遇瓶颈或需要跨地域部署时，可通过级联上 级端口交换服务来进行扩展(类似IDC接入、汇聚、核心等多层交换体系）。
【附图说明】
[0019] 图1是本发明白杨消息端口交换服务的一个主节点加多个从节点结构示意图。 [0020]图2是本发明白杨消息端口交换服务的主节点加从节点加仲裁节点结构示意图。 [0021]图3是树形结构横向扩展的BYPSS服务器集群和客户端集群的结构示意图。
[0022]图4是本发明的使用实例。
【具体实施方式】
[0023]以下结合附图进一步说明本发明的实施例。
[0024]为了使本发明的目的、技术方案和优点更加清楚明白，下面结合功能图和流程图， 对本发明做进一步详细说明。以下的示意性实施方式及其说明用于解释本发明，但并不作 为对本发明的限定。
[0025] -种白杨消息端口交换服务(BYPSS)，包括服务器集群和客户端集群;所述服务器 集群通过多数派算法来选举出当前集群中的主节点，并以租期的形式确保所述主节点在指 定期间内唯一;所述客户端集群包含了需要使用所述白杨消息端口交换服务的各个客户端 节点，且每个所述客户端节点均可按需分别与所述的主节点建立连接;所述客户端节点通 过唯一的节点ID在所述服务器集群中标识自己。
[0026] 请参见图1和图2所示，优选的，所述服务器集群采用一个主节点加多个从节点的 模式或主节点加从节点加仲裁节点的模式。
[0027] 优选的，每个所述客户端节点至少与所述白杨消息端口交换服务保持一个TCP长 连接。
[0028]优选的，每个所述连接上可以注册任意多个消息端口；所述消息端口由一个UTF-8 字符串描述，且在全局范围内唯一，若其它客户端节点已注册了相同的消息端口，则端口注 册失败，消息端口包含一个消息缓存队列和一个端口注销通知列表。
[0029] 优选的，所述白杨消息端口交换服务对外提供的应用编程接口（API)原语包括:等 待消息（WaitMsg)、续租（Relet)、注册端口（RegPort)、注销端口（UnRegPort)、消息发送 (3611(1]\188)、端口查询（( >)11615^01'1：)、节点查询（(>)11615^0(16)、清理((]16&1·)。
[0030] 端口交换服务对外提供的API原语包括：
[0031]等待消息(WaitMsg):客户端集群中的每个节点均应保持一个到端口交换服务的 TCP长连接，并调用此方法等待消息推送。此方法将当前客户端连接由消息发送连接升级为 消息接收连接。
[0032 ]每个节点号只能对应一个消息接收连接，若一个节点尝试同时发起两个消息接收 连接，则较早的那个接收连接将被关闭，并且绑定到当前节点上的所有端口都将被注销。 [0033]续租(Relet):若端口交换服务在指定的间隔内未收到来自某个消息接收连接的 续租请求，则判定该节点已经下线，并释放所有属于该节点的端口。续租操作用来周期性地 向端口交换服务提供心跳信号。
[0034]注册端口（RegPort):连接成功建立后，客户端应向端口交换服务注册所有属于当 前节点的消息端口。可以在一个端口注册请求中包含任意多个待注册端口，端口交换服务 会返回所有注册失败（已被占用）的端口列表。调用者可以选择是否需要为注册失败的端口 订阅端口注销通知。
[0035]每次调用WaitMsg重建消息接收连接后，都需要重新注册当前节点上的所有端口。 [0036]注销端口（UnRegPort):注销数据当前节点的端口，可一次提交多个端口执行批量 注销。BYPSS服务为其下每个端口维护一个端口注销通知列表，列表中记录了对该端口注销 事件感兴趣的客户端信息。当端口被注销后（如论是主动注销还是超时或故障造成的注 销），BYPSS服务将依照该列表，依次向对应的客户端推送端口注销通知。
[0037]消息发送(SendMsg):向指定的端口发送消息（BLOB)，消息格式对交换服务透明。 若指定的端口为空串，则向端口交换服务上的所有节点广播此消息。若指定的端口不存在， 则安静地丢弃该消息。
[0038] 端口查询（QueryPort):查询当前占用着指定端口的节点号，及其网络地址(通常 为IP地址）。此操作主要用于实现带故障检测的服务发现，消息投递时已自动执行了相应操 作，故无需使用此方法。
[0039] 节点查询(QueryNode):查询指定节点的网络地址(通常为IP地址)等信息。此操作 主要用于实现带故障检测的节点解析。
[0040] 清理(Clear):执行消息接收连接的断开前清理动作。类似于TCP协议四次挥手中 的FIN信令。未成功调用此信令即断开的消息接收连接将被消息端口交换服务判定为异常 断开，这时该客户端所持有的所有消息端口都不会立刻释放，而延迟到该客户端节点超时 时才释放。
[0041] 这保证了即使未使用TCP协议或客户端通过网关、代理等中间节点连接到消息端 口交换服务，也可严格保证同一端口在任意给定时间最多只有一个属主的强一致性。
[0042] 优选的，所有端口和消息等数据仅存放在BYPSS服务器集群的主节点内存中。 BYPSS主节点既不将端口信息写入磁盘，也不会在从节点、仲裁节点等BYPSS服务器集群中 的其它节点间同步这些数据(单点全内存模式，ful 1-in-memory)。
[0043] 优选的，所述客户端集群与所述白杨消息端口交换服务的连接包括消息接收连接 和消息发送连接。
[0044]消息接收连接（1:1):接收连接使用WaitMsg方法完成节点注册并等待消息推送， 同时通过Relet接口保持属于该节点的所有端口被持续占用，并在正常断开前使用Clear信 令完成清理。客户端集群中的每个节点应当并且仅能够保持一个消息接收连接。此连接为 长连接，由于连接中断重连后需要重新进行服务选举(注册端口），因此应尽可能一直保持 该连接有效并及时完成续租。
[0045]消息发送连接（1 :N):所有未使用WaitMsg API升级的客户端连接均被视为发送连 接，发送连接无需通过1^161：保持心跳，也无需使用(：1631'命令执行清理，仅使用1^8?01'1：、 UnRegPort、SendMsg以及QueryPort等原语完成非推送类的客户端请求。客户端集群中的每 个节点通常都会维护一个消息发送连接池，以方便各工作线程高效地与端口转发服务保持 通信。
[0046] 消息端口交换服务器集群的横向扩展模式请参见图3所示，在级联部署时，处于树 形结构的叶子节点的BYPSS服务器集群将分别对接各自的客户端集群，并为其提供分布式 协调服务。这些叶子集群负责处理所有本地的请求，并将所有超出本地决策范围的请求逐 级向上提交至更高级的服务器集群，直至该请求能够被处理并逐级向下返回结果为止(为 提高效率，结果可以逐级缓存）。
[0047] 决策范围由名空间来限定，规定一个客户节点只能注册其本地名空间及其上级名 空间下的端口，不能注册其兄弟或旁系名空间下的端口。消息发送则无此限制:一个客户节 点可以向系统中的任意端口和节点发送消息。
[0048]由于在实践中，绝大部分由BYPSS客户节点发出的请求均为本地请求(仅牵扯本地 BYPSS集群），因此这种级联模式不但可以高效地实现横向扩展，更能够用于部署不同区域 (Region)间的超远程异地集群。在此种情形下，跨区域的通信成本高昂，通过为每个区域分 别部署一套叶子集群(所有叶子集群统一连接到不同层次的上级集群），即可有效降低跨区 域通信的开销。
[0049]请参见图4所示，BYPSS服务器由三级级联结构的集群组成。其中顶级集群负责全 局名空间内的端口变更(注册、注销等)操作和跨大区（亚太、北美等)间的消息转发。
[0050]级联结构中的第二层则对应亚太、北美等各个大区，每个大区由一个对应的BYPSS 服务器集群来负责，其中每个集群可处理自己大区内的端口变更和该大区内各个区域间的 消息转发请求。他们向上连接顶级集群，向下为属于该大区内不同区域中的BYPSS提供服 务。
[0051 ]级联结构中的第三层分别对应大区内的各个区域，如:上海、北京、旧金山等。每个 区域由一个叶子级的BYPSS服务器集群负责管理。区域内的端口变更和消息转发请求均无 需通过上级集群，可由本地BYPSS服务器集群自行解决。仅超出本地范围的请求才需要向上 提交给上级集群处理。如:北京内部的消息交换和端口注册请求均可由位于北京的BYPSS服 务器集群处理；由一个北京节点发往一个上海节点的消息需要经过亚太集群中转;有一个 北京节点发往旧金山节点的消息需要经过亚太-顶级-北美等途径中转。
[0052]对应地，位于北京的客户节点可以注册名空间属于北京、亚太和全局（顶级）的端 口，但不能注册名空间位于上海、北美、温哥华等范围的端口。（注:上述对于图4的说明均为 举例，实际情况中可根据需要使用包含任意层次的级联结构和任意的区域划分规则）。
[0053] 从此可以看出本发明具有如下特性：
[0054] 可用性:两秒内完成故障检测和主备切换的高可用保证，基于多数派的选举算法， 避免由网络分区引起的脑裂问题。
[0055] -致性:保证任意给定时间内，最多只有一个客户端节点可持有某一特定端口。不 可能出现多个客户端节点同时成功注册和持有相同端口的情况。
[0056]可靠性:所有发往未注册(不存在、已注销或已过期)端口的消息都将被安静地丢 弃。
[0057]系统保证所有发往已注册端口消息有序且不重复，但在极端情况下，可能发生消 息丢失：
[0058] 端口交换服务宕机引起主从切换:此时所有在消息队列中排队的待转发消息均会 丢失;所有已注册的客户端节点均需要重新注册;所有已注册的端口（服务和锁)均需要重 新进行选举/获取(注册）。
[0059] 客户端节点接收连接断开重连:消息接收连接断开或重连后，所有该客户端节点 之前注册的端口均会失效并需重新注册。在接收连接断开到重连的时间窗口内，所有发往 之前与该客户端节点绑定的，且尚未被其它节点重新注册的端口之消息均被丢弃。
[0060] BYPSS在每次主节点故障掉线后，所有的已注册端口都会被强制失效，所有活动的 端口都需要重新注册。
[0061] 例如:若分布式Web服务器集群以用户为最小调度单位，为每位已登陆用户注册一 个消息端口。则当BYPSS主节点因故障掉线后，每个服务器节点都会得知自己持有的所有端 口均已失效，并需要重新注册当前自己持有的所有活动(在线）用户。
[0062]这看似会让系统性能产生剧烈波动，实则并无大碍：该操作可以被批量化地完 成一一通过批量端口注册接口，可在一次请求中同时提交多达数百万端口的注册和注销操 作，从而大大提升了请求处理效率和网络利用率:在2013年出厂的至强处理器上(Haswell 2.0GHz)，BYPSS服务可实现每核(每线程）100万端口/秒的处理速度。同时，得益于我方自主 实现的并发散列表(每个arena都拥有专属的汇编优化用户态读者/写者高速锁），因此可通 过简单地增加处理器核数来实现处理能力的线性扩展。
[0063] 具体来说，在4核处理器+千兆网卡环境下，BYPSS可达成约每秒400万端口注册的 处理能力；而在48核处理器+万兆网卡环境下，则可实现约每秒4000万端口注册的处理能力 (测试时每个端口名称的长度均为16字节），网卡吞吐量和载荷比都接近饱和。再加上其发 生概率极低，并且恢复时只需要随着对象的加载来逐步完成重新注册，因此对系统整体性 能几乎不会产生什么波动。
[0064]为了说明这个问题，考虑10亿用户同时在线的极端情形，即使应用程序为每个用 户分别注册一个专用端口（例如：用来确定用户属主、完成消息分发等），那么在故障恢复后 的第一秒内，也不可能出现"全球10亿用户心有灵犀地同时按下刷新按钮"的情况。相反，基 于Web等网络应用的固有特性，这些在线用户通常要经过几分钟、几小时甚至更久才会逐步 返回服务器（同时在线用户数=每秒并发请求数X用户平均思考时间）。即使按照比较严苛 的"1分钟内全部返回"（平均思考时间1分钟）来计算，BYPSS服务每秒也仅需处理约1600万 条端口注册请求。也就是说，一台配备了 16核至强处理器和万兆网卡的入门级1U PC Server即可满足上述需求。
[0065]作为对比实例：官方数据显示，淘宝网2015年双十一当天的日活用户数(DAU)为 1.8亿，同时在线用户数峰值为4500万。由此可见，目前超大型站点瞬时并发用户数的最高 峰值仍远低于前文描述的极端情况。即使再提高数十倍，BYPSS也足可轻松支持。
[0066] BYPSS和基于Paxos、Raft等传统分布式一致性算法的分布式协调产品特性对比如 下：
[0070] 上述比较中，延迟和性能两项主要针对写操作。这是因为在常见的分布式协调任 务中，几乎全部有意义的操作都是写操作。
[0072] 上表中，BYPSS的端口注册对应ZooKeeper等传统分布式产品中的"写/创建KV对"； 端口注销对应"删除KV对"；注销通知则对应"变更通知"服务。
[0073] 由此可见，为了发挥最高效率，在生产环境中通常不会使用单纯的查询等只读操 作。而是将查询操作隐含在端口注册等写请求中，请求成功则当前节点自身成为属主;注册 失败自然会返回请求服务的当前属主，因此变相完成了属主查询(服务发现/名称解析)等 读操作。
[0074]就算是端口注册等写操作失败，其实还是会伴随一个成功的写操作。因为仍然要 将发起请求的当前节点加入到指定条目的变更通知列表中，以便在端口注销等变更事件发 生时，向各个感兴趣的节点推送通知消息。因此写操作的性能差异极大地影响了现实产品 的实际表现。
[0075]综上所示，白杨消息端口交换服务本身是一个集成了故障检测、服务选举、服务发 现和分布式锁等分布式协调功能的消息路由服务。它通过牺牲极端条件下的可靠性，在保 证了强一致、高可用、可伸缩(横向扩展)的前提下，实现了极高的性能、容量和并发能力。
【主权项】
1. 一种白杨消息端口交换服务(BYPSS)，其特征在于:包括服务器集群和客户端集群； 所述服务器集群通过多数派算法来选举出当前集群中的主节点，并以租期的形式确保所述 主节点在指定期间内唯一;所述客户端集群包含了需要使用所述白杨消息端口交换服务的 各个客户端节点，且每个所述客户端节点均可按需分别与所述的主节点建立连接;所述客 户端节点通过唯一的节点ID在所述服务器集群中标识自己；所述服务器集群采用一个主节 点加多个从节点的模式或主节点加从节点加仲裁节点的模式，所有数据仅存储在主节点内 存中。2. 根据权利要求1所述的白杨消息端口交换服务(BYPSS)，其特征在于:每个所述客户 端节点至少与所述白杨消息端口交换服务保持一个TCP长连接。3. 根据权利要求2所述的白杨消息端口交换服务(BYPSS)，其特征在于:每个所述连接 上可以注册任意多个消息端口；所述消息端口的名称由一个UTF-8字符串描述，且在全局范 围内唯一;所述消息端口包含一个消息缓存队列和一个端口注销通知列表。4. 根据权利要求1所述的白杨消息端口交换服务(BYPSS)，其特征在于:所述白杨消息 端口交换服务对外提供的应用编程接口原语包括:等待消息、续租、注册端口、注销端口、消 息发送、端口查询、节点查询以及清理;其在所述注册端口的消息注册原语允许在一次通信 请求中，同时包含多个端口注册命令;所述注销端口的消息注销原语允许在一次通信请求 中，同时包含多个端口注销命令;所述消息发送的原语允许在一次通信请求中，同时包含多 条消息(批量消息发送）。5. 根据权利要求4所述的白杨消息端口交换服务(BYPSS)，其特征在于:所述客户端集 群与所述白杨消息端口交换服务的连接包括消息接收连接和消息发送连接。6. 根据权利要求1所述的白杨消息端口交换服务(BYPSS)，其特征在于:所述服务器集 群可由名空间分割为子服务器集群，所述子服务集群之间通过树形级联结构进行横向扩 展;所述客户端节点在其本地名空间及其上级名空间下的端口上进行注册。
【文档编号】H04L29/08GK106027634SQ201610323880
【公开日】2016年10月12日
【申请日】2016年5月16日
【发明人】白杨
【申请人】白杨