CN115242781A - 一种文件合并存储方法和装置 - Google Patents

一种文件合并存储方法和装置 Download PDF

Info

Publication number
CN115242781A
CN115242781A CN202210912191.3A CN202210912191A CN115242781A CN 115242781 A CN115242781 A CN 115242781A CN 202210912191 A CN202210912191 A CN 202210912191A CN 115242781 A CN115242781 A CN 115242781A
Authority
CN
China
Prior art keywords
file
message
message body
target
message header
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.)
Pending
Application number
CN202210912191.3A
Other languages
English (en)
Inventor
林圻
余鹏
钟海
曹佳杰
陈华国
耿显祥
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangzhou Huiqiao Computer Technology Co ltd
Original Assignee
Guangzhou Huiqiao Computer Technology Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Guangzhou Huiqiao Computer Technology Co ltd filed Critical Guangzhou Huiqiao Computer Technology Co ltd
Priority to CN202210912191.3A priority Critical patent/CN115242781A/zh
Publication of CN115242781A publication Critical patent/CN115242781A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/06Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种文件合并存储方法和装置,应用于医疗信息平台,包括:当首次接收到响应业务请求返回的业务消息时,从网关实时获取对应的日志信息作为初始消息头文件,并缓存至文件缓存区;当接收到集成引擎或业务组件发送的消息响应文件时,将消息响应文件合并至初始消息头文件,生成目标消息头文件并标记消息头时间戳;当消息头时间戳大于或等于预设的缓存时长时,将其从文件缓存区转存至文件服务器;从业务消息中提取消息体文件并缓存至文件服务器;当消息体文件的缓存状态参数满足预设的合并条件时,对已缓存的消息体文件执行文件压缩操作,生成目标消息体文件。从而减少医疗信息小文件存储的随机读写次数,保持文件存储空间连续性。

Description

一种文件合并存储方法和装置
技术领域
本发明涉及文件存储技术领域,尤其涉及一种文件合并存储方法和装置。
背景技术
随着医疗信息化的不断发展,医疗业务也随之越来越复杂,医疗信息系统之间的交互越来越紧密,存在众多的业务系统都需要接入平台进行服务交互的情况,随之而来的,医疗信息系统之间交互所产生的交互数据日志的数量也高速增长。
而在现有的医疗信息平台中,不仅需要保障接入平台的业务系统正常运行,还要基于对医疗信息的测评要求,将交互服务产生的日志数据保存三个月及以上。其在服务交互过程中会产生大量的交互数据,这种交互数据会产生小文件,例如数据日志等数据。
但现有的存储方法在对大量的数据日志进行存储时,由于医疗信息的非结构化文本的结构影响,需要直接操作磁盘进行记录存储,而海量的小文件存储会产生大量的随机读写,破坏存储空间的连续性,造成业务系统卡顿,进而影响医疗信息平台的正常运行。
发明内容
本发明提供了一种文件合并存储方法和装置,解决了现有的医疗消息存储方案由于医疗信息的非结构化文本的结构影响,需要直接操作磁盘进行记录存储,而海量的小文件存储会产生大量的随机读写,破坏存储空间的连续性,造成业务系统卡顿,进而影响医疗信息平台的正常运行的技术问题。
本发明提供的一种文件合并存储方法,应用于医疗信息平台,所述医疗信息平台分别与网关、集成引擎和多个业务组件通信连接,所述医疗信息平台包括文件缓存区和文件服务器,所述方法包括:
当首次接收到响应业务请求返回的业务消息时,从所述网关实时获取对应的日志信息作为初始消息头文件,并缓存至所述文件缓存区;
当接收到所述集成引擎或所述业务组件发送的消息响应文件时,将所述消息响应文件合并至所述初始消息头文件,生成目标消息头文件并标记消息头时间戳;
当所述消息头时间戳大于或等于预设的缓存时长时,将所述目标消息头文件从所述文件缓存区转存至所述文件服务器;
从所述业务消息中提取消息体文件并缓存至所述文件服务器;
当所述消息体文件的缓存状态参数满足预设的合并条件时,对已缓存的所述消息体文件执行文件压缩操作,生成目标消息体文件。
可选地,所述医疗信息平台还包括消息头服务接口,所述初始消息头文件设有消息流水号;所述当接收到所述集成引擎或所述业务组件发送的消息响应文件时,将所述消息响应文件合并至所述初始消息头文件,生成目标消息头文件并标记消息头时间戳的步骤,包括:
当通过所述消息头服务接口接收到所述集成引擎或所述业务组件响应所述业务消息发送的消息响应文件时,获取所述消息响应文件的响应流水号;
按照所述响应流水号检索所述文件缓存区,确定与所述响应流水号相同的消息流水号作为目标流水号;
将所述消息响应文件合并至所述目标流水号对应的初始消息头文件,生成目标消息头文件;
对所述目标消息头文件标记当前时刻对应的消息头时间戳。
可选地,所述将所述消息响应文件合并至所述目标流水号对应的初始消息头文件,生成目标消息头文件的步骤,包括:
在所述目标流水号对应的初始消息头文件创建消息来源属性项;
将所述消息响应文件加载至所述消息来源属性项,生成目标消息头文件。
可选地,所述方法还包括:
实时检测所述消息头服务接口对应的信息接收速率;
当所述信息接收速率大于预设的限流阈值时,则将所述消息响应文件写入至预设的第一消息队列;
当所述信息接收速率小于或等于所述限流阈值时,则读取所述第一消息队列内的全部所述消息响应文件;
跳转执行所述将所述消息响应文件合并至所述初始消息头文件,生成目标消息头文件并标记消息头时间戳的步骤。
可选地,所述医疗信息平台还包括消息体服务接口;所述从所述业务消息中提取消息体文件并缓存至所述文件服务器的步骤,包括:
通过所述消息体服务接口从所述业务消息中提取消息体文件;
判断所述文件服务器对应的瞬时写入量是否达到预设的阻塞阈值;
若是,则将所述消息体文件写入至所述文件服务器对应的第二消息队列;
当所述瞬时写入量小于所述阻塞阈值时,将所述第二消息队列内的所述消息体文件写入至所述文件服务器;
若否,则将所述消息体文件缓存至所述文件服务器。
可选地,所述缓存状态参数包括缓存个数和缓存时间;所述当所述消息体文件的缓存状态参数满足预设的合并条件时,对已缓存的所述消息体文件执行文件压缩操作,生成目标消息体文件的步骤,包括:
当所述缓存个数达到预设的合并最小阈值,或所述缓存时间达到预设的缓存周期阈值时,创建临时文件夹;
读取已缓存的全部所述消息体文件作为待合并消息体文件;
将所述待合并消息体文件复制至所述临时文件夹;
对所述待合并消息体文件执行文件压缩操作,生成目标消息体文件并存储至预设的目标文件夹。
可选地,所述方法还包括:
若所述消息体文件的缓存个数达到合并最大阈值,则按照预设的最大合并文件数量读取已缓存的所述消息体文件作为新的待合并消息体文件;
跳转执行所述将所述待合并消息体文件复制至所述临时文件夹的步骤,直至所述文件服务器不存在已缓存的所述消息体文件。
可选地,所述消息体文件携带有消息体索引;所述方法还包括:
当得到所述待合并消息体文件时,获取所述待合并消息体文件对应的初始文件路径;
若所述文件压缩操作执行失败,则按照所述初始文件路径再次读取所述待合并消息体文件;
跳转执行所述对所述待合并消息体文件执行文件压缩操作,生成目标消息体文件并存储至预设的目标文件夹的步骤,直至再次读取次数达到读取阈值;
当将所述目标消息体文件存储至所述目标文件夹时,获取所述目标文件夹对应的目标文件路径;
将所述消息体索引更新为所述目标文件路径,并删除已压缩的全部所述消息体文件与所述临时文件夹。
可选地,所述方法还包括:
若检测到所述文件压缩操作对应的执行线程过载时,则按照预设的最大线程数量调用额外执行线程执行所述文件压缩操作;
若检测到存在空闲的所述执行线程,且所述执行线程的线程数量大于预设的最小线程数量时,则计算所述线程数量与所述最小线程数量的线程差值,停用数量与所述线程差值相等的所述执行线程。
本发明还提供了一种文件合并存储装置,应用于医疗信息平台,所述医疗信息平台分别与网关、集成引擎和多个业务组件通信连接,所述医疗信息平台包括文件缓存区和文件服务器,所述装置包括:
初始消息头文件缓存模块,用于当首次接收到响应业务请求返回的业务消息时,从所述网关实时获取对应的日志信息作为初始消息头文件,并缓存至所述文件缓存区;
消息头文件合并模块,用于当接收到所述集成引擎或所述业务组件发送的消息响应文件时,将所述消息响应文件合并至所述初始消息头文件,生成目标消息头文件并标记消息头时间戳;
消息头文件转存模块,用于当所述消息头时间戳大于或等于预设的缓存时长时,将所述目标消息头文件从所述文件缓存区转存至所述文件服务器;
消息体文件提取模块,用于从所述业务消息中提取消息体文件并缓存至所述文件服务器;
消息体文件合并模块,用于当所述消息体文件的缓存状态参数满足预设的合并条件时,对已缓存的所述消息体文件执行文件压缩操作,生成目标消息体文件。
从以上技术方案可以看出,本发明具有以下优点:
当医疗信息平台首次接收到响应业务请求返回的业务消息时,从网关实时获取对应的日志信息作为初始消息头文件,并缓存至文件缓存区;当接收到集成引擎或业务组件发送的消息响应文件时,将消息响应文件合并至初始消息头文件,生成目标消息头文件并标记消息头时间戳;当消息头时间戳大于或等于预设的缓存时长时,将目标消息头文件从文件缓存区转存至文件服务器;与此同时,可以从业务消息中提取消息体文件并缓存至文件服务器;当消息体文件的缓存状态参数满足预设的合并条件时,对已缓存的消息体文件执行文件压缩操作,生成目标消息体文件并缓存至文件服务器内消息体文件的缓存目录。从而减少医疗信息小文件存储的随机读写次数,在保持文件存储空间连续性的同时,更为有效地维持医疗信息平台的正常运行,防止平台卡顿。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其它的附图。
图1为本发明实施例一提供的一种文件合并存储方法的步骤流程图;
图2为本发明实施例二提供的一种文件合并存储方法的步骤流程图;
图3为本发明实施例三提供的一种文件合并存储装置的结构框图。
具体实施方式
在现有技术中,医疗业务系统通常需要保证各种业务的正常运行,同时需要将交互服务所产生的日志数据保存一定时间,而由于医疗业务系统之间通常通过非结构化文本文件进行交互,而文件大小平均为几百KB(千字节),以普通的三甲医院为例,目前每天产生近百万条消息日志和近20G以上的消息日志文件,此消息日志都需要进行存储,对写入的IO要求极高,直接写入磁盘会导致服务器性能下降,海量的小文件会破坏空间的连续性,会产生大量的随机读写,直接会造成业务系统卡顿。而关系型数据库和一般文件系统进行存储的也无法满足海量小文件存储的要求;2)消息存储后,需要根据业务关键字和相关消息体内容进行检索,此要求对文件的读取要求极高,直接磁盘存储、关系型数据库和一般文件系统无法满足此要求。
本发明实施例提供了一种文件合并存储方法和装置,用于解决现有的医疗消息存储方案由于医疗信息的非结构化文本的结构影响,需要直接操作磁盘进行记录存储,而海量的小文件存储会产生大量的随机读写,破坏存储空间的连续性,造成业务系统卡顿,进而影响医疗信息平台的正常运行的技术问题。
为使得本发明的发明目的、特征、优点能够更加的明显和易懂,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,下面所描述的实施例仅仅是本发明一部分实施例,而非全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本发明保护的范围。
请参阅图1,图1为本发明实施例一提供的一种文件合并存储方法的步骤流程图。
本发明提供的一种文件合并存储方法,应用于医疗信息平台,医疗信息平台分别与网关、集成引擎和多个业务组件通信连接,医疗信息平台包括文件缓存区和文件服务器,方法包括:
步骤101,当首次接收到响应业务请求返回的业务消息时,从网关实时获取对应的日志信息作为初始消息头文件,并缓存至文件缓存区;
业务请求指的是医疗业务系统接收用户输入所生成的业务信息。
业务消息指的是医疗业务系统响应另一医疗业务系统发送的业务请求所返回的非结构化文本文件,包括但不限于消息体。
日志信息指的是当业务消息经过网关时,通过网关记录业务消息经过网关的时间,请求IP以及消息流水号等信息,初始消息头文件用于记录消息体经过所有应用详细记录。
在本申请实施例中,当医疗业务系统接收到业务请求后,响应该业务请求将业务消息通过网关返回至医疗信息平台,通过医疗信息平台内的采集软件主动从网关获取对应的日志信息作为初始消息头文件,同时将初始消息头文件缓存至文件缓存区。
需要说明的是,采集软件可以为Logstash、Filebeat、Fluentd等,在将初始消息头文件缓存至文件缓存区的同时,还可以将日志信息对应的消息流水号作为索引一并缓存。
步骤102,当接收到集成引擎或业务组件发送的消息响应文件时,将消息响应文件合并至初始消息头文件,生成目标消息头文件并标记消息头时间戳;
集成引擎指的是连接多个医疗业务系统的信息引擎,业务组件指的是医疗业务系统或是执行医疗业务所需要的系统组件。
消息响应文件指的是集成引擎或业务组件响应业务消息所生成的传出参数。
在本申请实施例中,当医疗信息平台接收到集成引擎或业务组件发送的消息响应文件时,为实现对消息头的同步合并,可以经过限流算法将各个消息响应文件作为索引,在文件缓存区检索对应的初始消息头文件,将消息响应文件合并至初始消息头文件,生成目标消息头文件,同时标记当前时间作为目标消息头文件对应的消息头时间戳。
其中,在生成目标消息头文件的同时,可以删除文件缓存区内的消息响应文件以及初始消息头文件。
步骤103,当消息头时间戳大于或等于预设的缓存时长时,将目标消息头文件从文件缓存区转存至文件服务器;
与此同时,可以在医疗信息平台中配置文件缓存区的缓存时长,在标记目标消息头文件的消息头时间戳后,若是消息头时间戳大于或等于预设的缓存时长时,将目标消息头文件从文件缓存区转存至文件服务器。
需要说明的是,在将目标消息头文件从文件缓存区转存至文件服务器的同时,可以删除缓存在文件缓存区内的目标消息头文件。
步骤104,从业务消息中提取消息体文件并缓存至文件服务器;
消息体文件指的是业务系统之间的交互信息的载体文件。
在初始消息头文件创建的同时,可以从业务消息中提取对应的消息体文件,并以消息体文件的消息流水号作为索引,经过限流算法将消息体文件缓存到文件服务器。
步骤105,当消息体文件的缓存状态参数满足预设的合并条件时,对已缓存的消息体文件执行文件压缩操作,生成目标消息体文件。
在本申请实施例中,可以按照消息体文件的缓存时间或者缓存个数等缓存状态参数进行实时检测,若是消息体文件的缓存状态参数满足预设的合并条件时,则可以对已缓存的消息体文件执行文件压缩操作,生成目标消息体文件。
需要说明的是,在生成目标消息体文件的同时可以删除已压缩的消息体文件,从而减少医疗信息平台的资源消耗。
在本申请实施例中,医疗信息平台分别与网关、集成引擎和多个业务组件通信连接,当医疗信息平台首次接收到响应业务请求返回的业务消息时,从网关实时获取对应的日志信息作为初始消息头文件,并缓存至文件缓存区;当接收到集成引擎或业务组件发送的消息响应文件时,将消息响应文件合并至初始消息头文件,生成目标消息头文件并标记消息头时间戳;当消息头时间戳大于或等于预设的缓存时长时,将目标消息头文件从文件缓存区转存至文件服务器;与此同时,可以从业务消息中提取消息体文件并缓存至文件服务器;当消息体文件的缓存状态参数满足预设的合并条件时,对已缓存的消息体文件执行文件压缩操作,生成目标消息体文件并缓存至文件服务器内消息体文件的缓存目录。从而减少医疗信息小文件存储的随机读写次数,在保持文件存储空间连续性的同时,更为有效地维持医疗信息平台的正常运行,防止平台卡顿。
请参阅图2,图2为本发明实施例二提供的一种文件合并存储方法的步骤流程图。
本发明提供的一种文件合并存储方法,应用于医疗信息平台,医疗信息平台分别与网关、集成引擎和多个业务组件通信连接,医疗信息平台包括文件缓存区、文件服务器和消息头服务接口,方法包括:
步骤201,当首次接收到响应业务请求返回的业务消息时,从网关实时获取对应的日志信息作为初始消息头文件,并缓存至文件缓存区;
在本申请实施例中,步骤201的具体实施过程与步骤101类似,在此不再赘述。
需要说明的是,初始消息头文件设有消息流水号。
步骤202,当通过消息头服务接口接收到集成引擎或业务组件响应业务消息发送的消息响应文件时,获取消息响应文件的响应流水号;
消息头服务接口指的是一个自动化系统与另一个自动化系统或人之间的共享边界。在本实施例中,消息头服务接口用于被动接收集成引擎或业务组件所发送的消息响应文件。
在本申请实施例中,当集成引擎或业务组件接收到业务消息时,集成引擎通过消息路由把业务消息分发至各个配置好的业务组件接口,通过业务组件接口发送至各个业务组件,同时生成业务消息对应的传出参数,而当业务组件接收到业务消息后,同样生成业务消息对应的传出参数。
为避免消息响应的遗漏,医疗信息平台可以通过消息头服务接口接收集成引擎或业务组件响应业务消息发送的消息响应文件,即传出参数,同时为方便后续对消息响应文件的查找,可以获取该消息响应文件对应的响应流水号。
步骤203,按照响应流水号检索文件缓存区,确定与响应流水号相同的消息流水号作为目标流水号;
在获取到消息响应文件对应的响应流水号后,为查找到对应的初始消息头文件,可以采用该响应流水号作为索引,对文件缓冲区进行检索,以查找与该响应流水号相同的消息流水号,将该消息流水号确定为目标流水号。
步骤204,将消息响应文件合并至目标流水号对应的初始消息头文件,生成目标消息头文件;
可选地,步骤204可以包括以下子步骤:
在目标流水号对应的初始消息头文件创建消息来源属性项;
将消息响应文件加载至消息来源属性项,生成目标消息头文件。
在本申请的一个示例中,在查找到目标流水号后,将其对应的初始消息头文件作为合并主体,创建消息来源属性项,进一步将各个消息响应文件加载到该消息来源属性项,从而完成对消息头文件以及消息响应的合并,生成目标消息头文件。
需要说明的是,在生成目标消息头文件后,为进一步减少资源消耗,可以对应删除缓存在文件缓存区内的消息响应文件以及初始消息头文件。同时在后续需要进行消息头文件或消息响应的查找时,由于初始消息头文件并未出现变化,而是在其基础上增加新的消息来源属性项,因此其消息流水号也未改变,可以直接通过该目标消息头文件对应的消息流水号进行查找,若是需要查找消息响应文件,则可以读取该目标消息头文件内的消息来源属性项,以获取到对应的消息响应文件。
步骤205,对目标消息头文件标记当前时刻对应的消息头时间戳。
进一步地,方法还包括以下步骤S11-S14:
S11、实时检测消息头服务接口对应的信息接收速率;
S12、当信息接收速率大于预设的限流阈值时,则将消息响应文件写入至预设的第一消息队列;
S13、当信息接收速率小于或等于限流阈值时,则读取第一消息队列内的全部消息响应文件;
S14、跳转执行将消息响应文件合并至初始消息头文件,生成目标消息头文件并标记消息头时间戳的步骤。
在本申请的另一个示例中,由于消息响应文件的传输量较大,容易出现多个业务组件同时发送消息响应文件的情况。为防止医疗信息平台奔溃,可以实时检测消息头服务接口接收该消息响应文件对应的信息接收速率。
若是该信息接收速率大于预设的限流阈值,则表明当前时刻消息服务接口的信息接收速率过高,医疗信息平台存在无法及时合并的风险,此时可以将消息响应文件写入到预设的第一消息队列,通过消息队列的方式对消息响应文件进行限流;当信息接收速率小于或等于限流阈值时,表明此时医疗信息平台已经可以满足当前时刻的文件合并需求,按照写入第一消息队列的顺序依次读取消息响应文件,跳转执行将消息响应文件合并到初始消息头文件的步骤,以生成目标消息头文件,并标记当前时刻的消息头时间戳。
需要说明的是,若是存在初始消息头文件过多的情况,同样可以通过消息队列的方式对初始消息头文件进行缓存,当限流解除时再次合并,以保证医疗信息平台的运行稳定。
步骤206,当消息头时间戳大于或等于预设的缓存时长时,将目标消息头文件从文件缓存区转存至文件服务器;
在本申请实施例中,步骤206的具体实施过程与步骤103类似,在此不再赘述。
步骤207,从业务消息中提取消息体文件并缓存至文件服务器;
可选地,医疗信息平台还包括消息体服务接口,步骤207可以包括以下子步骤:
通过消息体服务接口从业务消息中提取消息体文件;
判断文件服务器对应的瞬时写入量是否达到预设的阻塞阈值;
若是,则将消息体文件写入至文件服务器对应的第二消息队列;
当瞬时写入量小于阻塞阈值时,将第二消息队列内的消息体文件写入至文件服务器;
若否,则将消息体文件缓存至文件服务器。
在本申请的一个示例中,医疗信息平台除消息头服务接口外还可以包括消息体服务接口,用于接收业务消息中的消息体文件。
在医疗信息平台接收到业务消息的同时,通过消息体服务接口从业务消息中提取消息体文件,同时检测当前时刻文件服务器对应的瞬时写入量是否达到预设的阻塞阈值。其中阻塞阈值指的是文件服务器在同一时刻能够同时写入的最大数量。
若是瞬时写入量达到预设的阻塞阈值,表明此时消息体文件需要进行阻塞处理,可以通过将消息体文件写入到文件服务器所对应的第二消息队列,通过第二消息队列先对消息体文件进行缓存,直至瞬时写入量小于阻塞阈值,阻塞处理接触,此时可以将第二消息队列内的消息体文件按照第二消息队列的写入顺序写入到文件服务器。
若是瞬时写入量未达到阻塞阈值,则可以直接将消息体文件写入到文件服务器,等待后续对消息体文件的合并。
需要说明的是,在将消息体文件写入到文件服务器的同时,可以消息体文件对应的消息流水号作为索引标识,以方便后续对消息体文件的检索。
步骤208,当消息体文件的缓存状态参数满足预设的合并条件时,对已缓存的消息体文件执行文件压缩操作,生成目标消息体文件。
可选地,缓存状态参数包括缓存个数和缓存时间,步骤208可以包括以下子步骤:
当缓存个数达到预设的合并最小阈值,或缓存时间达到预设的缓存周期阈值时,创建临时文件夹;
读取已缓存的全部消息体文件作为待合并消息体文件;
将待合并消息体文件复制至临时文件夹;
对待合并消息体文件执行文件压缩操作,生成目标消息体文件并存储至预设的目标文件夹。
缓存个数指的是消息体文件写入到文件服务器内缓存目录的文件个数,缓存时间指的是消息体文件写入到文件服务器内的时间。
在本申请实施例中,缓存状态参数可以包括缓存个数和缓存时间,当缓存个数达到预设的合并最小阈值,或是缓存时间达到了预设的缓存周期阈值时,触发消息体文件的合并,此时在消息体文件在文件服务器内的缓存目录创建临时文件夹。按照文件缓存的顺序依次读取在文件服务器缓存目录中已缓存的全部消息体文件,将其作为待合并消息体文件,将待合并消息体文件复制至临时文件夹,在临时文件夹内对待合并消息体文件执行文件压缩操作,从而生成目标消息体文件并存储到预设的目标文件夹。
其中,该目标文件夹处于缓存目录,与消息体文件处于同一目录层级。
进一步地,步骤208还包括以下子步骤:
若消息体文件的缓存个数达到合并最大阈值,则按照预设的最大合并文件数量读取已缓存的消息体文件作为新的待合并消息体文件;
跳转执行将待合并消息体文件复制至临时文件夹的步骤,直至文件服务器不存在已缓存的消息体文件。
由于消息体文件的发送频率可能较高,存在消息体文件在某一瞬间接收过多的情况。为防止医疗信息平台对消息体文件的单次合并数量过多导致压缩时间答复增加,可以预设最大合并文件数量,若是判定消息体文件的缓存个数达到合并最大阈值,则可以按照预设的最大合并文件数量读取已缓存的消息体文件作为新的待合并消息体文件,再次执行将待合并消息体文件复制至临时文件夹的步骤,直至文件服务器所缓存的消息体文件清空。
在本申请的一个示例中,消息体文件携带有消息体索引,步骤208还包括以下步骤S21-S25:
S21、当得到待合并消息体文件时,获取待合并消息体文件对应的初始文件路径;
S22、若文件压缩操作执行失败,则按照初始文件路径再次读取待合并消息体文件;
S23、跳转执行对待合并消息体文件执行文件压缩操作,生成目标消息体文件并存储至预设的目标文件夹的步骤,直至再次读取次数达到读取阈值;
S24、当将目标消息体文件存储至目标文件夹时,获取目标文件夹对应的目标文件路径;
S25、将消息体索引更新为目标文件路径,并删除已压缩的全部消息体文件与临时文件夹。
在本实施例中,为方便后续消息体文件合并失败后的回滚操作,可以在选取得到待合并消息体文件的同时,记录待合并消息体文件对应的初始文件路径,此时若是文件压缩操作执行失败,则按照初始文件路径再次读取待合并消息体文件,对待合并消息文件再次执行文件压缩操作,直至再次读取次数达到了读取阈值。
在目标消息体文件被存储到目标文件夹后,可以进一步获取目标文件夹所对应的目标文件路径,将各个消息体文件对应的消息体索引更新为目标文件路径,同时删除全部已压缩的消息体文件和临时文件夹。
需要说明的是,在目标消息体文件存储到目标文件夹后,还可以进一步实时检测目标消息体文件对应的文件热度,若是文件热度大于某一阈值,表明此时目标消息体文件仍然经常被使用,此时可以将其缓存在目标文件夹中;若是文件热度小于或等于阈值,则表明此时目标消息体文件的使用频率较低,此时可以将其写入到医疗信息平台内的硬盘。
其中,文件热度指的是目标消息体文件的检索次数或是缓存日期,阈值指的是缓存最大日期或是检索次数最大值,例如3个月或是300次。
在本申请的另一个示例中,步骤208还可以包括以下步骤S31-S32:
S31、若检测到文件压缩操作对应的执行线程过载时,则按照预设的最大线程数量调用额外执行线程执行文件压缩操作;
S32、若检测到存在空闲的执行线程,且执行线程的线程数量大于预设的最小线程数量时,则计算线程数量与最小线程数量的线程差值,停用数量与线程差值相等的执行线程。
在本申请实施例中,由于消息体文件的体积较大,若是同时执行多个文件压缩操作可能导致医疗信息平台过载,为防止线程过载,可以通过医疗信息平台实时检测文件压缩操作对应的执行线程的使用情况,若是执行线程过载,则按照预设的最大线程数量调用额外执行线程,以满足医疗信息平台的文件合并峰值需求。
若是医疗信息平台检测到存在空闲执行线程,且执行线程的线程数量大于预设的最小线程数量,此时进一步计算线程数量和最小线程数量之间的线程差值,停用数量与线程差值相等的空闲的执行线程,节省平台运行资源。
可选地,消息数据在通过服务接口存储的过程中,为了防止数据的丢失和应对流量达到系统的瓶颈时,设计了一采用限流算法。当客户端以某一稳定的速率进行写入消息数据时,系统时稳定的且大多数的时候时保持稳定。但是有时需要应对流量峰值,这个时候超过规定的流量就会被限制。被限制的流量如果直接丢弃,那么可能重要的文件就被丢弃,这样显然不符合定位的高可用存储系统要求。于是在限流的逻辑中加入了以下处理流程:当流量达到系统瓶颈时,将被限流的流量写入队列,等到系统负载降低的时候,再从队列中读取这部分流量数据。而取出后的流量数据按照接口逻辑依次执行,在队列中,数据做到先进先出的原则,这样既保证系统的稳定性、顺序性,又解决因限流带来的数据丢失问题。
在本申请实施例中,医疗信息平台分别与网关、集成引擎和多个业务组件通信连接,当医疗信息平台首次接收到响应业务请求返回的业务消息时,从网关实时获取对应的日志信息作为初始消息头文件,并缓存至文件缓存区;当接收到集成引擎或业务组件发送的消息响应文件时,将消息响应文件合并至初始消息头文件,生成目标消息头文件并标记消息头时间戳;当消息头时间戳大于或等于预设的缓存时长时,将目标消息头文件从文件缓存区转存至文件服务器;与此同时,可以从业务消息中提取消息体文件并缓存至文件服务器;当消息体文件的缓存状态参数满足预设的合并条件时,对已缓存的消息体文件执行文件压缩操作,生成目标消息体文件并缓存至文件服务器内消息体文件的缓存目录。从而减少医疗信息小文件存储的随机读写次数,在保持文件存储空间连续性的同时,更为有效地维持医疗信息平台的正常运行,防止平台卡顿。
请参阅图3,图3为本发明实施例三提供的一种文件合并存储装置的结构框图。
本发明提供了一种文件合并存储装置,应用于医疗信息平台,医疗信息平台分别与网关、集成引擎和多个业务组件通信连接,医疗信息平台包括文件缓存区和文件服务器,装置包括:
初始消息头文件缓存模块301,用于当首次接收到响应业务请求返回的业务消息时,从网关实时获取对应的日志信息作为初始消息头文件,并缓存至文件缓存区;
消息头文件合并模块302,用于当接收到集成引擎或业务组件发送的消息响应文件时,将消息响应文件合并至初始消息头文件,生成目标消息头文件并标记消息头时间戳;
消息头文件转存模块303,用于当消息头时间戳大于或等于预设的缓存时长时,将目标消息头文件从文件缓存区转存至文件服务器;
消息体文件提取模块304,用于从业务消息中提取消息体文件并缓存至文件服务器;
消息体文件合并模块305,用于当消息体文件的缓存状态参数满足预设的合并条件时,对已缓存的消息体文件执行文件压缩操作,生成目标消息体文件。
可选地,医疗信息平台还包括消息头服务接口,初始消息头文件设有消息流水号;消息头文件合并模块302,包括:
响应流水号获取子模块,用于当通过消息头服务接口接收到集成引擎或业务组件响应业务消息发送的消息响应文件时,获取消息响应文件的响应流水号;
流水号检索子模块,用于按照响应流水号检索文件缓存区,确定与响应流水号相同的消息流水号作为目标流水号;
头文件合并子模块,用于将消息响应文件合并至目标流水号对应的初始消息头文件,生成目标消息头文件;
时间戳标记子模块,用于对目标消息头文件标记当前时刻对应的消息头时间戳。
可选地,头文件合并子模块具体用于:
在目标流水号对应的初始消息头文件创建消息来源属性项;
将消息响应文件加载至消息来源属性项,生成目标消息头文件。
可选地,装置还包括:
信息接收速率检测模块,用于实时检测消息头服务接口对应的信息接收速率;
第一消息队列写入模块,用于当信息接收速率大于预设的限流阈值时,则将消息响应文件写入至预设的第一消息队列;
消息响应读取模块,用于当信息接收速率小于或等于限流阈值时,则读取第一消息队列内的全部消息响应文件;
第一跳转模块,用于跳转执行将消息响应文件合并至初始消息头文件,生成目标消息头文件并标记消息头时间戳的步骤。
可选地,医疗信息平台还包括消息体服务接口;消息体文件提取模块304包括:
提文件提取子模块,用于通过消息体服务接口从业务消息中提取消息体文件;
瞬时写入量判断子模块,用于判断文件服务器对应的瞬时写入量是否达到预设的阻塞阈值;
第二消息队列写入子模块,用于若是,则将消息体文件写入至文件服务器对应的第二消息队列;
第一体文件缓存子模块,用于当瞬时写入量小于阻塞阈值时,将第二消息队列内的消息体文件写入至文件服务器;
第二体文件缓存子模块,用于若否,则将消息体文件缓存至文件服务器。
可选地,缓存状态参数包括缓存个数和缓存时间;消息体文件合并模块305包括:
临时文件夹创建子模块,用于当缓存个数达到预设的合并最小阈值,或缓存时间达到预设的缓存周期阈值时,创建临时文件夹;
待合并消息体文件确定子模块,用于读取已缓存的全部消息体文件作为待合并消息体文件;
体文件复制子模块,用于将待合并消息体文件复制至临时文件夹;
体文件压缩子模块,用于对待合并消息体文件执行文件压缩操作,生成目标消息体文件并存储至预设的目标文件夹。
可选地,消息体文件合并模块305还包括:
待合并消息体文件更新子模块,用于若消息体文件的缓存个数达到合并最大阈值,则按照预设的最大合并文件数量读取已缓存的消息体文件作为新的待合并消息体文件;
第二跳转子模块,用于跳转执行将待合并消息体文件复制至临时文件夹的步骤,直至文件服务器不存在已缓存的消息体文件。
可选地,消息体文件携带有消息体索引;消息体文件合并模块305还包括:
初始文件路径获取子模块,用于当得到待合并消息体文件时,获取待合并消息体文件对应的初始文件路径;
体文件二次读取子模块,用于若文件压缩操作执行失败,则按照初始文件路径再次读取待合并消息体文件;
第三跳转子模块,用于跳转执行对待合并消息体文件执行文件压缩操作,生成目标消息体文件并存储至预设的目标文件夹的步骤,直至再次读取次数达到读取阈值;
目标文件路径获取子模块,用于当将目标消息体文件存储至目标文件夹时,获取目标文件夹对应的目标文件路径;
索引更新子模块,用于将消息体索引更新为目标文件路径,并删除已压缩的全部消息体文件与临时文件夹。
可选地,消息体文件合并模块305还包括:
线程调用子模块,用于若检测到文件压缩操作对应的执行线程过载时,则按照预设的最大线程数量调用额外执行线程执行文件压缩操作;
线程停用子模块,用于若检测到存在空闲的执行线程,且执行线程的线程数量大于预设的最小线程数量时,则计算线程数量与最小线程数量的线程差值,停用数量与线程差值相等的执行线程。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的装置、模块和子模块的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
以上所述,以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种文件合并存储方法,其特征在于,应用于医疗信息平台,所述医疗信息平台分别与网关、集成引擎和多个业务组件通信连接,所述医疗信息平台包括文件缓存区和文件服务器,所述方法包括:
当首次接收到响应业务请求返回的业务消息时,从所述网关实时获取对应的日志信息作为初始消息头文件,并缓存至所述文件缓存区;
当接收到所述集成引擎或所述业务组件发送的消息响应文件时,将所述消息响应文件合并至所述初始消息头文件,生成目标消息头文件并标记消息头时间戳;
当所述消息头时间戳大于或等于预设的缓存时长时,将所述目标消息头文件从所述文件缓存区转存至所述文件服务器;
从所述业务消息中提取消息体文件并缓存至所述文件服务器;
当所述消息体文件的缓存状态参数满足预设的合并条件时,对已缓存的所述消息体文件执行文件压缩操作,生成目标消息体文件。
2.根据权利要求1所述的方法,其特征在于,所述医疗信息平台还包括消息头服务接口,所述初始消息头文件设有消息流水号;所述当接收到所述集成引擎或所述业务组件发送的消息响应文件时,将所述消息响应文件合并至所述初始消息头文件,生成目标消息头文件并标记消息头时间戳的步骤,包括:
当通过所述消息头服务接口接收到所述集成引擎或所述业务组件响应所述业务消息发送的消息响应文件时,获取所述消息响应文件的响应流水号;
按照所述响应流水号检索所述文件缓存区,确定与所述响应流水号相同的消息流水号作为目标流水号;
将所述消息响应文件合并至所述目标流水号对应的初始消息头文件,生成目标消息头文件;
对所述目标消息头文件标记当前时刻对应的消息头时间戳。
3.根据权利要求2所述的方法,其特征在于,所述将所述消息响应文件合并至所述目标流水号对应的初始消息头文件,生成目标消息头文件的步骤,包括:
在所述目标流水号对应的初始消息头文件创建消息来源属性项;
将所述消息响应文件加载至所述消息来源属性项,生成目标消息头文件。
4.根据权利要求2或3所述的方法,其特征在于,所述方法还包括:
实时检测所述消息头服务接口对应的信息接收速率;
当所述信息接收速率大于预设的限流阈值时,则将所述消息响应文件写入至预设的第一消息队列;
当所述信息接收速率小于或等于所述限流阈值时,则读取所述第一消息队列内的全部所述消息响应文件;
跳转执行所述将所述消息响应文件合并至所述初始消息头文件,生成目标消息头文件并标记消息头时间戳的步骤。
5.根据权利要求1所述的方法,其特征在于,所述医疗信息平台还包括消息体服务接口;所述从所述业务消息中提取消息体文件并缓存至所述文件服务器的步骤,包括:
通过所述消息体服务接口从所述业务消息中提取消息体文件;
判断所述文件服务器对应的瞬时写入量是否达到预设的阻塞阈值;
若是,则将所述消息体文件写入至所述文件服务器对应的第二消息队列;
当所述瞬时写入量小于所述阻塞阈值时,将所述第二消息队列内的所述消息体文件写入至所述文件服务器;
若否,则将所述消息体文件缓存至所述文件服务器。
6.根据权利要求1所述的方法,其特征在于,所述缓存状态参数包括缓存个数和缓存时间;所述当所述消息体文件的缓存状态参数满足预设的合并条件时,对已缓存的所述消息体文件执行文件压缩操作,生成目标消息体文件的步骤,包括:
当所述缓存个数达到预设的合并最小阈值,或所述缓存时间达到预设的缓存周期阈值时,创建临时文件夹;
读取已缓存的全部所述消息体文件作为待合并消息体文件;
将所述待合并消息体文件复制至所述临时文件夹;
对所述待合并消息体文件执行文件压缩操作,生成目标消息体文件并存储至预设的目标文件夹。
7.根据权利要求6所述的方法,其特征在于,所述方法还包括:
若所述消息体文件的缓存个数达到合并最大阈值,则按照预设的最大合并文件数量读取已缓存的所述消息体文件作为新的待合并消息体文件;
跳转执行所述将所述待合并消息体文件复制至所述临时文件夹的步骤,直至所述文件服务器不存在已缓存的所述消息体文件。
8.根据权利要求6或7所述的方法,其特征在于,所述消息体文件携带有消息体索引;所述方法还包括:
当得到所述待合并消息体文件时,获取所述待合并消息体文件对应的初始文件路径;
若所述文件压缩操作执行失败,则按照所述初始文件路径再次读取所述待合并消息体文件;
跳转执行所述对所述待合并消息体文件执行文件压缩操作,生成目标消息体文件并存储至预设的目标文件夹的步骤,直至再次读取次数达到读取阈值;
当将所述目标消息体文件存储至所述目标文件夹时,获取所述目标文件夹对应的目标文件路径;
将所述消息体索引更新为所述目标文件路径,并删除已压缩的全部所述消息体文件与所述临时文件夹。
9.根据权利要求6或7所述的方法,其特征在于,所述方法还包括:
若检测到所述文件压缩操作对应的执行线程过载时,则按照预设的最大线程数量调用额外执行线程执行所述文件压缩操作;
若检测到存在空闲的所述执行线程,且所述执行线程的线程数量大于预设的最小线程数量时,则计算所述线程数量与所述最小线程数量的线程差值,停用数量与所述线程差值相等的所述执行线程。
10.一种文件合并存储装置,其特征在于,应用于医疗信息平台,所述医疗信息平台分别与网关、集成引擎和多个业务组件通信连接,所述医疗信息平台包括文件缓存区和文件服务器,所述装置包括:
初始消息头文件缓存模块,用于当首次接收到响应业务请求返回的业务消息时,从所述网关实时获取对应的日志信息作为初始消息头文件,并缓存至所述文件缓存区;
消息头文件合并模块,用于当接收到所述集成引擎或所述业务组件发送的消息响应文件时,将所述消息响应文件合并至所述初始消息头文件,生成目标消息头文件并标记消息头时间戳;
消息头文件转存模块,用于当所述消息头时间戳大于或等于预设的缓存时长时,将所述目标消息头文件从所述文件缓存区转存至所述文件服务器;
消息体文件提取模块,用于从所述业务消息中提取消息体文件并缓存至所述文件服务器;
消息体文件合并模块,用于当所述消息体文件的缓存状态参数满足预设的合并条件时,对已缓存的所述消息体文件执行文件压缩操作,生成目标消息体文件。
CN202210912191.3A 2022-07-29 2022-07-29 一种文件合并存储方法和装置 Pending CN115242781A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210912191.3A CN115242781A (zh) 2022-07-29 2022-07-29 一种文件合并存储方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210912191.3A CN115242781A (zh) 2022-07-29 2022-07-29 一种文件合并存储方法和装置

Publications (1)

Publication Number Publication Date
CN115242781A true CN115242781A (zh) 2022-10-25

Family

ID=83677049

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210912191.3A Pending CN115242781A (zh) 2022-07-29 2022-07-29 一种文件合并存储方法和装置

Country Status (1)

Country Link
CN (1) CN115242781A (zh)

Similar Documents

Publication Publication Date Title
CN109034993B (zh) 对账方法、设备、系统及计算机可读存储介质
EP3806424A1 (en) File system data access method and file system
TWI430176B (zh) 管理持久的方法、裝置及電腦程式
EP3076307A1 (en) Method and device for responding to a request, and distributed file system
CN104111804A (zh) 一种分布式文件系统
US9792231B1 (en) Computer system for managing I/O metric information by identifying one or more outliers and comparing set of aggregated I/O metrics
CN110347651A (zh) 基于云存储的数据同步方法、装置、设备及存储介质
KR20210121315A (ko) 데이터베이스 동기화
CN113377868A (zh) 一种基于分布式kv数据库的离线存储系统
CN113806300B (zh) 数据存储方法、系统、装置、设备及存储介质
CN114490527A (zh) 元数据检索方法、系统、终端及存储介质
CN107181773A (zh) 分布式存储系统的数据存储及数据管理方法、设备
CN109460345A (zh) 实时数据的计算方法及系统
US9893972B1 (en) Managing I/O requests
CN108647280A (zh) 一种存储通讯信息的方法和装置
US9348847B2 (en) Data access control apparatus and data access control method
CN110413689B (zh) 一种内存数据库的多节点数据同步方法与装置
CN115242781A (zh) 一种文件合并存储方法和装置
CN116048846A (zh) 数据传输方法、装置、设备和存储介质
US20160085638A1 (en) Computer system and method of identifying a failure
CN109766462B (zh) 输电线路监控系统中的图像文件读取方法、装置及系统
CN115421856A (zh) 一种数据恢复方法及装置
CN115905115A (zh) 文件存储方法、读取方法及装置、电子设备与存储介质
CN114063931A (zh) 一种基于大数据的数据存储方法
CN109254880A (zh) 一种处理数据库宕机的方法及装置

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