详解地铁清分系统
- 格式:doc
- 大小:36.50 KB
- 文档页数:4
地铁清分中心ACC系统建设要素分析随着城市交通的发展,地铁系统作为城市快速交通的重要组成部分,其安全和运营效率的保障显得尤为重要。
地铁清分中心是地铁系统中的关键环节,负责收集、处理和管理各个地铁站点的清分工作。
为了提高地铁清分中心的工作效率和运营管理水平,需要建设一套高效稳定的地铁清分中心ACC(Automatic Clearing Control)系统。
本文将分析地铁清分中心ACC系统建设的要素,并提出相关建议。
1.系统硬件设备要素:首先,地铁清分中心ACC系统建设需要一套完善的硬件设备,包括服务器、计算机终端、网络设备、数据存储设备等。
这些硬件设备需要具备高性能、高稳定性和高可靠性,以确保系统的正常运行和数据的安全存储。
2.系统软件要素:地铁清分中心ACC系统建设还需要一套完善的软件系统,包括操作系统、数据库管理系统、数据处理软件等。
这些软件系统需要满足地铁清分中心的具体需求,能够实现数据的实时采集、处理和分析,并提供清晰的界面和报表输出功能。
3.数据采集要素:地铁清分中心ACC系统建设需要实现对各个地铁站点的数据实时采集。
数据采集要素包括数据传输设备、数据传输协议和数据采集模块等。
这些要素需要保证数据能够准确、及时地传输到地铁清分中心,并能够通过数据采集模块对数据进行实时监控和处理。
4.数据处理要素:地铁清分中心ACC系统建设需要有一套完善的数据处理机制。
数据处理要素包括数据清洗、数据整合和数据分析等。
数据清洗要素负责对采集到的数据进行筛选和过滤,排除无效数据。
数据整合要素负责将来自不同地铁站点的数据进行整合和归类。
数据分析要素负责对整合后的数据进行分析和汇总,提取有效信息并生成相关报表。
5.系统安全要素:6.系统性能要素:地铁清分中心ACC系统建设需要保证系统具备良好的性能,满足实时监控和高并发处理的需求。
系统性能要素包括系统响应速度、系统容量和系统可扩展性等。
这些要素需要保证地铁清分中心的系统能够支持大量数据的实时处理和分析,提高工作效率。
详解地铁清分系统详解地铁清分系统广州地铁自动售检票系统及其清分系统在实际运行中情况良好,系统达到了不间断工作的目标,为广州地铁的整个AFC系统提供持续稳定的服务。
随着信息化技术应用的不断深入,人们对计算机系统高可用性(High Availability)的要求不断提高,特别是企业基于数据库的关键业务系统,不仅希望保障关键业务数据信息的完整,而且希望联机应用能够不间断或者在最短的时间内自动恢复。
AFC系统及其清分系统简介广州地铁自动售检票系统(Automatic Fare Collection ,以下简称AFC)是基于计算机、通信、网络、自动控制等技术,实现城市轨道交通售票、检票、计费、收费、清分、管理等全过程的自动化系统。
目前,广州地铁自动售检票系统共分为车票、车站终端设备、车站计算机系统、线路中央计算机系统、清分系统五个层次(如下表所示)。
同时负责连接广州地铁AFC系统与城市一卡通清分系统,规定了对车票管理、票务管理、运营管理和系统维护管理的技术要求。
主要用于广州市轨道交通各条线路之间,与公交系统、银行系统及其他相关系统之间的清算分账、车票交易数据的处理及统计分析。
同时还具备对线路自动售检票(AFC)系统设备运营管理的功能。
远期定位于整个广州市及珠江三角洲城际轨道交通系统的清分中心和AFC运营管理中心。
方案选择和系统现状高可用性可选用的方案较多,如依赖于硬件的容错机方式、群集方式(双机或多机群集系统)、数据复制方式等。
广泛采用的群集方式(Cluster系统),其基本原理可以概括为:同一群集内的节点机所有关键业务数据存储于共享磁盘组,通常是磁盘阵列;故障节点被其它节点替换时,故障节点管辖的数据所在的数据设备(共享磁盘组的一部分)被接管;节点替换/接管的时机决定于集群内运行的监视软件;节点机上运行数据库管理系统,管理该节点机控制的设备上的数据;客户应用可以使用机群中的一个或多个数据库服务器。
节点机的替换意味着节点上运行的数据库管理系统进程的切换,这些过程是在服务器后台完成的,对于前端应用是透明的。
轨道交通领域自动售检票系统清分规则的研究-概述说明以及解释1.引言"1.1 概述部分:轨道交通领域的自动售检票系统是现代城市交通的重要组成部分,它能够提高乘客购票、检票的效率,减少人工操作的成本,更好地保障城市交通运营的安全和稳定。
在自动售检票系统中,清分规则是一个至关重要的环节,它关乎票务结算的准确性和公平性。
本文旨在研究轨道交通领域自动售检票系统的清分规则,探讨其在运营管理中的作用和意义。
通过深入分析,可以更好地指导实际操作,提高系统的运营效率和服务质量。
"1.2 文章结构文章结构部分应该包括对整篇文章的组织结构和各个部分内容的简要介绍。
具体内容如下:文章结构:本文主要分为引言、正文和结论三个部分。
其中,引言部分包括文章的概述、结构和目的介绍,使读者对文章内容有全面了解。
正文部分将详细介绍自动售检票系统的概述、清分规则的重要性以及目前存在的问题,通过对相关内容的分析和研究展开讨论。
结论部分将对整篇文章的内容进行总结,提出建议和展望,以及探讨实践意义,为读者提供深入思考和发展的空间。
整篇文章将以逻辑清晰、结构严谨的方式展开讨论,希望能够为轨道交通领域自动售检票系统的清分规则研究提供有益的参考和启发。
1.3 目的本文旨在研究轨道交通领域自动售检票系统清分规则,探讨其在提高运营效率、降低成本、保障安全等方面的重要性。
通过深入分析目前存在的问题,结合实际案例和数据,提出一套科学合理的清分规则,为轨道交通领域的自动售检票系统运营管理提供参考和借鉴,提升系统运行效果,提高服务质量,实现更高水平的管理。
同时,通过本文研究和总结,为相关行业的自动售检票系统管理者和技术人员提供思路和启示,促进整个行业的发展与进步。
2.正文2.1 自动售检票系统概述随着城市发展和人口增长,轨道交通系统已经成为现代城市重要的交通方式之一。
为了提高乘客出行的便利性和安全性,自动售检票系统被广泛应用于地铁、轻轨等轨道交通系统中。
详解地铁清分系统广州地铁自动售检票系统及其清分系统在实际运行中情况良好,系统达到了不间断工作的目标,为广州地铁的整个AFC系统提供持续稳定的服务。
随着信息化技术应用的不断深入,人们对计算机系统高可用性(High Availability)的要求不断提高,特别是企业基于数据库的关键业务系统,不仅希望保障关键业务数据信息的完整,而且希望联机应用能够不间断或者在最短的时间内自动恢复。
AFC系统及其清分系统简介广州地铁自动售检票系统(Automatic Fare Collection ,以下简称AFC)是基于计算机、通信、网络、自动控制等技术,实现城市轨道交通售票、检票、计费、收费、清分、管理等全过程的自动化系统。
目前,广州地铁自动售检票系统共分为车票、车站终端设备、车站计算机系统、线路中央计算机系统、清分系统五个层次(如下表所示)。
同时负责连接广州地铁AFC系统与城市一卡通清分系统,规定了对车票管理、票务管理、运营管理和系统维护管理的技术要求。
主要用于广州市轨道交通各条线路之间,与公交系统、银行系统及其他相关系统之间的清算分账、车票交易数据的处理及统计分析。
同时还具备对线路自动售检票(AFC)系统设备运营管理的功能。
远期定位于整个广州市及珠江三角洲城际轨道交通系统的清分中心和AFC运营管理中心。
方案选择和系统现状高可用性可选用的方案较多,如依赖于硬件的容错机方式、群集方式(双机或多机群集系统)、数据复制方式等。
广泛采用的群集方式(Cluster系统),其基本原理可以概括为:同一群集内的节点机所有关键业务数据存储于共享磁盘组,通常是磁盘阵列;故障节点被其它节点替换时,故障节点管辖的数据所在的数据设备(共享磁盘组的一部分)被接管;节点替换/接管的时机决定于集群内运行的监视软件;节点机上运行数据库管理系统,管理该节点机控制的设备上的数据;客户应用可以使用机群中的一个或多个数据库服务器。
节点机的替换意味着节点上运行的数据库管理系统进程的切换,这些过程是在服务器后台完成的,对于前端应用是透明的。
它主要可分为对称式(Active/Active)和非对称式(Active/Standby) 两种。
清分系统使用的是非对称式模式。
典型的非对称式的高可用性系统包括两台服务器, 一台是主服务器, 客户机从它存取数据和获得服务,另一台是备份服务器。
两台服务器通过心跳(Heartbeat)方式检测彼此的状态, 实现热备份。
当其中主服务器出现问题时, 后备服务器能够自动立即接替工作, 不会中断正常工作。
目前,清分系统配置2台Sun Fire 6800清分数据服务器,作为两个节点,以群集方式运行。
操作系统为Solaris 9,使用Sun Cluster 3.1群集管理软件。
在其中一台服务器故障时,另一台服务器能自动接管及运行所有的任务。
服务器配置外部磁盘阵列,磁盘阵列容量可扩展。
每台服务器均通过冗余的1000Mbps以太网口与中央以太网交换机连接。
数据库方面,清分系统使用的SybaseASE 12.5建立于Sun主机集群技术之上、面向分布式工作。
网络高可用性为保证网络连接的高可用性,清分系统的每台服务器均使用了两个千兆以太网卡用作对外连接。
在硬件安装好后,主要使用IPMP(IP Multipathing)来保证网络连接的高可用性。
它提供了一个基本机制,用于监视公共网络适配器,以及监视检测到故障时一个适配器到另一个适配器的失效转移IP地址。
在Solaris操作系统中,由in.mpathd后台进程负责故障检测,并根据不同的策略实现了故障转移和故障恢复。
检测物理接口的失败,in.mpathd所管理的主机系统的全部和部分网络接口组织成一个多路径接口组,其中的每一个网络接口分别赋予了测试地址。
在正常情况下,后台进程 in.mpathd不断地通过组中每个网络接口的测试地址向目标主机发送ICMP的ECHO包来检测相关网络接口的连通性。
其中,目标主机一般选为本网络的网关,如果网关不存在,那么,将选择网络中的主机作为仲裁主机。
在选择仲裁主机时,in.mpathd向网络上的所有主机发送multicast数据包,第一台返回响应数据包的主机将被认为是仲裁主机,此仲裁主机就是用来测试多路径接口组中网络连通性的目标主机。
在in.mpathd测试主机网络连通性的过程中,如果目标主机连续5次没有响应,in.mpathd认定相关连接已经失败,每次错误检测的缺省时间是10秒。
如果在多路径接口组中配置了备用网口,那么所有的网络访问将自动切向备用网络接口。
为了检测失败的网络接口是否已经被修复,in.mpathd不断尝试通过该网口的测试地址向目标主机发送检测包,如果能够连续10次收到响应数据包,那么in.mpathd后台进程认定该网口已经被修复,随后,所有被转移到备用网口的服务将自动恢复回原网口。
数据库的高可用性清分系统是7×24不间断运行的,所需的数据库服务是一种核心服务,它使用了Sybase ASE 12.5的高可用性产品,在系统故障发生时保证系统仍能正常运行,并将对最终用户的影响减少到最小。
Sybase故障切换产品使它能在具有双机配置的高可用性群集系统中工作,两个节点组合成协同服务器,每个节点或者是主协同服务器或者是辅助协同服务器。
主协同服务器故障或关闭期间,协同服务器便接管其工作。
此时进行故障切换,即把故障的或关闭的主协同服务器的数据库,元数据和用户连接移到辅助协同服务器以便用户仍然可以访问数据。
当主协同服务器可以重新运行时,用户可以执行故障恢复,将工作量移回原节点。
目前,Sybase ASE支持两种高可用性模式。
模式1—Hot Standby模式。
在辅助协同服务器上的ASE处于闲置状态,等待接管主协同服务器出现故障后的ASE。
它的优点是:易于管理,便于维护。
缺点就是只有一个服务器提供服务。
也把这种模式称为“主动—被动”架构。
清分系统为了方便管理,采用了这种模式。
模式2—分布式的工作负载。
它的特点是:集群中的节点可以同时访问磁盘,集群中两台ASE服务器可用于不同的应用系统。
优点是在同一时间,两台节点上的ASE都可以提供服务,其中一台都可以被配置成为另外一个服务器的接管服务器。
缺点:当故障发生时,性能将受到一定的影响。
这种模式也称为主动-主动模式。
无论在何种模式下,协同服务器对于客户端而言具有一定的透明性,客户端感觉只是一个统一的系统。
实现了自动的故障接管,但客户端必须重新提交在故障发生时刻尚未完成的事务。
在故障发生期间,一些ASE资源会发生转移:用户连接、数据库、数据库设备。
在故障发生期间,不会被转移的ASE资源包括:主协同服务器的高速缓存和其他内存中的资源、数据库配置参数、临时数据库 Tempdb。
因此,清分系统开发人员在设计和开发数据库相关应用时,需要考虑到上述因素。
对于数据库管理员,则需要为部分资源的切换进行相应的计划和配置。
包括:制定安全策略,定义没有交集的设备名称和数据库名称,选择需要发生故障切换的客户端。
故障切换期间,为保证具有故障切换属性的客户端自动重新连接,必须在interfaces 文件中增加标有“Hafailover”的行,以便为客户端连接到辅助协同服务器提供必要的连接信息。
我们可以使用文本编辑器或Sybase自带的Dsedit实用程序添加。
Sun Cluster系统的高可用性Sun Cluster管理软件是系统高可用性的核心, 它监视整个系统的硬件和软件的工作状况, 并在主系统失效时, 将事务切换到备份系统,对各种失效进行探测和有效的恢复。
软件实现要求保证系统正常工作, 避免本身可能存在的失效。
每个Sun Cluster系统是一组紧密连结的节点,提供网络服务和应用程序的单一管理视图。
Sun Cluster系统通过采用以下硬件和软件的组合实现高可用性:◆冗余磁盘系统提供存储。
群集中的所有节点还连接到公共网络,以使多个网络上的客户机可以访问该群集。
◆冗余热插拔组件使系统在硬件出现故障后继续运行,从而提高了可用性。
无需关闭运行系统,热插拔组件能够在运行系统中添加和删除硬件组件。
◆ Sun Cluster软件可检测节点故障,并将应用程序或服务移植到另一个节点。
Sun Cluster支持两种服务模式,第一种是失效转移数据服务:当故障发生时,系统自动将应用程序等资源从一个故障主节点上重新定位到指定的辅助节点,客户端可能会看到一个短暂的服务中断(一般为10秒),并可能需要在失败切换结束后重新连接,但客户端并不知道哪一个物理服务器向他们提供应用程序和数据。
做到了应用程序的冗余。
第二种是可伸缩数据服务:利用集群中的多个节点来同时运行一个应用程序,每个节点都可以提供数据和处理客户请求,这样既提供了高可用性,还提供了更高的性能。
目前,和数据库相配合,清分系统所使用的Sun Cluster配置为失效转移数据服务。
高可用性的日常管理日常运行中,如何知道系统高可用性正常运作呢?实际工作中可以定期利用系统空闲,用以下步骤进行:1.登录到控制Sybase ASE资源组的节点。
2.设置Sybase ASE 环境变量,这些环境变量是用户使用Environment_file扩展特性指定的变量。
3.检验Sun Cluster HA for Sybase ASE资源是否处于联机状态。
4.检查Sybase ASE日志以确定已发生的所有错误的原因。
5.确认用户可以连接到数据服务器并可以执行测试命令。
6.终止Sybase ASE数据服务器的进程。
7.将包含Sybase ASE资源的资源组切换到另一个群集成员,这一步能否切换成功是检验高可用性的重要标志之一。
8.登录到此时包含资源组的节点。
9.重复步骤3和步骤5。
要注意, Sybase ASE客户机连接在Sun Cluster HA for Sybase ASE切换后将断开。
如果发生了切换,则客户机与Sybase ASE 的现有连接将终止,并且客户机必须重新建立其连接。
切换后,重放Sybase ASE事务日志所需的时间决定了Sybase ASE的恢复时间。
在清分系统的实际运行中,高可用性故障问题的定位思路通常为先应用程序,再数据库,最后是操作系统,特别要注意查系统最近变更的记录。
高可用性故障主要表现为两类:一是Sun群集系统切换不成功问题。
这种情况一般是群集系统异常、群集切换脚本错误等原因导致。
问题的定位手段有:检查群集状态是否正常、群集之间网络是否正常,系统负荷是否过高;检查系统的进程是否正常,是否有很多僵死进程;检查群集软件的配置文件、群集脚本是否配置正确检查群集和程序文件属主、权限是否正确;检查群集数据库库配置文件是否一致。
二是Sun群集数据库异常切换问题。
这种情况一般是操作系统群集程序与数据库系统配置冲突的导致的。