CN115563224A - 一种分布式参数缓存*** - Google Patents

Abstract

本发明涉及一种分布式参数缓存***，通过嵌入式的应用在业务服务节点上，无需独立部署服务，采用时间轮定时拉取、及参数变更的MQ消息的消费响应拉取两种方式，高效快速的保证参数缓存的一致性、实时性与轻量级，不存在网络闪断、IP切换带来的各种弊端，支持各种数据结构，合理利用内存空间，不存在资源浪费。

Description

一种分布式参数缓存***

技术领域

本发明涉及参数缓存技术领域，尤其涉及一种分布式参数缓存***。

背景技术

现阶段分布式缓存技术大都需要独立部署服务集群，自动容错和恢复功能较差，主机从机的宕机都会导致前端部分读取请求失败，需要等待缓存服务节点重启或者手动切换前端IP才能恢复。此外，主机宕机以及部署数据未同步到从机，切换IP还会引入数据不一致问题，降低了***的可用性，较难支持在线扩容，集群容量达到上限时在线扩容变得很复杂，为避免此问题，运维人员在***上线时候必须确保有足够空间，这对资源造成了很大的浪费。

发明内容

本发明提供了一种应用于***核心交易***中的分布式参数缓存***。该***解决了现有技术中由于单元化的原因，各单元数据与服务分开管理，一些业务需要集中管理的数据，但无法跨单元访问的问题。本发明实现了分布式***各单元化应用服务中公有、私有化参数读取，并保证了高效、一致性访问。

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

一种分布式参数缓存***，所述分布式参数缓存***作为公共参数平台的中间层，上层为综合运营平台、下层为业务模块；

分布式参数缓存***包括核心框架、SDK参数缓存模块以及文件增量处理模块；其中，

所述核心框架用于对分布式参数缓存***进行业务初始化；

所述SDK参数缓存模块用于向业务方提供各种调用参数；

所述文件增量处理模块用于与上层的综合运营平台对接以确定文件格式。

进一步的，所述核心框架为综合运营平台提供4个接口，分别是查询接口、检查接口、维护接口、分拆提交接口。

进一步的，所述核心框架包括维护接口单元、检查接口单元、查询接口单元、接口默认实现单元、执行流程单元、批量提交单元、分拆提交单元和分析日志单元，其中，

所述维护接口单元、检查接口单元以及查询接口单元分别用于执行接口的维护、检查和查询工作，

所述接口默认实现单元和执行流程单元用于实现接口功能，

所述批量提交单元和分拆提交单元分别用于实现请求的批量、分拆提交，

所述分析日志单元用于根据与所述综合运营平台对接的数据来进行日志分析。

进一步的，所述SDK参数缓存模块包括MQ指令监听单元、定时查询单元和参数缓存单元，其中，所述MQ指令监听单元用于监听来自核心框架下发的指令，所述定时查询单元用于通过时间轮的方式实时刷新缓存，所述参数缓存单元用于缓存集成的参数。

进一步的，所述文件增量处理模块包括文件获取单元、文件解析单元、文件比对单元和差异化处理单元，其中，

所述文件获取单元用于根据文件增量请求从所述综合运营平台接收文件，所述文件解析单元用于对从所述综合运营平台接收的文件进行解析，所述文件比对单元用于将解析后的文件与数据库DB中的文件进行对比，所述差异化处理单元用于对比对结果不同的差异化数据进行重新维护。

进一步的，所述核心框架还包括业务初始化单元，用于在业务启动时，对业务的实现类进行初始化，并将业务绑定相应执行流程，在执行完相关检查流程后绑定入库。

进一步的，所述文件增量处理模块用于批量化处理公共参数变更请求，按照预设时间定期从所述综合运营平台拉取文件，实现文件格式解析，并提供统一的文件增量数据对比校正和落库操作。

进一步的，所述综合运营平台将FORM表单请求发送至维护接口，并根据FORM表单请求中携带的commitNo数据判断同一FORM表单中指定的参数类型并进行分拆操作，将分拆后的一批分拆请求以及分拆完成指令传输至批量提交单元，其中同一批分拆请求具有相同的批次号；所述FORM表单请求中包括发卡参数、额度参数、授权参数以及批量参数。

进一步的，所述批量提交单元在接收到所述综合运营平台发出的分拆完成指令后，对于提交的请求在数据库DB的日志表中进行记录，对分拆日志中同一批次的日志进行解析，并调用维护接口。

进一步的，所述核心框架与配置中心相连接，所述配置中心用于支持公共参数的业务性检查、维护性检查以及流程配置，并且对于不配置的公共参数按照默认检查和流程进行处理。

通过本发明实施例，可以获得如下技术效果：

（1）通过SDK的方式提供参数近似本地化读取，调用方便的同时使用方可以无感知，并且参数缓存在本地节点，性能明显高于实时远程调用。

（2）通过核心框架式维护参数的更新，提供统一日志拆分、解析、落库、查询和维护以及批量操作，并提供各类业务参数的默认实现，即使各业务组参数类型不同，亦可无需开发，直接使用。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为各应用的总体架构示意图；

图2为分布式参数缓存***中各模块的关系示意图；

图3为分拆提交和分析日志的流程示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的全部其他实施例，都属于本发明保护的范围。

在对本发明的技术方案进行详细描述之前，首先对本发明中使用的术语约定进行如下介绍：

分布式：分布式***是区别与原来的采用单一服务器运行、存储的一种可扩展的***结构，利用多台服务器分担运算、存储负荷，不但解决了传统集中式存储***中单存储服务器的瓶颈问题，还提高了***的可靠性、可用性和扩展性。

综合运营平台：外部***，对参数进行视图视图化管理，由当前平台进行表单提交公共参数SDK。

参数缓存：通过内部缓存框架进行参数的缓存。

文件服务平台：对文件进行管理，用于提供文件上传下载功能。

：公共参数平台提供业务方调用参数。

时间轮：一种类似定时任务的高效率实现。

图1为各应用的总体架构示意图。分布式参数缓存***作为综合运营平台与业务平台的中间层，起到承上启下的作用，上层为综合运营平台、下层为业务模块。分布式参数缓存***中的核心框架为综合运营平台提供了4个接口，分别是查询接口、检查接口、维护接口、分拆提交接口，综合运营平台将同一个FORM表单分拆成多个，分多次请求来调用公共参数平台。

本发明的分布式参数缓存***包括核心框架、SDK参数缓存模块以及文件增量处理模块。分布式参数缓存***中各模块的关系如图2所示。

核心框架，用于对分布式参数缓存***进行业务初始化，分别由维护接口单元、检查接口单元以及查询接口单元来执行接口的维护、检查和查询工作，由接口默认实现单元和执行流程单元来实现接口功能，请求的批量、分拆提交分别由批量提交单元和分拆提交单元来实现，由分析日志单元根据与综合运营平台对接的数据来进行日志分析；

SDK参数缓存模块，用于向业务方提供各种调用参数，通过MQ指令监听单元监听来自核心框架下发的指令，定时查询单元通过时间轮的方式实时刷新缓存，并将集成的参数缓存至参数缓存单元中；

文件增量处理模块，用于与综合运营平台确定文件格式，由文件获取单元根据文件增量请求从综合运营平台接收文件，由文件解析单元对从综合运营平台接收的文件进行解析，由文件比对单元将解析后的文件与数据库DB中的文件进行对比，由差异化处理单元对比对结果不同的差异化数据进行重新维护。

在核心框架中，业务初始化单元，用于在业务启动时，对业务的实现类进行初始化，并将业务绑定相应执行流程，在执行完相关检查流程后绑定入库。执行流程单元，按照绑定的执行流程执行操作。

核心框架与配置中心相连接，所述配置中心用于支持公共参数的业务性检查、维护性检查以及流程配置，对于不配置的公共参数则配置中心将按照默认检查和流程进行处理。

SDK参数缓存模块提供给业务方以获取参数JAR包，SDK参数缓存模块所实现的两大功能包括：

（1）查询功能：根据给定参数，通过查询参数API，无差异化获取参数结果集；

（2）刷新功能：根据监听获得的MQ指令对参数本地缓存进行刷新或者根据时间轮自行刷新。

文件增量处理模块批量化处理公共参数变更请求，按照预设时间定期从综合运营平台获取文件，实现文件格式解析，并提供统一的文件增量数据对比校正和落库操作。

图3为分拆提交和分析日志的流程示意图。综合运营平台将FORM表单请求发送至维护接口，FORM表单请求包括发卡参数、额度参数、授权参数以及批量参数；

FORM表单请求中还包括commitNo、commitIdex以及commitTotal，综合运营平台根据commitNo判断同一FORM表单中指定的参数类型并进行分拆操作，将分拆后的一批分拆请求以及分拆完成指令传输至批量提交单元，同一批分拆请求具有相同的批次号；

批量提交单元在接收到综合运营平台发出的分拆完成指令后，对于提交的请求在数据库DB的日志表中进行记录，对分拆日志中同一批次的日志进行解析，并调用维护接口。数据库DB的日志表栏位如下表所示。

分布式参数缓存***对外提供统一的查询接口单元、检查接口单元以及接口默认实现单元，接口默认实现单元用于针对无定制化需求的参数化业务，通过默认的实现方式在无需开发的情况下进行使用。

在核心框架中，核心接口包括查询接口单元、检查接口单元以及维护接口单元，上述接口单元的使用与定义如下：

（1）查询接口单元

参数定义：

{

"tableName":"xxxx",//公共参数服务定义的全大小表名称，也是参数缓存定义的参数名称

"condition":(code1=#{code1} AND code2=#{code2}) OR code3=#{code3}

"data":{

"code1":"code1",

"code2":"code2",

"code3":"code3",

}

}

相应定义：

[{//参数验证数据

"param1":"value1",

"param2":"value2",

"param3":[{

"param3_1","value3_1",

"param3_2","value3_2"

}]

}]

在上述代码中，定义了公共参数服务中的全大小表名称，即参数缓存定义的参数名称，数据查询方可根据给定参数，通过查询参数API，无差异化获取参数结果集。

（2）检查接口单元

参数定义：

{

"paramType":"test_01",//参数类型，公共参数服务定义的全表名称

"checkType":"A",//操作类型，A-新增U-更新D-删除

"paramData":{//参数验证数据

"param1":"value1",

"param3":[{"param3_1":"value3_1"}]

}

}

相应定义：

{

"paramType":"test_01",//参数类型

"result":"true/false",//参数检查结果

"message":"通过",//不通过错误原因

"code":0//参数维护结果0-成功1-维护中2-维护错误3-版本错误不维护

}

在上述代码中，定义了检查接口单元的检查对象、操作类型以及参数验证数据，检查对象包括参数类型和公共参数服务定义的全表名称，操作类型包括“A-新增”、“U-更新”以及“D-删除”。

检查接口单元根据检查对象和参数验证数据的比对检查结果来执行相应的“A-新增”、“U-更新”以及“D-删除”操作，并反馈参数类型以及对应的检查结果。检查结果包括参数检查结果、原因信息以及参数维护结果。其中参数检查结果包括"true"或者"false"，原因信息包括"通过"的原因或者“不通过”的原因，参数维护结果包括"0-成功"、"1-维护中"、"2-维护错误"、"3-版本错误不维护"。

"true"参数检查结果对应了"通过"的原因信息，"false"参数检查结果对应了“不通过”的原因信息，以及参数维护结果中的任意一项。（3）维护接口单元

参数定义：

{

"paramType":"test_01",//参数类型，公共参数服务定义的全表名称

"operateType":"A",//操作类型，A-新增U-更新D-删除

"commitNo":"123456",//提交的批次号，如果为空表示只有1个批次

"commitIndex":1,//当前额commit的索引号

"commitTotal":10,//需要多少次commit

"paramData":{//参数数据

"param1":"value1",

"param3":[{"param3_1":"value3_1"}]

}

"uniKey":{"key1":"keyValue1"}//参数唯一键值，新增验证唯一，修改和删除作为查询条件使用AND连接

}

相应定义：

{

"paramType":"test_01",//参数类型

"result":"true/false",//参数维护结果

"message":"通过",//维护失败原因

"code":0//参数维护结果0-成功1-维护中2-维护错误3-版本错误不维护

}

在上述代码中，定义了维护接口单元的维护对象、操作类型、批次号、commit索引号、commit次数、参数数据以及参数唯一键值，维护对象包括参数类型和公共参数服务定义的全表名称，操作类型包括“A-新增”、“U-更新”以及“D-删除”。

批次号表示进行维护时提交的批次号，如果为空表示只有1个批次，例如"123456"表示批次号"123456"。

维护接口单元根据参数唯一键值来执行相应的“A-新增”、“U-更新”以及“D-删除”操作，并反馈参数类型以及对应的检查结果。检查结果包括参数维护结果、原因信息以及参数维护结果。其中参数维护结果包括"true"或者"false"，原因信息包括"通过"的原因或者“维护失败”的原因，参数维护结果包括"0-成功"、"1-维护中"、"2-维护错误"、"3-版本错误不维护"。

"true"参数检查结果对应了"通过"的原因信息，"false"参数检查结果对应了“维护失败”的原因信息，以及参数维护结果中的任意一项。

综上所述，本发明的分布式参数缓存***无需独立部署服务，即嵌入式的应用在业务服务节点上，通过时间轮定时拉取、及参数变更的MQ消息的消费响应拉取两种方式，高效快速的保证参数缓存的一致性、实时性与轻量级，不存在网络闪断、IP切换带来的各种弊端，支持各种数据结构，合理利用内存空间，不存在资源浪费。

最后说明的是，以上优选实施例仅用以说明本发明的技术方案而非限制，尽管通过上述优选实施例已经对本发明进行了详细的描述，但本领域技术人员应当理解，可以在形式上和细节上对其作出各种各样的改变，而不偏离本发明权利要求书所限定的范围。

Claims (10)

1.一种分布式参数缓存***，其特征在于，所述分布式参数缓存***作为公共参数平台的中间层，上层为综合运营平台、下层为业务模块；

分布式参数缓存***包括核心框架、SDK参数缓存模块以及文件增量处理模块；其中，

所述核心框架用于对分布式参数缓存***进行业务初始化；

所述SDK参数缓存模块用于向业务方提供各种调用参数；

所述文件增量处理模块用于与上层的综合运营平台对接以确定文件格式。

2.根据权利要求1所述的分布式参数缓存***，其特征在于，所述核心框架为综合运营平台提供4个接口，分别是查询接口、检查接口、维护接口、分拆提交接口。

3.根据权利要求2所述的分布式参数缓存***，其特征在于，所述核心框架包括维护接口单元、检查接口单元、查询接口单元、接口默认实现单元、执行流程单元、批量提交单元、分拆提交单元和分析日志单元，其中，

所述维护接口单元、检查接口单元以及查询接口单元分别用于执行接口的维护、检查和查询工作；

所述接口默认实现单元和执行流程单元用于实现接口功能；

所述批量提交单元和分拆提交单元分别用于实现请求的批量、分拆提交；

所述分析日志单元用于根据与所述综合运营平台对接的数据来进行日志分析。

4.根据权利要求3所述的分布式参数缓存***，其特征在于，所述核心框架还包括业务初始化单元，用于在业务启动时，对业务的实现类进行初始化，并将业务绑定相应执行流程，在执行完相关检查流程后绑定入库。

5.根据权利要求1所述的分布式参数缓存***，其特征在于，所述SDK参数缓存模块包括MQ指令监听单元、定时查询单元和参数缓存单元，其中，所述MQ指令监听单元用于监听来自核心框架下发的指令，所述定时查询单元用于通过时间轮的方式实时刷新缓存，所述参数缓存单元用于缓存集成的参数。

6.根据权利要求1所述的分布式参数缓存***，其特征在于，所述文件增量处理模块包括文件获取单元、文件解析单元、文件比对单元和差异化处理单元，其中，

所述文件获取单元用于根据文件增量请求从所述综合运营平台接收文件；

所述文件解析单元用于对从所述综合运营平台接收的文件进行解析，

所述文件比对单元用于将解析后的文件与数据库DB中的文件进行对比；

所述差异化处理单元用于对比对结果不同的差异化数据进行重新维护。

7.根据权利要求1所述的分布式参数缓存***，其特征在于，所述文件增量处理模块用于批量化处理公共参数变更请求，按照预设时间定期从所述综合运营平台拉取文件，实现文件格式解析，并提供统一的文件增量数据对比校正和落库操作。

8.根据权利要求1所述的分布式参数缓存***，其特征在于，所述综合运营平台将FORM表单请求发送至维护接口，并根据FORM表单请求中携带的commitNo数据判断同一FORM表单中指定的参数类型并进行分拆操作，将分拆后的一批分拆请求以及分拆完成指令传输至批量提交单元，其中同一批分拆请求具有相同的批次号；所述FORM表单请求中包括发卡参数、额度参数、授权参数以及批量参数。

9.根据权利要求8所述的分布式参数缓存***，其特征在于，所述批量提交单元在接收到所述综合运营平台发出的分拆完成指令后，对于提交的请求在数据库DB的日志表中进行记录，对分拆日志中同一批次的日志进行解析，并调用维护接口。

10.根据权利要求1所述的分布式参数缓存***，其特征在于，所述核心框架与配置中心相连接，所述配置中心用于支持公共参数的业务性检查、维护性检查以及流程配置，并且对于不配置的公共参数按照默认检查和流程进行处理。

Images