CN110471991A - 海量医疗数据的状态机工作流引擎及分布式存储方法 - Google Patents

Abstract

本发明提出了一种海量医疗数据的状态机工作流引擎及分布式存储方法，该方法包括：S1，获取海量医疗数据；S2，业务系统判断是否接收到医疗数据流程化管理的业务命令；S3，通过异步推送MQ消息给医疗数据分发器系统异步消费JSON数据，同时医疗数据分发器系统根据业务需求调用Git相应命令让Git执行分布式存储和状态机工作流操作。本发明打造强大的分布式存储+状态机工作流，对中小型互联网公司来说开发简单，便于维护，最重要的是能保证数据的安全性，数据的完整性、一致性、容错性、鲁棒性、可靠性、可扩展性等，同时还具备异地备灾，各地区进行备份恢复等。

Description

海量医疗数据的状态机工作流引擎及分布式存储方法

技术领域

本发明涉及一种大数据技术领域，特别是涉及一种海量医疗数据的状态机工作流引擎及分布式存储方法。

背景技术

现在很多生态，譬如医疗生态存在这样一个棘手的问题，就是如何像OA一样实现无纸化，又能保证数据安全，可信性，完整性，一致性的系统要求，那么我们究竟需要做一种什么样的系统设计才能满足需求呢？尤其对整个系统运行过程中一些特别需要保证真实性，最终状态不可逆，能防止篡改，又要保证系统运行过程能保留历史记录并保证数据不丢失，又随时可查找各个状态的历史记录，也就是可追溯性呢？要解决这个问题，我们从现有的工作流引擎开始讨论：现有的工作流引擎显得笨重，做成分布式应用部署需要改造(例如Activiti：分布式全局唯一ID分发解决主键冲突，以及获取lastId多台服务器lastId字段数据不同步)，现在市面上开源的工作流引擎主要有：Workflow、Activiti、jBPM、Flowable等，而针对一些复杂的应用场景，单纯的工作流引擎是无法满足需求的，还必须要结合状态机来实现流转到达任意节点，也就是说可回退后面以执行的任意节点，也可以跳达前面没执行的任意节点，难点是这个设计方案本身就不那么好实现，当然也已有一些专利技术实现了这个设计方案，只是很复杂。

发明内容

本发明旨在至少解决现有技术中存在的技术问题，特别创新地提出了一种海量医疗数据的状态机工作流引擎及分布式存储方法。

为了实现本发明的上述目的，本发明提供了一种海量医疗数据的状态机工作流引擎及分布式存储方法，包括：

S1，获取海量医疗数据；

S2，业务系统判断是否接收到医疗数据流程化管理的业务命令：

若业务系统接收到医疗数据流程化管理的业务命令，则执行步骤S2；

若业务系统未接收到医疗数据流程化管理的业务命令，则继续等待；

S3，通过异步推送MQ消息给医疗数据分发器系统异步消费JSON数据，同时医疗数据分发器系统根据业务需求调用Git相应命令让Git执行分布式存储和状态机工作流操作；

S4，Git返回数据给医疗数据分发器系统后，医疗数据分发器系统再异步推送MQ消息让业务系统来异步消费JSON数据；

S5，业务系统实时将医疗流程化管理的业务数据经由上链系统网关，统一上传到区块链云平台进行存储。

在本发明的一种优选实施方式中，还包括外部系统既可直接实时调用业务系统的海量医疗数据，也可以从区块链云平台上获取海量医疗数据。

在本发明的一种优选实施方式中，在步骤S1中包括：

业务系统向其它服务器的系统上创建一个文件夹A，再在文件夹A中创建一个文件a.json，向文件a.json里写入格式为json的流程节点数据；

利用GitLab客户端创建一个用户，该用户包括用户设置的用户名和密码，登录成功后，该用户创建或选择一个分组G，再在分组G内创建一个项目仓库R。

在本发明的一种优选实施方式中，若检测到删除已经合并到master的所有分支，则业务系统将已经合并到master的所有分支删除。

在本发明的一种优选实施方式中，若检测到基于master的分支末梢创建新分支并检出c分支，规定一个流程为一个分支，则将当前分支c最近一次提交创建标签。

在本发明的一种优选实施方式中，往文件a.json里修改下一个状态数据，并追加第二个流程节点相关数据的方法为：

在c分支上提交文件a.json所有发生的修改，然后推送到远程版本仓库；

如果流程结束，则将c分支合并到master分支，压缩合并后直接提交；

如果流程未结束，则将当前分支c最近一次提交创建标签。

在本发明的一种优选实施方式中，读取文件夹A下文件a.json获取数据列表的方法为：

首先切换到c分支，然后检出标签，再获取更新。

在本发明的一种优选实施方式中，首先切换到c分支，再获取更新。

在本发明的一种优选实施方式中，查看自己或所有的流程状态和数据的方法：

利用事先在GitLab客户端中注册的账号的权限，然后调用Git相应的命令进行查看。

综上所述，由于采用了上述技术方案，本发明打造强大的分布式存储+状态机工作流，对中小型互联网公司来说开发简单，便于维护，最重要的是能保证数据的安全性，数据的完整性、一致性、容错性、鲁棒性、可靠性、可扩展性等，同时还具备异地备灾，各地区进行备份恢复等。

本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1是本发明流程示意框图。

图2是本发明示意框图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。

本发明提供了一种海量医疗数据的状态机工作流引擎及分布式存储方法，如图1所示，包括：

S1，获取海量医疗数据；

S2，业务系统判断是否接收到医疗数据流程化管理的业务命令：

若业务系统接收到医疗数据流程化管理的业务命令，则执行步骤S2；在本实施方式中，流程化管理的业务为打印纸质医疗凭证，打印电子版医疗凭证等。

若业务系统未接收到医疗数据流程化管理的业务命令，则继续等待或者调用关系型数据库和NOSQL；

S3，通过异步推送MQ消息给医疗数据分发器系统异步消费JSON数据，同时医疗数据分发器系统根据业务需求调用Git相应命令让Git执行分布式存储和状态机工作流操作；

S4，Git返回数据给医疗数据分发器系统后，医疗数据分发器系统再异步推送MQ消息让业务系统来异步消费JSON数据；

S5，业务系统实时将医疗流程化管理的业务数据经由上链系统网关，统一上传到区块链云平台进行存储。在本实施方式中，还包括将业务数据进行脱敏处理，脱敏处理包括以下步骤：S41，对业务数据进行同类数据聚集，获得预脱敏数据信息；

S42，从预脱敏数据信息中选择N个字符作为脱敏段，所述N为正整数，且N为小于或者等于预脱敏数据信息所包含的字符数；

S43，利用哈希算法对脱敏段进行运算，获得脱敏数据信息；

S44，判断获得的脱敏数据信息是否与数据库中记录的脱敏数据信息相同：

若获得的脱敏数据信息与数据库中记录的脱敏数据信息相同，则将获得的脱敏数据信息进行哈希算法，获得新的脱敏数据信息；令新的脱敏数据信息为脱敏数据信息，返回步骤S44；

若获得的脱敏数据信息与数据库中记录的脱敏数据信息不相同，则数据库记录获得的脱敏数据与加密段的对应关系。

在本发明的一种优选实施方式中，在步骤S1中还包括：

判断存储器中存储第一节点的剩余存储空间大小是否大于或者等于预设第一剩余存储空间：

若存储器中存储第一节点的剩余存储空间大小小于预设第一剩余存储空间，预设第一剩余存储空间为本次待存储数据空间的大小，则继续在存储第一节点上存储数据；

若存储器中存储第一节点的剩余存储空间大小大于或者等于预设第一剩余存储空间，则获取其它存储节点的信息状况，该信息状况包括剩余存储空间状态；所述剩余存储空间状态包括剩余存储空间和存储空间的历史使用情况；

通过所述信息状态确定存储第二节点作为用于对所述存储第一节点进行扩容的应急存储节点，将本次待存储数据存放在应急存储节点上；

其中，存储第二节点的剩余存储空间大于预设第二剩余存储空间，预设第一剩余存储空间小于或者等于预设第二剩余存储空间；避免存储器中由于某个节点剩余存储空间小于预设第一剩余存储空间时导致存储器整体不能继续进行新数据的读写，影响用户体验。

或/和在步骤S1中，还包括：

每隔T时间将获取的修改数据保存到指定的分布式存储节点上，所述T为正数，并记录每次保存节点的时间与数据文件的修改时间。

在本发明的一种优选实施方式中，还包括外部系统既可直接实时调用业务系统的海量医疗数据，也可以从区块链云平台上获取海量医疗数据。在本实施方式中，外部系统为其它分布式存储节点。

在本发明的一种优选实施方式中，在步骤S1中包括：

业务系统向其它服务器的系统上创建一个文件夹A，再在文件夹A中创建一个文件a.json，向文件a.json里写入格式为json的流程节点数据；

利用GitLab客户端创建一个用户，该用户包括用户设置的用户名和密码，登录成功后，该用户创建或选择一个分组G，再在分组G内创建一个项目仓库R。

在本发明的一种优选实施方式中，若检测到删除已经合并到master的所有分支，则业务系统将已经合并到master的所有分支删除。

在本发明的一种优选实施方式中，若检测到基于master的分支末梢创建新分支并检出c分支，规定一个流程为一个分支，则将当前分支c最近一次提交创建标签。

在本发明的一种优选实施方式中，往文件a.json里修改下一个状态数据，并追加第二个流程节点相关数据的方法为：

在c分支上提交文件a.json所有发生的修改，然后推送到远程版本仓库；

如果流程结束，则将c分支合并到master分支，压缩合并后直接提交；

如果流程未结束，则将当前分支c最近一次提交创建标签。

在本发明的一种优选实施方式中，读取文件夹A下文件a.json获取数据列表的方法为：

首先切换到c分支，然后检出标签，再获取更新。

在本发明的一种优选实施方式中，首先切换到c分支，再获取更新。

在本发明的一种优选实施方式中，查看自己或所有的流程状态和数据的方法：

利用事先在GitLab客户端中注册的账号的权限，然后调用Git相应的命令进行查看。

Git本身具备分布式存储和状态机工作流的特性，通过与业务相应的Git命令调用可以实现业务数据的分布式存储和状态机工作流。

一般我们医疗的业务系统，目前主流采用的架构是分布式微服务混合架构。

业务系统正常的业务调用走的还是关系型数据库和NOSQL等方式。

如图2所示，如果是碰到流程化管理的业务，就需要用到状态机工作流+分布式存储数据，流程化管理的业务往往是目前最多需要打印纸质凭证的地方。

步骤化流程管理的业务通过异步推送MQ消息(JSON数据)给“数据分发器系统”异步消费(JSON数据)，同时“数据分发器系统”根据业务需求调用Git相应命令让Git执行分布式存储和状态机工作流操作。

Git返回数据给“数据分发器系统”后，“数据分发器系统”再异步推送MQ消息(JSON数据)让业务系统来异步消费(JSON数据)。

业务系统实时将该“步骤化流程管理的业务数据”经由上链系统网关，统一上传到区块链云平台进行存储。

外部系统既可直接实时调用业务系统的数据，也可以从区块链云平台上获取。

与业务相应的Git命令调用一般有以下场景(需要GitLab客户端配合)：

工作流开发：第一次调用时初始化并创建一个流程引擎，以后再调用就会返回相同的流程引擎。

业务系统：横向集群扩展的系统，需要在不同服务器的系统每个都创建一个文件夹A，文件夹内创建一个文件a.json，向a.json里写入格式为json的流程节点数据。

GitLab客户端：创建一个用户，设置好用户名密码，用该用户创建或选择一个分组G，创建一个项目仓库R，

对应Git命令：git init(本地会初始化创建一个.git的文件，也就是版本仓库)，进入文件夹A，执行命令：git remote add origin http://root@gitlab.***.com:8080/G/R.git，

然后执行命令：git add a.json(让a.json文件加入到版本库)，

然后执行命令：git commit-m"Initial commit"(提交a.json文件)，

然后执行命令：git push-u origin master(推送到远程版本仓库)，

工作流开发：使用对应的方法删除所有流程引擎。

对应Git命令：git branch--merged master|grep-v'^\*\|master'|xargs-n1git branch–d(删除已经合并到master的所有分支)

工作流开发：部署流程。

对应Git命令：git checkout-b c(基于master的分支末梢创建新分支并检出c分支，规定一个流程为一个分支)，然后执行命令：git tag step0(为当前分支c最近一次提交创建标签)

工作流开发：开始流程。

业务系统：往a.json里修改下一个状态数据，并追加第二个流程节点相关数据。

对应Git命令：git commit–m“业务信息”(c分支上提交a.json文件所有发生的修改)，然后执行命令：git push-u origin c(推送到远程版本仓库)

工作流开发：办理流程。

对应Git命令：如果流程结束执行命令：git merge--squash master(c分支合并到master分支，压缩合并后直接提交)，如果流程还没完执行命令：git tag step1…(为当前分支c最近一次提交创建标签)

工作流开发：待办列表。

业务系统：读取文件夹A下a.json文件获取数据列表。

对应Git命令：git checkout c(切换到c分支)，然后执行命令：git checkoutstep0(检出标签step0)，然后执行命令：git pull(获取更新)

工作流开发：过程中列表。

业务系统：读取文件夹A下a.json文件获取数据列表。

对应Git命令：git checkout c(切换到c分支)，然后执行命令：git pull(获取更新)

工作流开发：已结束列表。

业务系统：读取文件夹A下a.json文件获取数据列表。

对应Git命令：git checkout master(切换到master分支)，然后执行命令：gitpull(获取更新)

工作流开发：查看自己或所有的流程状态和数据。

业务系统：按照事先在GitLab中注册的账号的权限然后调用Git相应的命令就可以查看到了。相应的看所有就用root账户。

尽管已经示出和描述了本发明的实施例，本领域的普通技术人员可以理解：在不脱离本发明的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由权利要求及其等同物限定。

Claims (9)

1.一种海量医疗数据的状态机工作流引擎及分布式存储方法，其特征在于，包括：

S1，获取海量医疗数据；

S2，业务系统判断是否接收到医疗数据流程化管理的业务命令：

若业务系统接收到医疗数据流程化管理的业务命令，则执行步骤S2；

若业务系统未接收到医疗数据流程化管理的业务命令，则继续等待；

S3，通过异步推送MQ消息给医疗数据分发器系统异步消费JSON数据，同时医疗数据分发器系统根据业务需求调用Git相应命令让Git执行分布式存储和状态机工作流操作；

S4，Git返回数据给医疗数据分发器系统后，医疗数据分发器系统再异步推送MQ消息让业务系统来异步消费JSON数据；

S5，业务系统实时将医疗流程化管理的业务数据经由上链系统网关，统一上传到区块链云平台进行存储。

2.根据权利要求1所述的海量医疗数据的状态机工作流引擎及分布式存储方法，其特征在于，还包括外部系统既可直接实时调用业务系统的海量医疗数据，也可以从区块链云平台上获取海量医疗数据。

3.根据权利要求1所述的海量医疗数据的状态机工作流引擎及分布式存储方法，其特征在于，在步骤S1中包括：

业务系统向其它服务器的系统上创建一个文件夹A，再在文件夹A中创建一个文件a.json，向文件a.json里写入格式为json的流程节点数据；

利用GitLab客户端创建一个用户，该用户包括用户设置的用户名和密码，登录成功后，该用户创建或选择一个分组G，再在分组G内创建一个项目仓库R。

4.根据权利要求1所述的海量医疗数据的状态机工作流引擎及分布式存储方法，其特征在于，若检测到删除已经合并到master的所有分支，则业务系统将已经合并到master的所有分支删除。

5.根据权利要求1所述的海量医疗数据的状态机工作流引擎及分布式存储方法，其特征在于，若检测到基于master的分支末梢创建新分支并检出c分支，规定一个流程为一个分支，则将当前分支c最近一次提交创建标签。

6.根据权利要求1所述的海量医疗数据的状态机工作流引擎及分布式存储方法，其特征在于，往文件a.json里修改下一个状态数据，并追加第二个流程节点相关数据的方法为：

在c分支上提交文件a.json所有发生的修改，然后推送到远程版本仓库；

如果流程结束，则将c分支合并到master分支，压缩合并后直接提交；

如果流程未结束，则将当前分支c最近一次提交创建标签。

7.根据权利要求1所述的海量医疗数据的状态机工作流引擎及分布式存储方法，其特征在于，读取文件夹A下文件a.json获取数据列表的方法为：

首先切换到c分支，然后检出标签，再获取更新。

8.根据权利要求7所述的海量医疗数据的状态机工作流引擎及分布式存储方法，其特征在于，首先切换到c分支，再获取更新。

9.根据权利要求1所述的海量医疗数据的状态机工作流引擎及分布式存储方法，其特征在于，查看自己或所有的流程状态和数据的方法：

利用事先在GitLab客户端中注册的账号的权限，然后调用Git相应的命令进行查看。