[发明专利]一种考虑网络负载的分布式电力用电信息数据采集系统

权利要求书

1.一种考虑网络负载的分布式电力用电信息数据采集系统，其特征在于：由所述系统执行以下步骤：

S1：基于异步事件驱动网络模型构建通信服务；

S1具体包括：

S1.1：借助EPOLL的I/O多路复用模型基于通讯频次构建高并发的网络通讯模型；

借助于EPOLL的事件通知机制，实时检测到网络通道上的读写就绪事件，根据相应的读写就绪事件，基于每个设备与通讯服务之间建立的网络连接上的通讯频次，对每一个设备维护一个数据写缓冲区和数据读缓冲区，其中读写缓冲区均具有一个回调函数，回调函数用来真正处理缓冲区中的数据，回调函数的应用，使主线程和上下行数据的处理过程剥离，使主线程专注于对读写缓冲的轮询判断，每个设备的数据由异步的回调函数处理，将需要下发的数据打包发送到网络通道或者将上行的数据发送到数据解析模块处理，业务处理线程按照通讯频次从大到小依次轮询处理每个设备对应缓冲区的数据；某个设备有数据需要下发时，将设备下行数据消息和当前时间写入设备对应的数据写缓冲区，当收到设备上行的数据后，收到EPOLL通知的读就绪事件后，从网络中读取数据，将设备上行数据消息和当前时间写入设备对应的数据读缓冲区；

业务处理线程以轮询的方式处理设备数据读写缓冲区，每次处理数据前对读写缓冲区按照通讯频次进行排序，每次轮询处理缓冲区中前1万个设备的数据，触发数据读写缓冲区对应的回调函数，对上行或下行数据进行真正的处理，并对读写缓冲区中通讯频次较低的设备的数据未处理时长是否达到一定的阈值，当达到一定的阈值时，触发数据读写缓冲区对应的回调函数，对上行或下行数据进行真正的处理；在处理数据读写缓冲区时，当某个设备有多条消息需要处理时，将多条消息打包成一个请求；

S1.2：通信服务使用主从Reactor多线程模型，一组线程池接收请求，一组线程池处理I/O；

通信服务端用于接收设备连接的不再是一个单独的I/O线程，而是一个独立的I/O线程池；监听线程组接收到设备网络连接的请求并处理完成后，将新创建的网络连接并注册到I/O线程池的某个I/O线程上，由它负责跟设备的网络连接的读写和数据的处理工作；监听线程组仅仅用于设备的登录、握手和安全认证，一旦链路建立成功，就将链路注册到I/O线程池的I/O线程上，由I/O线程负责后续的I/O操作；如果有数据需要下发到设备，由业务处理线程处理将需要下发的数据发送到I/O线程池对应的I/O通道上进行下发，如果设备有上行数据需要处理，则由I/O通道将数据发送给业务处理线程进行处理；

S1.3：对网络I/O操作进行异步处理；

通讯服务使用Future模式达到异步调用，在调用者提交任务后被调用者直接返回一个Future凭据，调用者在未来某个时间点根据Future凭据检查对应的调用是否返回结果，让原来需要同步等待的这段时间用来做其他的事情；

S2：基于分布式协调组件zookeeper构建分布式采集集群；

S2具体包括：基于ZooKeeper中事件监听器、异步通知和文件目录结构，构建弹性扩展的分布式采集集群；其中步骤如下：

S2.1：在Zookeeper里面创建名为cluster的永久节点，表示是整个采集服务集群的根节点；

S2.2：每一个采集服务节点启动时，在cluster的节点下创建自己的临时节点，并将自己的节点编号写入节点消息体中，表示此服务节点处于活跃状态；临时节点有个重要的特性，当创建此类节点的客户端与Zookeeper服务器的连接关闭时，此节点自动删除，利用此特性来感知采集服务节点的上下线；

S2.3：每个采集服务向ZooKeeper中的cluster节点注册监听器，监听cluster节点下节点的新增和删除事件；

S2.4：当采集服务监听到cluster节点下有新增或者删除事件时，获取新增或者删除的节点对应的编号，并更改集群变更标识；

S2.5：每个采集服务后一个后台守护线程每隔30s根据集群变更标识判断集群是否发生变更，若集群发生变更，等待60s后再次判断Zookeeper中的节点信息，是否和采集服务中保存的上一次节点信息一致，若一致，则不进行处理，认为是网络变更，向运维人员发送网络波动告警，若不一致，则触发设备档案重新分配的流程，每个采集服务重新负载到本服务节点的设备信息；

S3：设计考虑供需平衡的分布式负载管理模型；

S3具体包括：在分布式系统中，各个服务节点之间都需要相互通信来传输一些数据，包括通知当前节点上设备的在线/离线总数、当前节点的硬件负载信息；为了快速地将数据传输到各个分布式服务节点，借助图考虑供需平衡的分布式负载管理和调度；其中，具体步骤如下：

S3.1：构建分布式网络；

边的初始传输容量定义，设一条边的容量为：

其中k_i为节点i的度，即连接节点i的边的数量,k_j为节点j的度，即连接节点j的边的数量；b_ij为边介数，其值等于通过这条边的最短路径数量除以网络中总的最短路径数量；i和j为1至N的整数，N为初始时网络中的节点数量；

S3.2：网络负载统计；

设每个节点以概率p∈[0,1]生成p(N-1)个流量，分别随机选取分布式网络中的节点为目的地，同一个节点中的流量的目的地不能相同，即每个目的地只能对应一次流量生成；当网络中的所有节点都以概率p生成流量后，网络中的流量总需求为pN(N-1)；设每条流量对于边容量的需求为1，且流量的传输采用最短路径，记一条流量最短传输路径为：，其中e_ix为从i到x路径的边，e_xy为从x到y路径的边，...，e_zj为从z到j路径的边；

S3.3：容量分配和边的负载计算；

边e_xy的容量为所有经过该边的流量提供传输支持，其所能给某条流量分配的传输容量为：

其中c_xy为从x到y的传输容量，F_xy为边e_xy上所有流量的集合；I_ij为这条流量的优先级，随机选择I_ij∈[1,2,3,4,5]，5等级最高，以对应不同优先级的流量；

对于流量最短路径，边e_xy实际提供传输容量为：

即如果传输容量大于1则取1，否则采用通过计算得出的边e_xy所能提供的传输容量；考虑到路由上存在链路瓶颈效应，流量最短路径在网络中的传输效率为：，那么对于边e_xy来说，其总效率就是所有通过它的流量的传输效率总和，如下式所示：

S3.4：在分布式节点之间需要进行数据的传输时，数据发送的节点根据步骤S3.1-S3.3计算当前节点到目标节点所涉及所有边的传输效率，根据传输效率最高原则选择对应的边将数据通过分布式节点发送到目标节点；

S4：引入分布式消息中间件kafka处理剧增的业务数据；

S4具体包括：基于kafka构建高吞吐的消息处理机制，其中步骤如下：

S4.1：对于每个其他电力业务服务，定义一个用来发送消息和接收消息的主题，称topic；

S4.2：定义每个topic对应业务的消息格式；

S4.3：业务系统和采集服务分别订阅接收topic和发送topic；

S4.4：业务系统向消息发送topic发送消息后直接返回，处理自己的其他数据，不需要同步等待；

S4.5：采集服务采集到数据后向对应的接收消息的主题写入采集结果；

S4.6：业务系统收到采集服务返回的消息后进行对应的处理。