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