南京地铁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业务处理层之间的数据文件传输处理可靠性。

3.4ACC后台数据层硬件扩容，重新规划磁盘阵列数据

结合ACC系统文件传输处理流程调整方案，考虑新磁盘阵列仅存储在线数据库数据，提高其安全和性能；既有的两台磁盘阵列一台保存历史数据库数据，一台用于ACC前置业务层和ACC业务处理层的数据存放。

4ACC系统文件传输处理流程调整方案可行性分析

根据之前的调整方案描述，并结合现有的文件传输处理流程，调整后的流程示意图如下：

图2 ACC系统文件传输处理流程调整后示意图

4.1ACC前置业务层

ACC前置业务层上增加一组服务器集群组成ACC前置业务层2，用于处理新线接入数据，既有线路数据处理流程不变。

4.2ACC业务处理层

考虑对现有ACC系统应用拆分的原则，同时参考现有的设备运行情况，一卡通业务保留在原有服务器集群上，一票通及其他综合业务则部署在另两组服务器集群上或考虑采用多机集群方式进行。

4.3数据分类筛选层

数据分类筛选层是建立在ACC前置业务层与ACC业务处理层之间，考虑在前置业务层设备上开发一套应用软件，按照ACC系统现有管理规则对上下行数据进行分类处理。

4.4ACC后台数据层

配合硬件系统资源，将历史数据库和在线数据库从硬件设备上进行分离，增加阵列间的数据库迁移工作，提高数据库性能。

4.5 调整后的文件传输流程

既有线路和后续线路AFC系统通过AFC线路业务层，将各类上行数据文件分别传输至ACC前置业务层的两个服务器集群，在数据分类筛选层处理后按业务类型传输至ACC业务处理层进行处理，最后存储在ACC后台数据层在线数据库中（如图2黑线所示）。ACC系统按照不同业务类型，通过ACC业务处理层处理后生成各类下行数据文件，再经过数据分类筛选层筛选按需分别传输至ACC前置业务层的两个服务器集群，最终传输至AFC线路业务层的各线路LC或ZLC系统前置机。（如图2绿线所示）。

ACC系统与一卡通公司系统之间数据交换仍放在ACC前置业务层的原有服务器集群上，ACC系统与一卡通公司系统之间每天通过ACC前置业务层和ACC业务处理层的原有服务器集群进行一卡通清结算对账工作，黑名单及卡对应关系文件则按期由一卡通公司传输至ACC系统处理，ACC业务处理层上对此类数据处理考虑放在新增的其他综合业务服务器集群上完成（如图2红线所示）。

ACC后台数据层中历史数据库和在线数据库分不同阵列存储，定期进行跨库迁移。

4.6调整方案优点

ACC前置业务层可扩展性和系统标准兼容性增强，对后续线路提供了良好的接入平台，满足未来各类线路系统的接入要求；ACC业务处理层业务更加分散，减小了该层级的压力，既降低了设备风险，又对新增业务提供了良好的扩展性；数据分类筛选层的建立有助于管理ACC前置业务层和ACC业务处理层之间的上下行数据；ACC后台数据层的调整则更加符合实际生产需要。

5结论

本文讨论的调整方案将成为南京地铁ACC系统性能提升的又一大举措，为今后的新线AFC系统建设、ACC系统二期建设奠定了基础。对ACC功能定位进行初步尝试，对完善ACC系统功能提供了良好的理论依据。