分布式架构核算体系统一日切调度方案.docx

上传人:王** 文档编号:786063 上传时间:2024-01-14 格式:DOCX 页数:12 大小:108.46KB
下载 相关 举报
分布式架构核算体系统一日切调度方案.docx_第1页
第1页 / 共12页
分布式架构核算体系统一日切调度方案.docx_第2页
第2页 / 共12页
分布式架构核算体系统一日切调度方案.docx_第3页
第3页 / 共12页
分布式架构核算体系统一日切调度方案.docx_第4页
第4页 / 共12页
分布式架构核算体系统一日切调度方案.docx_第5页
第5页 / 共12页
分布式架构核算体系统一日切调度方案.docx_第6页
第6页 / 共12页
分布式架构核算体系统一日切调度方案.docx_第7页
第7页 / 共12页
分布式架构核算体系统一日切调度方案.docx_第8页
第8页 / 共12页
分布式架构核算体系统一日切调度方案.docx_第9页
第9页 / 共12页
分布式架构核算体系统一日切调度方案.docx_第10页
第10页 / 共12页
亲,该文档总共12页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《分布式架构核算体系统一日切调度方案.docx》由会员分享,可在线阅读,更多相关《分布式架构核算体系统一日切调度方案.docx(12页珍藏版)》请在优知文库上搜索。

1、分布式架构核算体系统一日切调度方案1、背景在上一篇文章中,我们向大家介绍了面向信用助贷业务的业财一体化核算体系。在本篇文章中,我们将向大家介绍在分布式架构核算体系中,我们是通过什么方式处理日切问题的。Ll关于日切首先,我们需要理解日切的概念:在传统金融类业务中,会定义一个时间切点(并不一定是每个自然日的00:00:00),每日在该时间点之前发生的业务,使用一个记账日期(有时也称为会计日期)进行记账,在该时间点之后发生的业务,使用下一个记账日期进行记账。所谓日切,通俗的来说就是根据该时间切点进行记账日期的切换,整个日切过程需要对当日该时间切点前发生的交易数据进行集中批量处理,并做好受理下一日交易

2、的准备,整体处理完毕后,系统从当前记账日切换到下一记账日。对于支持7*24小时的系统,日切过程中交易可以照常提交并正确处理返回。1.2分布式核算体系处理日切的难点在传统单体应用中,可以在核心系统中记录时间切点,并通过Cronc1、quartz等调度工具控制日切过程中的一系列夜间批量处理作业间的依赖关系及调度次序。而在我们的分布式架构的核算体系中,包括了台账、账务、会计等多个系统。数据分布在多个系统中,且每个系统的日切过程都有自己的一系列批量处理作业,且各个系统的批量处理作业间存在相对比较复杂的数据依赖或时序依赖关系。我们需要解决:(1)每个系统对时间切点及记账日期的定义如何保持一致;(2)各个

3、系统间的日切作业如何协调调度并保持逻辑一致;(3)如何核对各个系统中的数据等一系列的问题。本篇文章,将向大家介绍,我们是如何形成一套统一日切调度方案,并解决上述问题的。2、解决方案2.1 分布式系统间的批量作业协同如下图,分布式架构的核算体系中,包括多个系统。每个系统负责自己领域内的日切功能完成,在各自的日切过程中都有自己的一个或一系列批量处理作业。但各个系统的批量处理作业间存在相对比较复杂的数据依赖或时序依赖关系。系统A系统B系统C系统D图1业务系统分布这一问题,可以通过各个系统定义各自批处理作业的启动时间,并在启动前询问上游依赖系统的批处理作业是否完成来解决。但这一方案存在:依赖需要在各系

4、统中分散管理;如果数据量发生剧烈变化则各作业的启动时间需要进行小心调整等问题。我们的方案是建立统一的日切调度系统,集中统一管理各系统批处理作业间的依赖关系,并统一进行调度。这样,整个日切过程中,如果有新增批量处理作业,或各系统间日切作业的依赖关系发生变化,可以由该系统统一管理。具体如下图所示:日切调度系统账单核心系统台账系统账务系统会计系统图2多业务系统间协作2.2统一分布式系统间的时间切点要保证在分布式架构下日切数据的准确,各业务系统的时间切点需要保持一致,故不应由各系统各自定义。常见的可选方案是在统一的配置中心中定义切点,并在各系统引用该配置。但考虑各系统日切不仅需要时间切点这个配置,还需

5、要统一记账日期这个动态数据(记账日期和自然日并不一定完全一致,可能会早于(追赶历史数据)或晚于(未来记账日执行测试)自然日)。记账日期的变化一般由某一系统中心化地进行统一控制,考虑到我们为了统一调度分布式系统间的批量作业,建立了统一日切调度系统,故在该系统中定义时间切点和记账日期,并推送至各业务系统。具体实施时,假设时间切点是00:00:00,在时间切点之前,日切调度系统触发日切通知,将时间切点和下一个记账日期推送至系统。下图是调度系统的日切通知流程,(1)因为账务系统有对记账日进行合理性校验的功能:如果记账日非法(比如与当前记账日不连续),可以返回错误,中断整体日切过程,故首先通知到账务系统

6、;(2)校验通过后就可以按照交易数据传递方向依次通知各业务系统。图3记账日、时间切点通知2.3分布式核算体系业务数据逻辑一致性业务数据逻辑一致性指的是:同一笔交易,在各系统中需要被认定为在同一个记账日期,且在各系统中,该笔交易的状态及金额一致。为解决该问题,我们首先需要保证业务数据在各系统中被正确传递,且不丢失。其次,各系统需要能根据时间切点信息,辅以日切调度系统传递的控制信息,准确切分数据。最后,需要通过数据核对验证数据的逻辑一致性。分布式架构业务数据流向如图在交易体系与核算体系的交互过程中,数据是从交易体系的账单核心系统流向台账系统。在核算体系内部,数据由台账系统流向账务系统,再由账务系统

7、流向会计系统。核算体系内数据处理不影响客户交易行为,数据采用异步准实时传递,并且下游系统对上游系统的处理进度无感知。该过程中业务数据有两个特点:每条数据带有交易时间;数据在系统间传递不一定完全有序。基于以上两个特点,我们会使用什么方案将数据准确切分到不同的记账日期进行记账呢?业务数据流向账单核心系统数据传递(交易时间)交易体系台账系统数据传递(交易时间)体账务系统图4分布式系统业务数据流如何保证记账日数据切分准确要实现日切数据准确需满足两点:(1)每个系统对业务数据的记账日切分正确;(2)每个系统日切数据不缺失。在2.2中,我们已经通过统一日切调度系统将时间切点准确送给各业务系统。各系统可通过

8、业务数据的交易时间和时间切点比较判断,在下图中,业务数据在各个系统中传递,假设日切时间切点是00:00:00,每个系统将发生时间在0点前的数据判断为上一记账日数据,0点后判断为下一记账日数据。图5记账日数据切分然而前文已经提到,系统间的数据交互并不能保证一定是按交易时间有序传递数据,故下游系统有可能提前收到属于下一个记账日的数据,而上游上一个记账日的数据并未全部发送完毕。可能的选择有:1.下游等待一段足够长的时间,假定上游会在这段时间内将上一日数据发送完毕;2.上游通过额外接口通知下游上一日数据已发送完毕;3.下游通过接口询问上游是否已发送完毕。但这三种方式都有一定缺陷,第一种基于一个上游一定

9、会在短时间内将上一日数据发送完毕的假设;第二种方式这个通知本身可能会丢失;第三种方式会让系统交互互相依赖。此处我们采用的解决方案是通过统一日切调度系统协调,解耦上下游业务系统日切批量间的通知依赖(系统间相互依赖变为仅与统一调度系统发生依赖关系),并且通过引入工作流组件bizflow实现查询及通知可重试机制。如下图中,日切调度系统不断轮询账单核心系统上一日数据是否发送完成,在确认发送完成后,调度系统将此信息告知台账系统,则台账系统可以基于已收到的数据明确切分。后面流程与之相似,调度系统按照数据传递的顺序依次询问上游系统日切执行进度,并通知下游系统,保证每个系统上一记账日数据处理完整性。业务数据流

10、向调度流程控制账单核心系统账务系统台账系统会计系统日切调度系统图6各系统日切流程依赖控制7*24小时业务系统日切实现ountOUMoc I LtoJr工IMX)JIA(UIIC(UlPtl图77*24小时业务系统日切实现账务系统日切需要将账务账户切换到下一记账日,由于账户数量在千万级别,日切批量作业过程比较长且记账业务不会停。如果某账户已经完成日切,上一日流水记账需要联动上一日和下一日两个账户余额;如果某账户未日切,上一日流水记账只需要更新上一日账户余额即可。当日切批量作业和实时流水记账两个过程尝试更新同一个账户余额时,会产生更新冲突问题。我们采用锁机制解决余额更新冲突问题,考虑到日切批量作业

11、过程中账户表会有记录插入操作,我们采用分布式锁方案。上图为该方案的示意图,为了提高记账效率,我们只在日切过程中加锁(即图中的加锁期),而日间实时流水记账时无需加锁(即图中的无锁期),图中A,B,C代表账务系统的不同账户,(X)表示该账户是未加锁状态,(L)表示该账户是已加锁状态。我们将加锁期又分为预热期和日切执行期(即真正的日记批量作业执行期)。其中实时流水记账会在预热期和日切执行期均尝试对账户加锁;而真正的日切批量仅会在日切执行期尝试对账户加锁。在日切开始后,首先进入预热期,通过预热期J的存在,我们可以确保正在处理的实时流水记账过程涉及的账户都已加锁。当进入日切执行期后,而实时流水记账和日切

12、批量作业两个过程均会对尝试更新的账户加锁,故可以保证对同一个账户的更新正确。2.4大规模数据核对业务核对功能前文描述是提供了业务数据逻辑一致性的方案,我们还需要一种方式来验证我们技术方案的正确性。因此需要在系统间进行日终批量完成后的数据(即每日日终数据)核对,验证数据在各系统间逻辑一致;并且核对结果的产出时效要高。应用系统核对的难点首先可以考虑到的是在应用系统层面进行核对。然而该方案有两大难点:(1)数据量级大,需要核对的数据量有千万级别,如台账系统的分期数、账务系统的账户数分别约有5000万,会计系统每日分录约有3000万。通过Java代码+关系型数据库的方式对账效率会过低,且对关系型数据的

13、系统资源占用会过高;(2)数据分布式在各系统各自的库中,如在某个系统进行明细核对,则需要将每个数据库的大量数据同步到同一个数据库中。解决方案综合业务诉求(需要系统在每日工作开始前完成对账)和应用系统对账的难点,我们在离线数仓平台上进行数据核对。离线数仓能将不同数据库的数据抽取到同一个平台中,并且能通过分布式计算能力提供高效的数据核对能力。如下图所示,是日切数据核对过程,因为核对流程需要依赖系统日切流程完成,所以在日切完成后,日切调度系统先协调抽数任务;调度系统感知到抽数全部完成后,再通知离线数仓平台进行对账,并且覆盖了业务需要的多种对账场景,做到了核对数据全覆盖。,榴敷完成一Q计日切图8日切数据核对3、总结通知业务系统切度统日调系日切协作离线数仓平台-抽数、对账士图9分布式架构统一日切调度模型本文描述了一种分布式架构核算体系统一日切调度的方案,一步步拆解问题并一一解决,最终提供了一种统一日切调度模型。该模型由通知、日切协作、数据核对三个流程组成,由日切调度系统实现整体流程控制。目前体系中是每日日终进行离线对账,在未来规划中,为提高整个体系的时效,拟将按天的周期改成按小时的周期,提高数据核对的时效,减少日终批次的压力。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 办公文档 > 解决方案

copyright@ 2008-2023 yzwku网站版权所有

经营许可证编号:宁ICP备2022001189号-2

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!