CN109788024B - 高可用高并发高性能分布式远程抄表采集服务器解决方法 - Google Patents
高可用高并发高性能分布式远程抄表采集服务器解决方法 Download PDFInfo
- Publication number
- CN109788024B CN109788024B CN201811480586.0A CN201811480586A CN109788024B CN 109788024 B CN109788024 B CN 109788024B CN 201811480586 A CN201811480586 A CN 201811480586A CN 109788024 B CN109788024 B CN 109788024B
- Authority
- CN
- China
- Prior art keywords
- task
- server
- master
- tasks
- time
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了高可用高并发高性能分布式远程抄表采集服务器解决方法,多个采集服务器使用orleans组成一个集群;同一时刻所有在运行的采集服务器进程中只有一个任务分发者:Master服务器Master服务器定期生成抄表记录到t_running表,定期到t_running表根据优先级高低顺和已经到时间需要执行的任务序获取到内存中,每次只获取部分任务;从数据库获取到的任务存在内存一个队列中;本发明还公开了其他的一些技术特征。本发明增加整个采集系统的稳定性、高可用性,在集群中某台或者某几台机器宕机后不影响整个系统的运行;均衡的分布式处理方式使得集群中每台机器都处理相对均匀的任务,使整体资源得到更合理的利用,避免某些服务器任务过载某些服务器无任务处理。
Description
技术领域
本发明涉及计算机软件系统中与智能电表、集中器或者网关的数据采集、数据交互的服务器端系统架构、系统设计的解决方案。尤其涉及大批量、实时性要求较高的智能电表的数据采集和数据交互系统,特别涉及一种高可用高并发高性能分布式远程抄表采集服务器解决方法。
背景技术
随着电子技术的发展出现越来越多的用到小型智能终端设备如各类传感器、智能手机、智能电表、网络摄像机等等,这是一个物联网的时代;光有智能设备不足以满足人类的要求,智能设备被安装后人们要求对每个角落的每块设备进行远程访问控制,尤其是需要实时的采集到这些智能设备的各种数据并对这些数据进行加工处理。本发明不涉及对大数据的加工处理和分析,本发明只针对如何远程实时高效的与智能电表交互数据。其中终端智能电表可通过GPRS、以太网接入到主站服务器,也可以通过plc或者RF连接到集中器或者网关,再由集中器或者网关连接到主站。
比如现在需要采集一个超大城市的所有智能电表数据(如实时采集每15分钟的电能负荷曲线),有如下一系列需求或前提条件:
·这个城市可能安装了超过500万只智能电表
·要求30分钟内采集完所有500万只电表数据
·有的电表是通过网关或者集中器连接到主站服务器,一个网关下可能连接几百块plc电表,并且同一时间网关只能与下面一个电表进行通讯
·并且期间可能有相当部分电表还存在其它任务要处理如远程拉合闸充费等等。
·同一个集中器下的所有电表任务只能同时在一个地方被处理,一次只能处理一块电表的众多任务之一否则会冲突导致任务处理失败
·同一个GPRS电表的所有任务也只能同时在一个地方被处理,一次只能处理该块表众多任务之一否则会冲突
·所有任务,包括抄读电表数据、远程拉合闸等所有任务需要分优先级,优先级高的任务优先处理,同一个电表同时有很多任务需要处理时优先处理,对于给定的某个电表同一时刻只处理一个任务
·如果是抄读冻结数据优先级相同的情况下需要先执行距离当前时间最近的任务,其余任务按时间先后执行
·对于需要远程充值的预付费电表系统,要求实时完成一半用户的同时远程充费操作
·采集服务器不能超过15台(包括虚拟机和防挂备用机)
对于类似这种大批量相对实时的数据采集系统目前一般的解决办法为选定其中一台服务器作为任务分发处理中心,通过rpc(远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议)将排序后的任务分发到其它采集服务器,其它服务器接收到任务后访问终端智能设备最后将结果(成功或者失败的结果)返回到任务分发者。这些解决方案都存在或多或少的缺陷,有的缺陷甚至是致命的。
·指定的任务分发者服务器挂掉后整个系统的任务处理都停滞了
·其它任务接收服务器短时间内如果接收到大量任务比如20万个任务难以做到如此高的并发处理,传统的做法是对每个任务分配一个线程去处理但分配的线程数达到一定数量后整个系统将会变得非常卡顿甚至进程挂掉。比较好的处理方式是使用异步处理方式访问终端设备使用异步等待等技术,但存在如何有效的管理如此大量的异步IO请求也是非常困难的稍有不慎也会是整个系统崩溃
·任务分发者需要和其它服务器保持心跳以便检测其它服务器是否存活,如果该服务器存活则分派任务否则不分派任务到该服务器
·任务处理服务器需要和任务分发者服务器保持心跳,以便在任务处理结束后通知任务处理结果
·任务分发者如何做到均衡不冲突的分发任务到其它服务器也是一大难题,传统解决方法需要任务分发者记录当前哪些设备已经有任务正在被处理,哪些任务被分派到了哪台服务器,每台服务器当前被分派了多少个任务;收到其它服务器返回的任务处理结果时要同步更新分派的任务数,并且需要设定超时检测功能以便检测分派到其它服务器的任务如果没有反馈将任务重新分派等等
·如果任务分发者服务器挂机如何让其它存活的服务器接管任务分配,如何将挂机时刻任务分发者的各种任务分配信息移交到新的任务分发者等等
以上只是列举了一些传统解决方案的不足或者缺陷,不难看出使用传统解决方案系统复杂性非常高、易出错,出了问题难以查找问题原因难以做到高可用、高并发、高性能等。
发明内容
针对传统大量智能电表设备数据采集方案存在的技术不足,本发明主要解决的技术问题是提供一种数据采集方案,其特征是高可用、高并发、高性能、分布式、实时性,该方案能够解决以上传统做法的各种缺陷和不足。
本发明的目的是通过以下技术方案来实现的:
高可用高并发高性能分布式远程抄表采集服务器解决方法,多个采集服务器使用orleans组成一个集群;
同一时刻所有在运行的采集服务器进程中只有一个任务分发者:Master服务器;
Master服务器定期生成抄表记录到t_running表,定期到t_running表根据优先级高低顺和已经到时间需要执行的任务序获取到内存中,每次只获取部分任务;
从数据库获取到的任务存在内存一个队列中;
另外单独有一个线程每隔若干毫秒检测这个队列,如果发现队列有数据则对队列中的任务再次根据时间优先级排序和设备id进行分组,对当前空闲的设备挑选出其设备下的任务,并通过orleans客户端发送任务到集群中;
发送任务时以设备id作为grain的identity,以任务的具体信息作为请求内容发送,orleans集群自动实例化和管理每个grain的生命周期。
作为优选方式,Master服务器由以下方式产生:
a.首先设计数据表t_Master和t_running,分别用于记录当前Master服务器的信息和任务信息,其中t_Master表字段Mastermark需要设定唯一约束;
b.每个采集服务器(Master服务器也属于采集服务器)进程启动后开启一个后台线程,该线程每隔0-180秒内的随机时间检测数据库表t_Master里面的记录,如果该表没记录则把自己作为Master服务器添加进去,如果添加成功则该进程成为Master服务器并开始履行Master服务器的职责;每个采集器服务器需要更新t_Master表记录时使用相同的Mastermark值,这样通过数据库的唯一约束防止多个采集服务器同时更新该表,起到加锁的功能,保证只有一个采集服务器能更新成功,更新成功的采集器成为Master角色;
c.一旦一个采集服务器成为Master服务器后除非进程崩溃、掉电、机器重启、强行关闭、连接不上数据库,否则该角色会一直扮演下去;
d.Master服务器定期(默认间隔20秒)更新t_Master的在线时间;
e.其它非Master采集服务器(采集服务器包括Master服务器和非Master采集服务器)定期检测t_Master运行情况,如果发现Master记录的在线时间超过120秒则认为系统当前没有健康的Master服务器存在,然后把t_Master中旧的记录删除,如果删除成功则把自己作为Master添加进去,如果添加成功则开始履行Master服务器的职责;新的Master服务器会重新到t_running表加载任务,由于切换Master服务器的时间间隔比访问一次前端设备的时间要长,所以新的Master服务器接管任务分派职责后在t_running表中的任务全都是未做或者做失败的任务。
作为优选方式,Master服务器定期从redis中获取分出去的任务执行结果并根据结果清理自己在内存中的任务,将执行成功的任务从队列删除,失败的任务重新入队。
作为优选方式,Master服务器定期检测分发出去的任务是否丢失(如果在6分钟以内没有执行结果返回到redis中则任务该任务丢失),对于丢失的任务重新分发。
作为优选方式,如果有新的采集服务器加入到集群则不需要做任何操作,新的采集服务器正常启动后Master服务器自动检测到并开始给其分配任务。
作为优选方式,如果有采集服务器退出集群无需做任何操作,Master服务器会检测到该服务器的退出并将分配给该进程的但是没有做完的任务重新分配给其它采集服务器处理。
作为优选方式,每个被分派任务的采集服务器自行处理任务,利用异步IO和orleans的高并发管理机制可同时大量访问前端智能设备;
如果任务处理成功则自行删除t_running表记录并增加历史记录到his表,同时发送任务完成结果到redis;
如果任务处理失败则判断是否该任务还有重试次数如果有则将重试次数减1和更新任务下次执行时间随同设备id等其它信息作为处理结果写到redis,随后再由Master服务器继续处理该任务,如果没有重试次数则删除running表记录并增加历史到his,同时发送任务完成的结果到redis。
作为优选方式,Master服务器对超过一定时间的任务从t_running表删除。
作为优选方式,
grain接口:在收到具体任务后采用异步IO请求的方式向前端终端发起请求,请求发出后处于异步等待状态,所以资源得以释放并可以处理其它的任务接收或者前端设备的数据返回;
如果任务处理成功则自行删除t_running表记录并增加历史记录到his表,同时发送任务完成结果到redis;
如果任务处理失败则判断是否该任务还有重试次数如果有则将重试次数减1和更新任务下次执行时间随同设备id等其它信息作为处理结果写到redis,随后再由Master服务器继续处理该任务,如果没有重试次数则删除t_running表记录并增加历史到his,同时发送任务完成的结果到redis。
本发明的有益效果是:
·增加整个采集系统的稳定性、高可用性,在集群中某台或者某几台机器宕机后不影响整个系统的运行;
·均衡的分布式处理方式使得集群中每台机器都处理相对均匀的任务,使整体资源得到更合理的利用,避免某些服务器任务过载某些服务器无任务处理;
·增加了系统的吞吐量和性能,在短时间内可以处理大量的对前端设备的访问;经测试环境测试集群中单个节点可在1分钟内访问10万个前端设备,并且还有余量,如果发送任务速度更快那么1分钟内访问的前端设备会更多;
·相对传统做法节省了大量硬件服务器,采用本发明后单节点可同时支持10万个访问;旧方式只能取决于操作系统的可用线程,一般某个进程占用超过5千个线程时性能会变得严重低下甚至死机。
附图说明
图1为以orleans作为中间件的高可用性示意图;
图2为grain的生命周期示意图;
图3为本发明的较佳实施实例。
具体实施方式
下面结合附图进一步详细描述本发明的技术方案,但本发明的保护范围不局限于以下所述。
本发明涉及一种分布式、高并发、高性能、高吞吐、高可用性和高可扩展(或收缩)的与智能电表、集中器或者网关等设备的数据交互系统软件解决方案。在面对需要与大批量智能电表设备(如几百上千万只智能电能表)进行相对实时(如在30分钟内采集完成500万只智能电表冻结数据)数据交互时,往往面临诸多难题;如面临短时间内要处理的数据量非常大,硬件服务器资源昂贵不可能部署成百上千台服务器,即便有这么多服务器资源如何均匀不冲突的分摊交互任务也是一大难题,某些服务器宕机后剩余的可用服务器如何快速的接管处理任务和故障恢复,同一个终端设备(集中器或网关)同一时刻只有一个通讯通道可用此时就要求整个系统同一时刻对同一个设备保证处理任务是串行的,当终端设备增加或者减少时整个系统如何做到收放自如等等。针对以上种种难题本发明提供一种透明的、高并发、容错性非常高的分布式处理解决方法。
如图1所示,高可用高并发高性能分布式远程抄表采集服务器解决方法,多个采集服务器使用orleans组成一个集群;(引入orleans作为程序的中间件,包括引入orleans的各种库和依赖环境如数据库脚本,zookeeper等(具体根据实际选择一种))
同一时刻所有在运行的采集服务器进程中只有一个任务分发者:Master服务器,不用人为干预谁先抢到谁就成为Master服务器;(Master服务器用于:任务生成、任务获取、任务分发、任务处理结果管理、超时检测等等,可根据具体的业务需求做更多的功能增加)
Master服务器定期生成抄表记录到t_running表,生成间隔时间可配置,定期到t_running表根据优先级高低顺和已经到时间需要执行的任务序获取到内存中,每次只获取部分任务比如5万条,默认间隔30秒获取一次,所有间隔时间和条数等参数都可配置;
从数据库获取到的任务存在内存一个队列中;(所有的表都建立在数据库中)
另外单独有一个线程每隔若干毫秒(比如10毫秒)检测这个队列,如果发现队列有数据则对队列中的任务再次根据时间优先级排序和设备id进行分组,对当前空闲的设备挑选出其设备下的任务,并通过orleans客户端发送任务到集群中;
发送任务时以设备id作为grain的identity,以任务的具体信息比如抄读时间范围、重试次数等作为请求内容发送,orleans集群自动实例化和管理每个grain(需要编写任务分发接收处理grain接口,该接口至少需要定义一个能够接收任务实例的接口)的生命周期;grain的生命周期如图2所示。客户端请求某个grain时并不需要事先知道该grain是否已经被实例化、存在位置;客户端只需要向orleans集群发起请求即可,如果集群中没有该grain的实例则orleans运行时会挑选一台相对资源空闲比较多的服务器并实例化该grain,客户端的请求会被重定向到该服务器上;如果在相当一段时间都没有任何对某个grain的请求则运行时自动将该grain销毁并回收所占资源;所以对客户端而言grain永远随时可用,完全不需要关心其它细节。
优选地,调试、编译打包部署,使用真实连接有智能电表的环境进行测试、验证。
从图1可以看出,集群中某台服务器挂掉后并不影响Frontends的访问请求,对于Frontends而言集群中某个服务器的宕机并不可见。在失败服务器上的grain会被集群中其它服务器重新激活。
借助orleans的特性所以不需要关心任务的具体底层数据发送和接收端如何接收并激活任务,并且orleans运行时自动均衡的分派任务到集群中的每台机器。即使在运行一段时候后突然新加了一台采集服务器到集群中,orleans会将集群中旧的服务器上存在的部分grain转移到新加的服务器上,自动实现负载均衡。如图3所示,Master服务器是从采集服务器中产生的,其他非Master采集服务器通过网络与电表连接。其中DB代表关系型数据库,如oracle、mysql、mssql;Master采集服务器:具有master角色且为orleans集群中的一个节点采集服务器:orleans集群中的普通节点。
在一个优选实施例中,Master服务器由以下方式产生:(根据以下内容可以实现Master服务器的检测和更新)
a.首先设计数据表t_Master和t_running,分别用于记录当前Master服务器的信息和任务信息,其中t_Master表字段Mastermark需要设定唯一约束;
b.每个采集服务器(Master服务器也属于采集服务器)进程启动后开启一个后台线程,该线程每隔0-180秒内的随机时间检测数据库表t_Master里面的记录,如果该表没记录则把自己作为Master服务器添加进去,如果添加成功则该进程成为Master服务器并开始履行Master服务器的职责;每个采集器服务器需要更新t_Master表记录时使用相同的Mastermark值,这样通过数据库的唯一约束防止多个采集服务器同时更新该表,起到加锁的功能,保证只有一个采集服务器能更新成功,更新成功的采集器成为Master角色;
c.一旦一个采集服务器成为Master服务器后除非进程崩溃、掉电、机器重启、强行关闭、连接不上数据库,否则该角色会一直扮演下去;
d.Master服务器定期(默认间隔20秒)更新t_Master的在线时间;
e.其它非Master采集服务器(采集服务器包括Master服务器和非Master采集服务器)定期检测t_Master运行情况,如果发现Master记录的在线时间超过120秒则认为系统当前没有健康的Master服务器存在,然后把t_Master中旧的记录删除,如果删除成功则把自己作为Master添加进去,如果添加成功则开始履行Master服务器的职责;新的Master服务器会重新到t_running表加载任务,由于切换Master服务器的时间间隔比访问一次前端设备的时间要长,所以新的Master服务器接管任务分派职责后在t_running表中的任务全都是未做或者做失败的任务。
在一个优选实施例中,Master服务器定期从redis中获取分出去的任务执行结果并根据结果清理自己在内存中的任务,将执行成功的任务从队列删除,失败的任务重新入队。
在一个优选实施例中,Master服务器定期检测分发出去的任务是否丢失(如果在6分钟以内没有执行结果返回到redis中则任务该任务丢失),对于丢失的任务重新分发。
在一个优选实施例中,如果有新的采集服务器加入到集群则不需要做任何操作,新的采集服务器正常启动后Master服务器自动检测到并开始给其分配任务。
在一个优选实施例中,如果有采集服务器退出集群无需做任何操作,Master服务器会检测到该服务器的退出并将分配给该进程的但是没有做完的任务重新分配给其它采集服务器处理。
在一个优选实施例中,每个被分派任务的采集服务器自行处理任务,利用异步IO和orleans的高并发管理机制可同时大量访问前端智能设备;
如果任务处理成功则自行删除t_running表记录并增加历史记录到his表,同时发送任务完成结果到redis;
如果任务处理失败则判断是否该任务还有重试次数如果有则将重试次数减1和更新任务下次执行时间随同设备id等其它信息作为处理结果写到redis,随后再由Master服务器继续处理该任务,如果没有重试次数则删除running表记录并增加历史到his,同时发送任务完成的结果到redis;结果从右边push到redis list(key:jobresult)。
在一个优选实施例中,Master服务器对超过一定时间的任务,比如抄负荷曲线的任务超过1天后则从t_running表删除,每种任务的过期时间可配置。
在一个优选实施例中,grain接口:在收到具体任务后采用异步IO请求的方式向前端终端发起请求,请求发出后处于异步等待状态,所以资源得以释放并可以处理其它的任务接收或者前端设备的数据返回;
如果任务处理成功则自行删除t_running表记录并增加历史记录到his表,同时发送任务完成结果到redis;
如果任务处理失败则判断是否该任务还有重试次数如果有则将重试次数减1和更新任务下次执行时间随同设备id等其它信息作为处理结果写到redis,随后再由Master服务器继续处理该任务,如果没有重试次数则删除running表记录并增加历史到his,同时发送任务完成的结果到redis;结果从右边push到redis list(key:jobresult)。
名称解释:
Redis:一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言访问的API。
Grain:orleans是Actor Model编程思想一种二次发明,最重要的发明点就在于将Actor进行虚拟化处理,虚拟化的actor在orleans中称为grain。
本发明提出一种数据采集方案,该方案涉及一种计算机软件开发设计方法。该方案的中间件采用微软研究院(Microsoft Research and designed for use in thecloud)的开源项目“Orleans”。Orleans设计思想来源于1970年代提出的Actor Model程序设计思想,并经过微软研究院二次发明成为Virtual Actors编程模型,该特性使得开发者不必关心后台actor的生命周期,对开发者而言actor随时随地可用。Orleans被许多大型公司采用如visa、Honeywell、Microsoft Stusios 343Studios(Halo),Age of Empires,BigPark,Black Tusk。主要被游戏开发领域作为后台状态服务或者实时在线缓存信息处理等。Orleans具有高并发性和位置透明性,高并发是指保证一个grain某个时刻只能被一个线程执行属于线程安全的,并且整个运行时可在多核cpu的优势下并发执行大量的grain代码;位置透明性指调用者不需要知道grain的激活等细节,调用者只需要发出对相关grain的请求不必关心该grain是否已经被激活、该grain存在或者应该在集群中哪台服务器激活等。此外orleans还具有自动负载均衡和高可扩展收缩性,orleans运行时能自动检测到过载的服务器并将该服务器上的部分grain转移到其它资源剩余比较多的服务器上。
本发明使用orleans的部分功能加上其它算法设计使得数据采集系统变得容易容错性高性能高等特点。包括任务分发者的自动选举和产生,任务分发处理中心对任务的统一管理、优先级排序、任务分发回收记录、超时检测、任务重入队,任务的分派和接收,任务处理者任务的异步IO处理方式、任务处理结果返回给任务分发者的处理方式。
采用该方案后在电力远程智能抄表系统中使服务器硬件资源大幅减少,性能和效率比原来提升50倍以上,高可用且低延迟(在预付费系统中可同时为几十万个客户远程实时充费)并可以高可用的在集群内统一处理定期任务如每天删除一次过期日志、清理数据库过期记录、缓存oracle数据库记录到内存数据库等等。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,应当指出的是,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。
Claims (9)
1.高可用高并发高性能分布式远程抄表采集服务器解决方法,其特征在于:多个采集服务器使用orleans组成一个集群;
同一时刻所有在运行的采集服务器进程中只有一个任务分发者:Master服务器;
Master服务器定期生成抄表记录到t_running表,定期到t_running表根据优先级高低顺序和已经到时间需要执行的任务获取到内存中,每次只获取部分任务;
从数据库获取到的任务存在内存一个队列中;
另外单独有一个线程每隔若干毫秒检测这个队列,如果发现队列有数据则对队列中的任务再次根据时间优先级排序和设备id进行分组,对当前空闲的设备挑选出其设备下的任务,并通过orleans客户端发送任务到集群中;
发送任务时以设备id作为grain的identity,以任务的具体信息作为请求内容发送,orleans集群自动实例化和管理每个grain的生命周期。
2.根据权利要求1所述的高可用高并发高性能分布式远程抄表采集服务器解决方法,其特征在于,Master服务器由以下方式产生:
a.首先设计数据表t_Master和t_running,分别用于记录当前Master服务器的信息和任务信息,其中t_Master表字段Mastermark需要设定唯一约束;
b.每个采集服务器进程启动后开启一个后台线程,该线程每隔0-180秒内的随机时间检测数据库表t_Master里面的记录,如果该表没记录则把自己作为Master服务器添加进去,如果添加成功则该进程成为Master服务器并开始履行Master服务器的职责;每个采集器服务器需要更新t_Master表记录时使用相同的Mastermark值,这样通过数据库的唯一约束防止多个采集服务器同时更新该表,起到加锁的功能,保证只有一个采集服务器能更新成功,更新成功的采集器成为Master角色;
c.一旦一个采集服务器成为Master服务器后除非进程崩溃、掉电、机器重启、强行关闭、连接不上数据库,否则该角色会一直扮演下去;
d.Master服务器定期更新t_Master的在线时间;
e.其它非Master采集服务器定期检测t_Master运行情况,如果发现Master记录的在线时间超过120秒则认为系统当前没有健康的Master服务器存在,然后把t_Master中旧的记录删除,如果删除成功则把自己作为Master添加进去,如果添加成功则开始履行Master服务器的职责;新的Master服务器会重新到t_running表加载任务,由于切换Master服务器的时间间隔比访问一次前端设备的时间要长,所以新的Master服务器接管任务分派职责后在t_running表中的任务全都是未做或者做失败的任务。
3.根据权利要求1所述的高可用高并发高性能分布式远程抄表采集服务器解决方法,其特征在于:Master服务器定期从redis中获取分出去的任务执行结果并根据结果清理自己在内存中的任务,将执行成功的任务从队列删除,失败的任务重新入队。
4.根据权利要求1所述的高可用高并发高性能分布式远程抄表采集服务器解决方法,其特征在于:Master服务器定期检测分发出去的任务是否丢失,对于丢失的任务重新分发。
5.根据权利要求1所述的高可用高并发高性能分布式远程抄表采集服务器解决方法,其特征在于:如果有新的采集服务器加入到集群则不需要做任何操作,新的采集服务器正常启动后Master服务器自动检测到并开始给其分配任务。
6.根据权利要求1所述的高可用高并发高性能分布式远程抄表采集服务器解决方法,其特征在于:如果有采集服务器退出集群无需做任何操作,Master服务器会检测到该服务器的退出并将分配给该进程的但是没有做完的任务重新分配给其它采集服务器处理。
7.根据权利要求1或2或3所述的高可用高并发高性能分布式远程抄表采集服务器解决方法,其特征在于:每个被分派任务的采集服务器自行处理任务,利用异步IO和orleans的高并发管理机制可同时大量访问前端智能设备;
如果任务处理成功则自行删除t_running表记录并增加历史记录到his表,同时发送任务完成结果到redis;
如果任务处理失败则判断是否该任务还有重试次数,如果有则将重试次数减1和更新任务下次执行时间随同设备id作为处理结果写到redis,随后再由Master服务器继续处理该任务,如果没有重试次数则删除t_running表记录并增加历史记录到his,同时发送任务完成的结果到redis。
8.根据权利要求2所述的高可用高并发高性能分布式远程抄表采集服务器解决方法,其特征在于:Master服务器对超过一定时间的任务从t_running表删除。
9.根据权利要求1所述的高可用高并发高性能分布式远程抄表采集服务器解决方法,其特征在于:
grain接口:在收到具体任务后采用异步IO请求的方式向前端终端发起请求,请求发出后处于异步等待状态,所以资源得以释放并可以处理其它的任务接收或者前端设备的数据返回;
如果任务处理失败则判断是否该任务还有重试次数,如果有则将重试次数减1和更新任务下次执行时间随同设备id作为处理结果写到redis,随后再由Master服务器继续处理该任务,如果没有重试次数则删除t_running表记录并增加历史到his,同时发送任务完成的结果到redis。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811480586.0A CN109788024B (zh) | 2018-12-05 | 2018-12-05 | 高可用高并发高性能分布式远程抄表采集服务器解决方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811480586.0A CN109788024B (zh) | 2018-12-05 | 2018-12-05 | 高可用高并发高性能分布式远程抄表采集服务器解决方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109788024A CN109788024A (zh) | 2019-05-21 |
CN109788024B true CN109788024B (zh) | 2021-08-24 |
Family
ID=66496662
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811480586.0A Active CN109788024B (zh) | 2018-12-05 | 2018-12-05 | 高可用高并发高性能分布式远程抄表采集服务器解决方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109788024B (zh) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110990165B (zh) * | 2019-11-15 | 2020-10-09 | 北京连山科技股份有限公司 | 多路并发传输系统中多用户同时工作的方法及传输服务器 |
CN111212336B (zh) * | 2019-12-31 | 2022-08-12 | 杭州海兴电力科技股份有限公司 | 一种抄表系统和方法 |
CN112286962B (zh) * | 2020-10-26 | 2023-06-02 | 积成电子股份有限公司 | 一种用电信息采集终端抄表成功率统计方法与系统 |
CN114167794A (zh) * | 2021-12-20 | 2022-03-11 | 苏州易助能源管理有限公司 | 一种智能电表远程数据采集系统及数据采集方法 |
CN115474109B (zh) * | 2022-11-01 | 2023-02-03 | 安徽博诺思信息科技有限公司 | 一种基于can总线的电力系统多线程通讯方法及系统 |
CN117478605B (zh) * | 2023-12-25 | 2024-03-22 | 深圳龙电华鑫控股集团股份有限公司 | 一种负载均衡方法、集中器、电表及存储介质 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107123252A (zh) * | 2017-05-27 | 2017-09-01 | 南京林洋电力科技有限公司 | 一种m‑bus并线器及其智能切换电路 |
CN107948216A (zh) * | 2016-10-09 | 2018-04-20 | 四川智康科技有限责任公司 | 一种基于soa构架的医院集中数据分析应用云平台 |
EP3313051A1 (de) * | 2016-10-20 | 2018-04-25 | Hausheld Energieberatung GmbH | Verfahren zur adressvergabe für eine vielzahl von zählern zur verbrauchsmessung sowie system aus master-adapter und slave-adapter |
CN108234185A (zh) * | 2016-12-22 | 2018-06-29 | 成都长城开发科技有限公司 | 自动抄表系统及其构建方法 |
CN108280150A (zh) * | 2018-01-05 | 2018-07-13 | 宝付网络科技(上海)有限公司 | 一种分布式异步业务分发方法及系统 |
-
2018
- 2018-12-05 CN CN201811480586.0A patent/CN109788024B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107948216A (zh) * | 2016-10-09 | 2018-04-20 | 四川智康科技有限责任公司 | 一种基于soa构架的医院集中数据分析应用云平台 |
EP3313051A1 (de) * | 2016-10-20 | 2018-04-25 | Hausheld Energieberatung GmbH | Verfahren zur adressvergabe für eine vielzahl von zählern zur verbrauchsmessung sowie system aus master-adapter und slave-adapter |
CN108234185A (zh) * | 2016-12-22 | 2018-06-29 | 成都长城开发科技有限公司 | 自动抄表系统及其构建方法 |
CN107123252A (zh) * | 2017-05-27 | 2017-09-01 | 南京林洋电力科技有限公司 | 一种m‑bus并线器及其智能切换电路 |
CN108280150A (zh) * | 2018-01-05 | 2018-07-13 | 宝付网络科技(上海)有限公司 | 一种分布式异步业务分发方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN109788024A (zh) | 2019-05-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109788024B (zh) | 高可用高并发高性能分布式远程抄表采集服务器解决方法 | |
US11397709B2 (en) | Automated configuration of log-coordinated storage groups | |
Sreekanti et al. | A fault-tolerance shim for serverless computing | |
US10373247B2 (en) | Lifecycle transitions in log-coordinated data stores | |
Zhou et al. | Foundationdb: A distributed unbundled transactional key value store | |
EP2633400B1 (en) | Stateful applications operating in a stateless cloud computing environment | |
Li | Alluxio: A virtual distributed file system | |
CN112667362B (zh) | Kubernetes上部署Kubernetes虚拟机集群的方法与系统 | |
CN101707399A (zh) | 电能信息采集方法及系统 | |
CN109684032A (zh) | 防脑裂的OpenStack虚拟机高可用计算节点装置及管理方法 | |
CN109634716A (zh) | 防脑裂的OpenStack虚拟机高可用管理端装置及管理方法 | |
WO2016044763A1 (en) | Automated configuration of log-coordinated storage groups | |
CN109614201A (zh) | 防脑裂的OpenStack虚拟机高可用系统 | |
CN112269781A (zh) | 数据生命周期管理方法、装置、介质及电子设备 | |
CN113157411B (zh) | 一种基于Celery的可靠可配置任务系统及装置 | |
EP4379554A1 (en) | Data processing method and apparatus, and device, storage medium and program product | |
CN114064414A (zh) | 一种高可用的集群状态监控方法及系统 | |
US20210303327A1 (en) | Gpu-remoting latency aware virtual machine migration | |
US10817285B1 (en) | Transactional migration system | |
CN112565416B (zh) | 基于云原生的大规模边缘安卓设备纳管系统及其纳管方法 | |
Ilin et al. | Performance analysis of software with a variant NoSQL data schemes | |
Folliot et al. | GATOSTAR: A fault tolerant load sharing facility for parallel applications | |
CN109032809A (zh) | 基于遥感影像存储位置的异构并行调度系统 | |
Gasiunas et al. | Fiber-based architecture for NFV cloud databases | |
Marra et al. | A debugging approach for big data applications in pharo |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
CP03 | Change of name, title or address |
Address after: 611731 No. 99, Tianquan Road, high tech Zone, Chengdu, Sichuan Patentee after: Chengdu Great Wall Development Technology Co.,Ltd. Address before: 611731 no.1218, Hezuo Road, high tech Zone (West District), Chengdu, Sichuan Province Patentee before: CHENGDU GREAT WALL DEVELOPMENT TECHNOLOGY Co.,Ltd. |
|
CP03 | Change of name, title or address |