一种金融设备软件的升级方法与流程

文档序号:12787470阅读:238来源:国知局
一种金融设备软件的升级方法与流程

本发明涉及金融设备技术领域,尤其涉及一种金融设备软件的升级方法。



背景技术:

对于银行来说,存在着大量的金融机具,如:点钞机、清分机、自动取款机(Automatic Teller Machine,ATM)、存取款一体机、远程柜员机(Video Teller Machine,VTM)、捆钞机等等。这些金融机具,由于某种原因,经常需要对其进行软件升级,典型的如“新币发行”导致的金融机具升级。

传统的金融机具的软件升级,是通过人工的方式,对所有的金融机具进行一台一台的升级。可以想象,传统的软件升级方式,给银行和机具厂家带来了很多的问题,通过人工的方法对每一台金融设备升级,人工费用高,由于人工费用高,无法对金融设备的升级做很大的并行升级工作,导致了银行服务的时间损失,在操作的过程中,也很容易出现各种错误,导致升级过程更加漫长。另外,除了在设备软件升级方便,对金融机具的管理、维护等等,也有同样的问题。

从2011年起,人民银行要求银行现金设备(A类点钞机,清分机和ATM)具备识别人民币冠字号功能,并且以标准FSN文件格式向中心汇报,这样所有的银行现金设备都必须具备联网功能。大银行的省级分行下辖众多网点拥有各类现金设备从几千到几万不等,其中A类点验钞机占比最高。

对众多现金设备的管理,包括远程监控,升级管理,黑名单管理,设备参数管理,数据汇总等成为难题,特别是在后台对设备的指令管理往往需要分地区单独分设服务器,比较占用服务器资源,也不便服务器维护和管理。

在升级或其他管理过程中,我们将服务器和机具的每一次通讯过程,称之为一次指令下发。那么,系统要解决指令的如下问题:

1)指令在未下发之前,必须持久化,保证指令不丢失;

2)指令的范围,指令的下发有范围的限制,在线升级存在无法扩展到更多金融机具的问题;

3)在线升级带来的大压力的升级入库问题;

4)指令下发的整个过程存在生命周期,如生成、池化、下发、接收、完成等过程,这些过程指示着指令是否被机具执行;

5)根据指令的生命周期所产生的一系列报表,如有多少指令,指令下发了多少,指令完成了多少,多少机器需要重新下发指令等。



技术实现要素:

针对现有技术中存在的问题,本发明提供了一种能够快速对至少一个金融设备的软件进行升级的金融设备软件的升级方法。

本发明采用如下技术方案:

一种金融设备软件的升级方法,适用于不同类型的客户端,所述客户端包括第一客户端和第二客户端;所述方法包括如下步骤:

步骤S1、采用一指令规划器接收指令请求;

步骤S2、所述指令规划器解析接收到的所述指令请求,并持久化所述指令请求到一数据库的指令列表中;

步骤S3、所述指令规划器根据解析的所述指令请求的内容,为请求范围内的每个所述客户端生成一条指令,规划所述指令的执行时间,并持久化所述指令到所述数据库的指令表中,并标识所述指令的指令状态为创建;

步骤S4、采用一任务安排器定时读取指令请求表,根据对应于所述第一客户端的第一指令请求的编号从所述指令表中提取对应于所述第一客户端的第一指令并存储,以及根据对应所述第二客户端的第二指令请求的编号从所述指令表中提取对应于所述第二客户端的第二指令并存储;

步骤S5、对所述第一指令和所述第二指令分别进行下发处理操作以更新所述第一客户端和所述第二客户端;

步骤S6、所述指令规划器根据所述下发处理操作后更新所述指令状态为发送并放入指令更新队列,由指令更新线程自动异步更新所述指令状态;

步骤S7、所述客户端接收到所述指令后,发送指令状态更新请求,所述指令规划器更新所述指令状态为接收并放入所述指令状态更新队列,由所述指令状态更新线程自动异步更新所述指令状态;

步骤8:所述客户端完成指令执行后,发送指令状态更新请求,所述指令规划器更新所述指令状态为完成并放入所述指令状态更新队列,由所述指令状态更新线程自动异步更新所述指令状态。

优选的,所述第一客户端包括一个启动节点端和多个关联于所述启动节点端的调动端,所述启动节点端设有节点服务器,所述调动端设有关联于所述节点服务器的调动服务器。

优选的,所述步骤S4包括:

步骤S41a、所述任务安排器定时读取所述指令请求表,获取未处理的所述指令请求的编号,定义未处理的所述指令请求的编号为所述第一指令请求的编号;

步骤S42a、所述指令规划器根据所述第一指令请求的编号从所述指令表中提取所述第一指令;

步骤S43a、所述指令规划器将所述第一指令放入指令池。

优选的,所述步骤S5包括:

步骤S51a、所述指令规划器向所述启动节点端下发启动命令;

步骤S52a、所述启动节点端接收所述启动命令后向每个关联于所述启动节点端的所述调动端发送调动命令;

步骤S53a、所述启动节点端和所述调动端分别向所述指令规划器发送所述指令请求来获取所述第一指令;

步骤S54a、所述指令规划器从所述指令表中提取相应的所述第一指令并下发给所述启动节点端和所述调动端。

优选的,所述步骤S4包括:

步骤S41b、所述任务安排器定时读取指令请求表,获取所有所述指令请求的编号,定义所述指令请求的编号为所述第二指令请求的编号;

步骤S42b、所述指令规划器根据所述第二指令请求的编号从所述指令表中提取所述第二指令;

步骤S43b、所述指令规划器将所述第二指令按照key/value的方式缓存至一Redis服务器。

优选的,所述步骤S5包括:

步骤S51b、所述第二客户端向所述指令规划器发送所述指令请求来获取所述第二指令;

步骤S52b、所述指令规划器从所述指令表中提取相应的所述第二指令并下发给所述第二客户端。

优选的,所述指令规划器通过HTTP、消息或socket接口接收所述指令请求。

优选的,所述步骤S2中所述指令规划器把所述指令请求,根据系统设置的参数和逻辑,计算出指令发布的时间,并维护所述指令状态。

优选的,所述步骤3中所述规划指令执行的时间,由用户指定一个日期时间,系统根据设定的一批执行机器的数量及每批执行的间隔时间,来为每台机具的执行指令设定具体的执行时间。所述一批执行机器的数量及每批执行的间隔时间,通过系统配置来设定。

优选的,所述步骤S43a中所述指令池是一个以所述客户端的编号为Key,指令列表为value的哈希表;这个哈希表缓存在内存里,通过高速缓存在不同实例间进行同步。

优选的,所述指令状态更新过程,包括以下步骤:

步骤a:所述指令状态更新线程侦听指令状态更新队列;

步骤b:每隔设定时间,所述指令状态更新线程取到指令状态更新队列所有待更新指令,进行一次数据库更新批处理,更新成功后,清除更新过的指令。

本发明的有益效果是:解决金融机具在线升级问题,无需人工升级,提高升级效率;解决在线升级所带来的大压力的升级入库问题;结构合理有利于扩展。

附图说明

图1为本发明的一种优选实施例中,金融设备软件的升级方法的流程图;

图2为本发明的一种优选实施例中,金融设备软件的升级方法的示意图;

图3为本发明的一种优选实施例中,步骤S4的流程图之一;

图4为本发明的一种优选实施例中,步骤S5的流程图之一;

图5为本发明的一种优选实施例中,步骤S4的流程图之二;

图6为本发明的一种优选实施例中,步骤S5的流程图之二;

图7为本发明的一种优选实施例中,基于内存指令管理系统控制指令状态迁移图。

具体实施方式

需要说明的是,在不冲突的情况下,下述技术方案,技术特征之间可以相互组合。

下面结合附图对本发明的具体实施方式作进一步的说明:

如图1-2所示,一种金融设备软件的升级方法,适用于不同类型的客户端,上述客户端包括第一客户端和第二客户端;上述方法包括如下步骤:

步骤S1、采用一指令规划器接收指令请求;

步骤S2、上述指令规划器解析接收到的上述指令请求,并持久化上述指令请求到一数据库的指令列表中;

步骤S3、上述指令规划器根据解析的上述指令请求的内容,为请求范围内的每个上述客户端生成一条指令,规划上述指令的执行时间,并持久化上述指令到上述数据库的指令表中,并标识上述指令的指令状态为创建;

步骤S4、采用一任务安排器定时读取指令请求表,根据对应于上述第一客户端的第一指令请求的编号从上述指令表中提取对应于上述第一客户端的第一指令并存储,以及根据对应上述第二客户端的第二指令请求的编号从上述指令表中提取对应于上述第二客户端的第二指令并存储;

步骤S5、对上述第一指令和上述第二指令分别进行下发处理操作以更新上述第一客户端和上述第二客户端;

步骤S6、上述指令规划器根据上述下发处理操作后更新上述指令状态为发送并放入指令更新队列,由指令更新线程自动异步更新上述指令状态;

步骤S7、上述客户端接收到上述指令后,发送指令状态更新请求,上述指令规划器更新上述指令状态为接收并放入上述指令状态更新队列,由上述指令状态更新线程自动异步更新上述指令状态;

步骤S8:上述客户端完成指令执行后,发送指令状态更新请求,上述指令规划器更新上述指令状态为完成并放入上述指令状态更新队列,由上述指令状态更新线程自动异步更新上述指令状态。

在本实施例中,第一客户端指设置在银行系统的金融机具,第二客户端值设置在民用系统(超市等)的金融机具,金融机具的具体类型包括:点钞机、清分机、ATM机、存取款一体机、VTM机、捆钞机等。指令在未下发前被持久化到指令列表中,保证指令不会丢失。

本发明较佳的实施例中,上述第一客户端包括一个启动节点端和多个关联于上述启动节点端的调动端,上述启动节点端设有节点服务器,上述调动端设有关联于上述节点服务器的调动服务器。

本发明较佳的实施例中,如图3所示,上述步骤S4包括:

步骤S41a、上述任务安排器定时读取上述指令请求表,获取未处理的上述指令请求的编号,定义未处理的上述指令请求的编号为上述第一指令请求的编号;

步骤S42a、上述指令规划器根据上述第一指令请求的编号从上述指令表中提取上述第一指令;

步骤S43a、上述指令规划器将上述第一指令放入指令池。

本发明较佳的实施例中,如图4所示,上述步骤S5包括:

步骤S51a、上述指令规划器向上述启动节点端下发启动命令;

步骤S52a、上述启动节点端接收上述启动命令后向每个关联于上述启动节点端的上述调动端发送调动命令;

步骤S53a、上述启动节点端和上述调动端分别向上述指令规划器发送上述指令请求来获取上述第一指令;

步骤S54a、上述指令规划器从上述指令表中提取相应的上述第一指令并下发给上述启动节点端和上述调动端。

在本实施例中。指令下发的范围没有限制,以第一客户端为例,指令下发是后台用户统一下发的,在所述第一客户端上设置web服务器,每个第一客户端都发布一个web服务,指令下发的启动落在一个启动节点端上,由启动节点端去调用与之关联的调动端的web服务,从而将所有的节点的指令下发都启动。每个第一客户端均从指令池中获取指令。

第一客户端和第二客户端的指令请求持久化和指令持久化是一样的;区别在于指令的池化,如果是第二客户端,只需要以key/value的形式保存到redis服务器即可,因为是第二客户端主动来获取指令;如果是第一客户端,则是统一下发指令,不是由第二客户端(如点钞机)来获取,所以池化成队列,以供第二客户端的服务器依次获取,统一下发;第一客户端和第二客户端的指令处理过程显示了上面的差异;第一客户端和第二客户端的指令状态的更新是一致的,都是将指令状态暂存于redis的队列,由指令状态更新线程更新指令表;

值得注意的是,总架构图中使用了两次redis,第二客户端的指令池是不需要redis持久化的,如果redis重启,则重新从数据库拿到指令,再次池化到redis中;第一客户端的指令状态更新队列则需要持久化,如果redis重启,也不能导致指令状态更新队列数据丢失。

本发明较佳的实施例中,如图5所示,上述步骤S4包括:

步骤S41b、上述任务安排器定时读取指令请求表,获取所有上述指令请求的编号,定义上述指令请求的编号为上述第二指令请求的编号;

步骤S42b、上述指令规划器根据上述第二指令请求的编号从上述指令表中提取上述第二指令;

步骤S43b、上述指令规划器将上述第二指令按照key/value的方式缓存至一Redis服务器。

本发明较佳的实施例中,如图6所示,上述步骤S5包括:

步骤S51b、上述第二客户端向上述指令规划器发送上述指令请求来获取上述第二指令;

步骤S52b、上述指令规划器从上述指令表中提取相应的上述第二指令并下发给上述第二客户端。

在本实施例中,指令下发的范围没有限制,第二客户端在更新时,指令下发是第二客户端的用户和向后台发出请求后由后台下发的,在所述第二客户端上设置web服务器,每个第二客户端都发布一个web服务,指令下发的启动落在一个启动节点上,由启动节点去调用与之关联的调动节点的web服务,从而将所有的节点的指令下发都启动。每个节点都从Redis服务器的指令队列中一次获取一个指令,将指令下发到点钞机等第二客户端。如果Redis服务器重启,则重新从数据库中拿到指令再次池化到Redis服务器中,指令状态更新队列进行持久化如果Redis服务器重启,不会导致指令状态更新队列数据丢失。本发明较佳的实施例中,上述指令规划器通过HTTP、消息或socket接口接收上述指令请求。

本发明较佳的实施例中,上述步骤S2中上述指令规划器把上述指令请求,根据系统设置的参数和逻辑,计算出指令发布的时间,并维护上述指令状态。

本发明较佳的实施例中,上述步骤3中上述规划指令执行的时间,由用户指定一个日期时间,系统根据设定的一批执行机器的数量及每批执行的间隔时间,来为每台机具的执行指令设定具体的执行时间。上述一批执行机器的数量及每批执行的间隔时间,通过系统配置来设定。

本发明较佳的实施例中,上述步骤S43a中上述指令池是一个以上述客户端的编号为Key,指令列表为value的哈希表;这个哈希表缓存在内存里,通过高速缓存在不同实例间进行同步。

本发明较佳的实施例中,如图7所示,上述指令状态更新过程,包括以下步骤:

步骤a:上述指令状态更新线程侦听指令状态更新队列;

步骤b:每隔设定时间,上述指令状态更新线程取到指令状态更新队列所有待更新指令,进行一次数据库更新批处理,更新成功后,清除更新过的指令。

本发明较佳的实施例中通过说明和附图,给出了具体实施方式的特定结构的典型实施例,基于本发明精神,还可作其他的转换。尽管上述发明提出了现有的较佳实施例,然而,这些内容并不作为局限。

对于本领域的技术人员而言,阅读上述说明后,各种变化和修正无疑将显而易见。因此,所附的权利要求书应看作是涵盖本发明的真实意图和范围的全部变化和修正。在权利要求书范围内任何和所有等价的范围与内容,都应认为仍属本发明的意图和范围内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1