南京地铁ACC系统文件传输处理流程调整方案研究.docVIP

南京地铁ACC系统文件传输处理流程调整方案研究 　　【内容摘要】根据南京地铁新线规划，在近2-3年内将有4-6条新线自动售检票(以下简称AFC)系统将接入票卡清分结算（以下简称ACC）系统，而ACC系统目前使用率已达设计上限， ACC系统文件传输处理流程须尽快调整。调整过程中须考虑线网标准兼容、业务拆分、数据库规划等方面问题，本文将着重介绍调整方案和各类问题处理方法。 　　 　　【关 键 词】 ACC系统文件传输处理平行扩展业务拆分 　　 中图分类号： U692.4+2文献标识码：A 文章编号： 　　 　　 　　1ACC系统文件传输处理现状及发展弊端 　　1.1现有ACC系统文件传输处理现状 　　南京地铁线路AFC系统与ACC系统间文件传输处理分为AFC线路业务层、ACC前置业务层、ACC业务处理层及ACC后台数据层。 　　现有一号线、二号线及一号线南延线均设立了独立线路中心（以下简称LC）系统通过AFC线路业务层、ACC前置业务层将上行数据文件传输至ACC业务处理层进行分类处理，最后存储在ACC后台数据层（如图1黑线所示）； ACC系统生成各类下行数据文件，通过ACC业务处理层、ACC前置业务层，最终传输至AFC线路业务层的各线路LC系统前置机（如图1绿线所示）。 　　ACC系统与一卡通公司系统之间每天通过ACC前置业务层和ACC业务处理层之间进行一卡通清结算对账工作，黑名单和卡对应关系文件则按期由一卡通公司传输至ACC系统处理（如图1红线所示）。 　　ACC后台数据层由在线数据库和历史数据库两部分组成，定期进行数据库内迁移。 　　 　　 　　图1 ACC系统现有文件传输处理流程图 　　1.2ACC系统文件传输处理发展弊端 　　如果后续线路建成后按照既有方式接入ACC系统，将会存在以下问题： 　　ACC业务处理层的文件传输处理过于集中。服务器一旦出现故障，所有ACC业务进程将全部停止，各类上行数据文件将堆积在ACC前置业务层，无法继续处理；同时ACC系统也无法生成参数、黑名单等各类下行数据文件，一卡通清结算工作无法进行，最终导致整个ACC系统文件传输处理全部瘫痪。 　　 （2）ACC前置业务层会出现新老线系统的接口标准兼容性问题。一方面新线系统接口和老线系统接口存在差异，另一方面新线即将引入区域线路中心（以下简称ZLC）系统概念，与LC系统接入ACC系统存在较大差别。（注：ZLC系统是基于传统多线路数据统一管理前提下，应用层实现相邻多个车站区域化管理的系统。） 　　（3）ACC后台数据层容量不足，目前ACC在线数据库空间使用率已达70%，新线接入后数据量将呈现几何级增长，影响数据库处理性能，且存储能力也不能满足新线的接入需求。 　　 　　2ACC系统文件传输处理流程调整必要性 　　根据南京地铁近期规划和“十二五”发展规划，2015年三号线、四号线一期、十号线一期、宁高、宁和、宁天城际六条线路将全部建成，新线AFC系统将接入ACC系统运营，现有的ACC系统资源和接入方式已不能满足新线的接入需求，必须调整ACC系统文件传输处理流程，优化整合现有系统资源，整体规划数据库的数据存储方式。此外，为配合AFC系统线网标准化的建设和发展，须对ACC系统文件传输处理流程进行调整，兼容新老线AFC系统标准，满足ZLC系统接入ACC系统的功能需求。 　　 　　3ACC系统文件传输处理流程调整方案 　　3.1ACC前置业务层平行扩展，具备新老线AFC系统标准兼容性 　　一号线、二号线和一号线南延线的ACC前置业务层不变，继续处理既有线路数据，而新老AFC系统接口标准不兼容，且新线AFC系统存在LC和ZLC两种接入模式，考虑对现有的ACC前置业务层进行平行扩展，按照“新老并存，分开处理”的方式，在同一级系统架构上增加一组服务器集群用来处理新线数据，解决新老线系统接口标准兼容问题。 　　3.2ACC业务处理层应用拆分，降低整个ACC系统运行风险性 　　现有ACC系统的所有应用业务全部集中在ACC业务处理层的一组服务器上，一旦出现故障将会导致ACC系统所有业务进程停止，造成ACC系统应用级瘫痪，考虑对现有的ACC业务处理层应用按照业务种类进行拆分，平摊风险，按照现有的数据类型考虑分为一卡通业务、一票通业务及其他综合业务三大类，分别部署在三组服务器集群或多机集群进行业务处理。 　　3.3ACC数据分类筛选层建立，分类处理ACC前置和后台数据 　　为了实现ACC业务处理层的应用拆分功能，考虑在ACC前置业务层与ACC业务处理层之间建立一个数据分类筛选层，整个系统中的各类上下行数据文件通过数据分类筛选层按照ACC系统处理原则进行分类管理，确保ACC前置业务层与ACC业务处理层之间的数据文件传输处理