应用于静态集群上的分布式通信系统及方法与流程

本发明涉及一种分布式通信中间件技术，尤其是涉及一种可在规模较大的多台主机上，多个应有程序中使用服务名进行相互通信的应用于静态集群上的分布式通信系统及方法。

背景技术：

在传统的信息系统中，随着信息化的深入，信息系统的规模在不断的扩大。例如，面向交通行业的软件，因为线路的不断建设、信息化的深入、互联互通的需求等原因，系统规模不断扩大，需要相互通信的主机规模甚至达到了千台级别。为了解决大规模集群的通信问题，产生了分布式消息队列技术。但是分布式消息队列技术的实现大部分是面向互联网行业的开源实现，应用于传统行业软件会有功能、性能、运维、授权协议等一系列问题。

随着业务的发展，系统规模不断扩大，呈现出分布式与集群等特点。系统中一部分业务模块需要使用多台主机组成一个集群才能完成业务。另一部分业务模块需要分布在多台主机上，甚至多地多台主机上进行工作，主机既需要相互通信，又不能因为局部、或者大部分出问题而影响其他部分。在这样的技术需求背景下，如果继续使用传统的客户端、服务端通信模型进行软件开发，设计、开发、维护的难度都非常巨大。

技术实现要素：

本发明的发明目的是为了克服现有技术中的现有业务需求下分布在一定规模主机上的多个应用程序无法进行高性能通信的不足，提供了一种可在规模较大的多台主机上，多个应用进程中使用服务名进行相互通信的用于静态集群上的分布式通信系统及方法。

为了实现上述目的，本发明采用以下技术方案：

一种应用于静态集群上的分布式通信系统，在包括N台主机，m个应用服务进程的静态集群上，服务于该静态集群的分布式通信系统包括设于每台主机上的天使服务进程，极速配置库和m个天使客户端库；每个应用服务进程均调对应的用天使客户端库，天使服务进程和各个应用服务进程均与极速配置库连接，天使服务进程分别与各个应用服务进程连接，N≥1，m≥2；

极速配置库中设有应用服务进程信息表与天使服务进程信息表；

应用服务进程信息表由4个字段构成，4个字段分别为应用服务进程服务名，应用服务进程编号，应用服务进程对应的天使服务进程编号和应用服务进程在线状态；其中，应用服务进程服务名是应用服务进程信息表的主键；应用服务进程在线状态字段是动态字段，应用服务进程根据应用服务进程与天使服务进程之间的连接状态进行更新，其它字段均为静态字段；

天使服务进程信息表由5个字段构成，5个字段分别为天使服务进程地址信息，天使服务进程编号，天使服务进程附属应用服务进程起始编号，天使服务进程附属应用服务进程个数和天使服务进程在线状态；天使服务进程地址信息是天使服务进程信息表的主键，天使服务进程为动态字段，天使服务进程在线状态根据本地天使服务进程与其它天使服务进程之间的连接状态进行更新，同时更新的包括天使服务进程附属的应用服务进程在线状态。

本发明解决了分布在一定规模主机上的多个应用程序进行高性能相互通信的问题，提供了一种在规模较大的多台主机上，多个应有程序可以使用服务名进行相互通信中间件系统。本发明使用简单，对用户友好。

在一个应用服务进程需要与多个应用服务进程进行通信的时候，如果使用客户端、服务端模型，应用服务进程需要管理多个连接，操作复杂，且随着需要相互通信的应用服务进程数量的增多，开发复杂度快速上升；如果整个集群中这种需要相互通信的应用服务进程数量特别多，将消耗比较多的系统资源。

相对于客户端、服务端通信模型，本发明可以按照服务名进行通信。

现有的开源消息技术基本只支持三台主机以上的集群；开源消息队列技术在集群中N/2+1台机器出现网络故障或者主机故障时便不能进行通信；开源消息队列技术在集群规模越来越大的时候，通信效率呈现下降；开源消息队列技术在集群出现分裂时，处于少数的主机不能使用消息队列；开源消息队列面临遵守开源协议的问题，需要面对动态集群技术，实现复杂度高、效率低，

相对于开源消息队列技术，本发明可以适应一台、两台到多台主机的集群，在集群规模变大时，通信效率保持稳定；少数的主机之间依旧可以通信；本发明面对静态集群环境，实现简单，效率高。

一种应用于静态集群上的分布式通信系统的方法，包括关系表的插入过程：关系表为应用服务进程信息表或天使服务进程信息表；

步骤1：从要插入行的行内容中取出主键内容；

步骤2：对主键进行哈希计算，得到哈希值；

步骤3：在哈希区寻找与哈希值对应节点的位置，如果该节点没有被使用，转入步骤4，如果该节点已经被使用，转入步骤6；

步骤4：在节点内写入节点信息，节点信息包括主键、行号和下个节点偏移；其中，行号为关系表的表头中的待插入行号，表头包括行数目；

步骤5：将行内容写入待插入行号的行，待插入行号加1；

步骤6：按照节点信息中下一个节点偏移信息，依次寻找下一个节点，直到下一个节点偏移为-1，将-1改为拉链区可用节点偏移，在拉链区可用偏移的位置上，写入节点信息，将拉链区可用偏移号加1；

步骤7：将行内容写入待插入行号的行，待插入行号加1；

其中，哈希计算包括如下步骤：

步骤1：采用公用的哈希算法对主键进行哈希，得到一个整数；

步骤2：将整数对行数目取余，得到一个哈希值。

作为优选，还包括查询的过程：

步骤1：对查询主键进行哈希计算，得到哈希值；

步骤2：在哈希区寻找与哈希值对应节点的位置，比较节点的主键内容与查询主键内容是否相同，相同时取节点中记录的行号信息；不相同时，取下一个节点的偏移；

步骤3：按照下一个节点的偏移，依次比较节点的主键与查询主键是否相同，直到找到相同的节点，取该节点中记录的行号信息；

步骤4：如果没有找到行号信息，查询失败；

其中，哈希计算包括如下步骤：

步骤1：采用公用的哈希算法对主键进行哈希，得到一个整数；

步骤2：将整数对行数目取余，得到一个哈希值。

作为优选，还包括在线状态同步触发步骤：

步骤1：取当前系统时间，将当前系统时间减去上一次的系统时间，得到时间差；

若时间差＞1秒，转入步骤2；

若时间差≤1秒，则睡眠100毫秒，循环执行步骤1；

步骤2：检测事件触发标志是否为1，或者是否到了同步周期；如果是，转入步骤3；否则，继续执行步骤2；

步骤3：将事件触发标志修改为0，执行在线状态同步过程；

步骤4：将上一次系统时间赋值为获取的当前系统时间，将周期时间赋值为当前系统时间加周期值，继续执行步骤1。

作为优选，还包括在线状态同步过程：

步骤1：天使服务进程从极速配置库中读取附属于自己的应用服务进程的在线状态；

步骤2：天使服务进程将附属于自己的应用服务进程的在线状态进行压缩，构成一个在线状态更新包；

步骤3：向其他的所有主机的天使服务进程发送自己附属的应用服务进程的在线状态更新包；

步骤4：接收到在线状态更新包的天使服务进程，解压缩在线状态更新包，修改本地的极速配置库。

作为优选，还包括应用服务进程登录过程：

步骤1：在主机i上，应用服务进程j在天使服务进程i上登录，应用服务进程j调用天使客户端库的登录接口，传入自己的服务名jX；i＝1，2，…，N；j＝1，2，…，m；

步骤2：天使服务进程i接到应用服务进程j登录请求，按照服务名j查询查询本地极速配置库；

如果查到极速配置库里面存在该服务的配置，返回应用服务进程j的编号及登录成功的信息，修改极速配置库内应用服务进程j的登录状态为已经登录，转入步骤3；

如果没有查到极速配置库里面存在该服务的配置，返回-1及登录失败的信息；

步骤3：天使服务进程i将应用服务进程j的已登录状态广播发送给天使服务进程2到N；

天使服务进程2至天使服务进程N收到应用服务进程j的已登录状态，分别转入步骤4；

步骤4：天使服务进程2至天使服务进程N将应用服务进程j的已登录状态写入本地极速配置库。

作为优选，还包括应用服务进程之间通信过程：

应用服务进程j向应用服务进程k发送一个消息；k＝1，2，…，m；k≠j；

步骤1：应用服务进程j通过本地极速配置库，按照应用服务进程k的服务名，查询应用服务进程k的编号与在线状态；若查询到应用服务进程的编号且应用服务进程的在线状态为在线，转入步骤2；反之，返回失败信息，通信结束；

步骤2：应用服务进程j构建消息包，向天使服务进程i发送该消息包；

步骤3：天使服务进程i收到该消息包，按照该消息包包头内容，查询极速配置库，查出应该转发的目标天使进程N，并查询目标天使进程N的在线状态；

步骤4：天使服务进程i将消息包发送给天使服务进程N；

步骤5：天使服务进程N收到该消息包，按照该消息包包头内容，查询极速配置库，查出应用服务进程k；

步骤6：天使服务进程N将消息包发送给应用服务进程k。

因此，本发明具有如下有益效果：可以适应一台、两台到多台主机的集群，在集群规模变大时，通信效率保持稳定；在静态集群出现故障时，即使故障范围涉及了大部分主机，少数没被涉及的主机之间依旧可以通信；本发明面对静态集群环境，实现简单，效率高。

附图说明

图1为本发明的一种结构示意图；

图2为本发明的极速配置库的一种结构图；

图3为本发明的极速配置库的表头的一种结构图；

图4本发明的极速配置库中表的索引结构与索引方法的一种示意图；

图5本发明的极速配置库中表数据的一种分布方式图；

图6为本发明的对等辐射网络的一种结构图；

图7为本发明的应用服务进程在线状态的一种周期同步过程图；

图8本分明的在网络分裂状况下的一种可靠性分析图；

图9为本发明的天使客户端库接口的一种图。

图中：主机2、天使服务进程21、极速配置库22、应用服务进程23、天使客户端库24。

具体实施方式

下面结合附图和具体实施方式对本发明做进一步的描述。

如图1所示的实施例是一种应用于静态集群上的分布式通信系统，在包括N台主机2，20个应用服务进程23的静态集群上，服务于该静态集群的分布式通信系统包括设于每台主机上的天使服务进程21，极速配置库22和20个天使客户端库24；20个应用服务进程分别调用20个天使客户端库，天使服务进程和各个应用服务进程均调用极速配置库，天使服务进程分别与各个应用服务进程连接；

如图2所示，极速配置库中设有应用服务进程信息表与天使服务进程信息表；

应用服务进程信息表由4个字段构成，4个字段分别为应用服务进程服务名，应用服务进程编号，应用服务进程对应的天使服务进程编号和应用服务进程在线状态；其中，应用服务进程服务名是应用服务进程信息表的主键；应用服务进程在线状态字段是动态字段，会根据应用服务进程与天使服务进程之间的连接状态进行更新；

其它字段均为静态字段；静态字段在一个静态集群确定的时候就已经确定，不会在运行期动态变化。应用服务进程服务名可以按照服务名进行快速查询。应用服务进程的编号使用连续数字顺序编号，对应应用服务进程在应用服务进程信息表中的行号，且将同一台主机上的应用服务进程连续编号。只有应用服务进程在线状态是根据实际情况动态更新的字段。

天使服务进程信息表由5个字段构成，5个字段分别为天使服务进程地址信息，天使服务进程编号，天使服务进程附属应用服务进程起始编号，天使服务进程附属应用服务进程个数和天使服务进程在线状态；天使服务进程地址信息是天使服务进程信息表的主键，可以按照地址快速查询。天使服务进程编号使用连续数字顺序编号，对应天使服务进程信息表的行号。天使服务进程地址信息是主键，

天使服务进程附属的应用服务进程是与天使服务进程在同一台主机上，使用天使客户端库直接连接在天使服务进程上的应用服务进程。天使服务进程为动态字段，天使服务进程在线状态，是根据本地天使服务进程与其他天使服务进程之间的连接状态进行更新的，同时更新的包括天使服务进程附属的应用服务进程在线状态。

两张表中的在线状态字段是动态变化的，但是变化不频繁，表中使用一个字节表示在线状态，同时使用0表示在线，其他任何值均表示离线，所以变化字段无需加锁，整个极速配置库变可以使用无锁设计。极速配置库使用共享内存进行实现，且使用无锁设计，根据上述特点，极速配置库可以提供内存级别的访问速度。

如图3、图5所示，还包括关系表的插入过程：

步骤1：从要插入行的行内容中取出主键内容；

步骤2：对主键进行哈希计算，得到哈希值；

步骤3：在哈希区寻找与哈希值对应节点的位置，如果该节点没有被使用，转入步骤4，如果该节点已经被使用，转入步骤6；

步骤4：在节点内写入节点信息，节点信息包括主键、行号和下个节点偏移；其中，行号为关系表的表头中的待插入行号，表头包括行数目；

步骤5：将行内容写入待插入行号的行，待插入行号加1；

步骤6：按照节点信息中下一个节点偏移信息，依次寻找下一个节点，直到下一个节点偏移为-1，将-1改为拉链区可用节点偏移，在拉链区可用偏移的位置上，写入节点信息，将拉链区可用偏移号加1；

步骤7：将行内容写入待插入行号的行，待插入行号加1；

其中，哈希计算包括如下步骤：

步骤1：采用公用的哈希算法对主键进行哈希，得到一个整数；

步骤2：将整数对行数目取余，得到一个哈希值。

如图4、图5所示，还包括查询的过程：

步骤1：对查询主键进行哈希计算，得到哈希值；

步骤2：在哈希区寻找与哈希值对应节点的位置，比较节点的主键内容与查询主键内容是否相同，相同时取节点中记录的行号信息；不相同时，取下一个节点的偏移；

步骤3：按照下一个节点的偏移，依次比较节点的主键与查询主键是否相同，直到找到相同的节点，取该节点中记录的行号信息；

步骤4：如果没有找到行号信息，查询失败；

其中，哈希计算包括如下步骤：

步骤1：采用公用的哈希算法对主键进行哈希，得到一个整数；

步骤2：将整数对行数目取余，得到一个哈希值。

如图6所示，分布在集群中每一台机器上的天使服务进程均连接其他所有主机上的天使服务进程，构成一个每一台主机上都对等的辐射形状的网络结构。第1天使服务进程在连接第2天使服务进程至第N天使服务进程的同时，接收第2天使服务进程至第N天使服务进程的连接。

对等辐射网络上每一个天使服务进程管理的连接数目都是2*(N-1)；任意两台主机都使用天使服务进程直接连接；任意两个分布在不同主机上的应用服务进程之间的通信都是使用两个主机之间的天使服务进程进行转发通信。在对等辐射网络的网络结构上，没有任何一个天使服务进程节点会成为性能瓶颈，也没有一个天使服务进程会成为主要节点，而影响不相关的应用服务进程之间的通信。由于本地进程间通信的与网络通信的速度相比是非常快速的，所以本地天使服务进程也不会成为应用服务进程通信的瓶颈，因为更先到达瓶颈的是网络通信速度。如果达到网络通信的速度瓶颈，即使使用客户端、服务端的传统通信模式也不能提高速度。

在线状态同步触发方式分为两种：

周期触发在线状态同步；

事件触发在线状态同步。周期触发的在线状态同步，是为防止异常情况的出现，一种可以从任何出错情况下自修复策略。不管出现任何没有预料到的异常，只要经过一个周期，系统就可以从错误中恢复，回到正常可运行状态。每隔一个周期执行一次，周期可配置，最短周期一秒。事件触发的在线状态同步，是在应用服务进程调用登录接口、调用登出接口、异常退出三种情况下，修改在事件触发标志为1(注意，不是直接触发在线状态同步)。两种触发方式结合在一起，得到下述在线状态同步触发步骤。

如图7所示，还包括在线状态同步触发步骤：

步骤1：取当前系统时间，将当前系统时间减去上一次的系统时间，得到时间差；

若时间差＞1秒，转入步骤2；

若时间差≤1秒，则睡眠100毫秒，循环执行步骤1；

步骤2：检测事件触发标志是否为1，或者是否到了同步周期；如果是，转入步骤3；否则，继续执行步骤2；

步骤3：将事件触发标志修改为0，执行在线状态同步过程；

步骤4：将上一次系统时间赋值为获取的当前系统时间，将周期时间赋值为当前系统时间加周期值，继续执行步骤1。

可以看出，事件触发方式是合并进周期触发方式中进行处理的，发生事件触发的时候，仅修改事件触发标志。这样做的好处是，在发生应用服务进程调用登录接口等事件的时候，最多1秒之后，应用服务进程的在线状态将被同步，保持了系统的灵敏性。而且避免了如果某些应用服务进程发生异常或其他情况引起的频繁的登录、登出调用，导致在线状态同步太频繁，从而冲击整个系统。因为无论如何频繁的发生触发事件，在线状态同步过程最多每秒触发一次。

还包括在线状态同步过程：

步骤1：天使服务进程从极速配置库中读取附属于自己的应用服务进程的在线状态；

步骤2：天使服务进程将附属于自己的应用服务进程的在线状态进行压缩，构成一个在线状态更新包；

步骤3：向其他的所有主机的天使服务进程发送自己附属的应用服务进程的在线状态更新包；

步骤4：接收到在线状态更新包的天使服务进程，解压缩在线状态更新包，修改本地的极速配置库。

压缩的方法如下：因为静态集群的特点，附属于同一个天使服务进程的多个应用服务进程在编号上是连续的，可以使用一个字符数组表示在线状态，按照顺序字符数组每一个字节的每一位对应一个应用服务进程的在线状态。由于极速配置库中已经有天使服务进程对应的应用服务进程的起始编号与个数，所以不需要传输额外的其他信息，既可以进行解压缩。例如天使服务进程1附属5个应用服务进程，一个字节有8个比特位，使用一个字节就可以表示5个应用服务进程的在线状态。使用上述压缩方法，可以使用极少的字节，表示更多的信息。

使用本发明的应用服务进程在线状态的同步方法，在一个1000台主机，每台主机上80个应用服务进程的静态集群上，采用10秒为一个周期。在系统稳定运行期间，每一台主机上为保持应用服务进程在线状态同步所耗用的网络带宽是1000个字节/秒(计算方法(80/8*1000)/10)，按照带宽为百兆的系统计算，损耗的资源只有不足万分之一。即使在系统彻底动荡期间，所耗用的最大带宽也只有10000字节/秒，按照百兆系统计算也不足千分之一，况且这种情况几乎不会出现。所以使用这种同步方法，对于资源的损耗非常小，同步的速度稳定，且具有自修复能力，可以从错误中恢复。

还包括应用服务进程登录过程：

步骤1：在主机i上，应用服务进程j在天使服务进程i上登录，应用服务进程j调用天使客户端库的登录接口，传入自己的服务名jX；i＝1，2，…，N；j＝1，2，…，m；

步骤2：天使服务进程i接到应用服务进程j登录请求，按照服务名j查询查询本地极速配置库；

如果查到极速配置库里面存在该服务的配置，返回应用服务进程j的编号及登录成功的信息，修改极速配置库内应用服务进程j的登录状态为已经登录，转入步骤3；

如果没有查到极速配置库里面存在该服务的配置，返回-1及登录失败的信息；

步骤3：天使服务进程i将应用服务进程j的已登录状态广播发送给天使服务进程2到N；

天使服务进程2至天使服务进程N收到应用服务进程j的已登录状态，分别转入步骤4；

步骤4：天使服务进程2至天使服务进程N将应用服务进程j的已登录状态写入本地极速配置库。

还包括应用服务进程之间通信过程：

应用服务进程j向应用服务进程k发送一个消息；k＝1，2，…，m；k≠j；

步骤1：应用服务进程j通过本地极速配置库，按照应用服务进程k的服务名，查询应用服务进程k的编号与在线状态；若查询到应用服务进程的编号且应用服务进程的在线状态为在线，转入步骤2；反之，返回失败信息，通信结束；

步骤2：应用服务进程j构建消息包，向天使服务进程i发送该消息包；

步骤3：天使服务进程i收到该消息包，按照该消息包包头内容，查询极速配置库，查出应该转发的目标天使进程N，并查询目标天使进程N的在线状态；

步骤4：天使服务进程i将消息包发送给天使服务进程N；

步骤5：天使服务进程N收到该消息包，按照该消息包包头内容，查询极速配置库，查出应用服务进程k；

步骤6：天使服务进程N将消息包发送给应用服务进程k。

如图8所示，因为网络故障，导致进群分裂，分裂为2台与3台两个部分，在这种情况下，本通信中间件依旧可以使用。

当出现如图8所示的分裂的时候，如果使用开源消息队列技术，下面一半主机数目为2，将不能进行通信，上面主机数目为3，可以进行通信。如果上半部分再出现一台主机故障，上半部分也不能进行通信。

设左上方的应用服务进程为X，右上方的应用服务进程为Y，左下方的应用服务进程为F，右下方的应用服务进程为G；

本发明不存在这个问题，应用服务进程X与应用服务进程Y之间可以进行通信，应用服务进程F与应用服务进程G也可以进行通信。应用服务进程X与应用服务进程F不能进行通信的原因是因为网络或硬件故障，在物理上不具有连通性，与通信中间件无关，通信中间件提供了最大可能的可靠性。本例只是列举其中一种故障情况下本通信中间件的可靠性，其他类似的状况与故障不再一一列举。

如图9所示，天使客户端库提供了服务登录、登出、消息发送，消息接收回调四个接口，且只有四个接口，向应用服务进程提供了简单的使用方式。

应理解，本实施例仅用于说明本发明而不用于限制本发明的范围。此外应理解，在阅读了本发明讲授的内容之后，本领域技术人员可以对本发明作各种改动或修改，这些等价形式同样落于本申请所附权利要求书所限定的范围。