公路客运服务向“互联网+”转型，在高并发压力下电子客票系统如何实现数据强一致性？

对于第二个问题：怎么解决互联网业务系统数据库层面的扩展能力问题，对于集中式和分布式是如何考虑的？

        分布式部署面临数据库容量飞速增长的时候，由于本身的处理能力等问题，往往是通过横向扩展，不断增加数据库节点，不断增加服务器和存储数量，随着业务的不断发展，将面临IT蔓延的情况，形成孤岛效应，另外这种部署方式随着业务的增长，复杂度呈现线性增长的趋势，越发不能控制。越来越高的客户需求将会演变为越来越分散的部署架构，随着Linux更多进入到关键业务领域，通过不断增加x86服务器的方式给企业的信息系统建设带来了越来越多的挑战：系统稳定性较差；纵向扩展能力的不足导致不得不采用分库分表等方式，带来了应用复杂度的急剧提升；大量的硬件采购、安装、更新换代及繁琐的硬件维护；软件和应用的运维管理难度增加；商业软件许可证费用的不断增加；灾备建设的难度增加；越来越多的安全隐患；系统利用率低下，投资回报率差。

       使用集中式部署，我们可以很好的实现数据库层面的扩展能力，同时降低复杂度，提升效率，节约成本。以IBMLinuxONE主机为例，多层级虚拟化技术帮助实现最为灵活高效安全的数据库部署，提供逻辑分区、虚机(z/VM&KVM)、容器(Docker)全面结合的多层级虚拟化能力。大型关键数据库可以直接部署在LPAR分区，赋予更接近硬件的资源调度及强大纵向扩展能力。众多中小业务应用或数据库可以部署在一个或多个z/VM或KVM虚机，甚至更轻量级的容器中，部署更加灵活，并实现各种负载的物理整合并提升利用率。所有Linux虚机或容器都可以通过HiperSockets虚拟网络或vSwitch进行内存级高速通讯，无需外部网络连接，更快捷、更稳定、更安全。利用先进负载优先级管理能力，确保关键应用在混合负载情况下的优先资源保障。还可以对分布在不同分区、虚机、及各个容器组的数据和应用进行有效隔离并实现高等级的安全保障。LinuxONE + Docker可以带来稳健更具扩展能力的Linux平台，更经济更简单的网络部署和管理，更强大的I/O处理能力，更安全的服务提供，容器模式及虚机模式的灵活结合。

        另外对于分布式平台使用更多节点，分库分表，使用内存数据库等方式平衡由于不断横向物理扩展带来的性能降低等情况，以LinuxONE为例，进行集中式部署可以避免类似的担忧。首先单核能力更强，四级缓存，最大10TB内存，专门负责处理异步I/O的协处理器使得CPU专注于业务处理，单机能够承载更多的数据库并且提供良好的性能和稳定性。其次使用业界最高安全等级的分区技术和主机虚拟化能力能够更好更安全的满足不断增加的业务需求而不需要不断增加物理服务器。另外主机HiperSocket基于内存级的通信技术，可以实现数据库分区之间、数据库之间、数据库和应用之间的高速数据传输和交换，避免了跨物理机的使用DBLink通信性能降低。这种通信方式的变化对于应用端完全透明，应用不会察觉到丝毫变化（与传统物理链路和IP网络通信相比）。由于它是基于内存的，并且以内存速度进行操作，所以能够大大降低通信连接两端的处理开销，降低网络延迟，提高终端用户性能，支持业务需求需要多次网络跳转的复杂应用系统。HiperSocket同时也带来安全方面的优势，特别是注重内存保护的主机上。同时，由于不需要网络集线器、路由器、适配器，甚至线缆，HiperSocket的传输方式提高了可靠性和可用性。

       如果使用分布式部署公路客票云系统需要考虑很多问题。传统的分布式部署对数据不一致性及耦合程度要求低，使用无共享分布式计算架构。这种架构中的每一个节点（ node）都是独立、自给的，而且整个系统中没有单点竞争。 无共享分布式架构通常需要将他的数据分布在多个节点的不同数据库或文件中（不同的计算机处理不同的用户和查询）或者要求每个节点通过使用某些协调协议来保留它自己的应用程序数据备份，这通常被成为数据库Sharding。 数据强完整性被限制在极小的数据库实例范围内，跨数据库使用复杂的应用进行补偿式的完整性确认与保障。无共享分布式数据架构下通过数据分裂来保证可用性和扩展性，但数据一致性无法保障。由于使用了读写分离，使用数据复制来形成多份数据拷贝，在只读数据上启用查询交易。业务对数据延时及一致性需要单独考虑。另外事务的支持有限，支持基于单库的事务，但不支持跨库进行事务。一旦业务需要跨库的事务处理，要么使用复杂的数据模型和应用逻辑来保障，要么使用昂贵的系统方法(降低其扩展能力)。无法处理局部热点。局部热点不会随着数据拆分而消失，另外拆分的数据平衡也是极其复杂的问题。开发的低效性。数据”分区”是非标准化的解决方案,只支持很基本的SQL操作.使用该方法将造成程序员开发的低效性和提高应用逻辑的复杂度。架构的独特性。独特的架构引入了维护与监控以及和其他商业软件的互联互通等一系列独有的问题。

        公路客票系统和其他客运系统一样，对于可靠性的要求非常高，分布式CAP理论证明在共享数据的分布式系统中的CAP特性中，最多只能同时满足两个。公路客票系统对数据完整性和一致性的刚性要求, 核心业务属于事务处理型交易，要求具备ACID特性，否则在事务处理的过程中无法保证数据的完整一致性。这也是为什么我认为不能采用分布式数据库,只能采用集中式数据库。分布式的思想是把鸡蛋放到多个篮子,篮子之间是软连接,集中式部署的思想是有限的篮子,但篮子间的连接相对强度较高.很重要的问题是要放几个鸡蛋。集中式部署在不断提高篮子的强度的同时通过先进的高可用和灾备等技术来规避鸡蛋放到同一个篮子的风险。分布式的设计思路是基于多种外部因素的可恢复,恢复复杂冗长.集中式部署的设计思路是内生的快速恢复的思路.比如系统升级。

针对问题1：电子客票系统怎么实现数据强一致性？

        公路客运订票作为特殊的服务与京东等购物网站极大不同之处在于，它对数据一致性、可靠性及实时响应要求很高。尤其是在没有大系统历史及运行经验的中国，且中国自身人口面积及市场又远超发达国家。在本质上，客票业务系统是以纵向计算扩展方式为主的综合性业务系统。为更好地支撑这样的票务系统，需要一个最为领先的基础架构，在出票量高达数10亿张的客运高峰期也能提供高安全、高可靠、高扩展、高数据一致性的架构支持。

        特别对于要实现实时性和一致性来说，在传统环境中，不同的数据库部署在多台数据库服务器上，相互使用过程中需要借助DBLink跨物理机访问本地的数据库中的数据，而各数据库有数据同步过程，存在数据丢失风险，已经不是实时数据，在经过DBLink跨物理机的远程访问过程，最终到达的数据实时性较弱，一些复杂的数据操作会出现延时，影响业务效率。使用集中式部署，采用纵向扩展能力强的基础架构技术来提高不同数据库镜像之间的数据交互效率，不同镜像使用同一份数据，保证数据的完全一致性和安全性，才能实现真正意义上的实时数据，无数据丢失，从而大大提高业务的实时性和数据一致性。目前大部分互联网，移动应用和数据库都使用开源Linux操作系统进行部署，而且从外围非关键应用快速走向关键和核心应用。要实现数据一致性和实时性，需要将多个分散部署的重要数据库基于Linux环境进行协同部署。

        公路客票云系统对信息的实时一致性要求决定了核心业务系统数据逻辑集中，使用共享式集群架构，将核心应用和数据库集中式部署到处理能力更强的基础架构上，这种部署支持跨多个业务线的紧耦合的大联机交易量的处理，它能够保证信息的实时的一致性；无需通过应用层跨系统的集成开销来保证数据和交易的一致性；由于紧耦合的数据可提供整个耦合的单一逻辑形象，可以说是做到了分享一切。应用不需要考虑跨不同数据库的完整性、恢复性等等，因此对于应用的开发人员来讲节省了许多集成层面和管理层面的烦恼。这种全共享式数据集中的紧耦合集群架构是一种既有SCALE OUT横向扩展能力也有SCALE UP纵向扩展能力的系统架构。接入层的各种前置终端设备和移动设备应用使用分布式部署，以提高终端的扩展能力和用户体验。

背景分析：

        对于公路客运这个行业来说，区别于传统购票方式，目前基于移动互联的多渠道购票对公路客运系统的并发能力提出了更高的要求，另外基于公路客运的多种服务需求，长业务链，运营跨区域等原因，要求能够保障公路客运系统的可靠性，我想这也是为什么这一问题涉及高并发和数据一致性两个方面。

         公路客运网络已形成了一个覆盖全国所有市、地、县、镇、村的庞大的旅客运输系统。公路客运占整体客运市场的比重高达87.5%，承载着超过190.82亿的旅客数量，堪称综合性交通市场的“龙头老大”。然而，与飞机、铁路等客运方式相比，公路客运服务存在着旅客信息资源利用率不足、票务服务智能化水平较低等问题。旅客需要在客运站通过人工售票的方式购买车票，既无法通过线上订购车票，也无法即时查询客车动态。

        另外传统公路客运业务系统架构面临的几个主要问题：首先多个业务系统（票务、清分、结算、统计分析）分散部署， 数据交互十分复杂；其次众多渠道接入，同样意味着要在多个站点平台之间进行复杂的数据交换和同步；另外多渠道网络化的客票服务、节假日的客流高峰，对系统负荷形成压力；

        各级公路客运车站设备已不能满足当下的发展需求，需要致力于全面提升票务服务、旅客服务和站务服务的智能化水平，借助新兴互联网技术推动公路客运服务的数字化转型是必由之路。

        基于国外的客票系统的实际案例和国内行业特点，我觉得可以使用基于IBM LinuxONE大型主机的基础架构进行集中式部署，整合中间件，数据库，以及前端开源应用的方法进行部署。LinuxONE电子客票云平台将主机内各分区，各虚拟机负载统一管理，自动快速部署，透明使用底层资源，满足各业务版本的快速更新和发布。

        逻辑上，可分为四层即接入层，渠道层，核心业务层和通用服务层。接入层可以选择性价比高，横向扩展能力强的X86服务器平台，作为前置应用服务器，根据服务半径，部署到相应地区以提供前置应用的最大化效能，提升终端客户的应用体验。其他层纳入到LinuxONE主机云平台进行管理，以实现后台数据的强一致性，实时性和统一管理。接入层包括手机，PAD，远程，网络，售票窗口，车站监控和一体终端等 。渠道层包括直销渠道服务，分销管理服务，联程票务服务，站务管理服务和登乘服务等。核心业务层包括核心订票，分销服务，联程服务，短信微信服务，登乘服务，清分清算，统计结算和支付服务等各种核心业务。通用服务层包括站务服务，系统监控，数据服务，通用交易，通用数据和通用消息等。各个子系统运行到主机上，通过主机的高处理能力，高内存，高带宽，以及均衡设计考虑的其他机制，保证所有的业务能够稳定运行，使用相同的数据库的同时保证数据的一致性，实时性，而不牺牲效率。而主机本身的PR/SM技术（EAL5+,商用服务器最高安全等级）实现动态负载管理，先进的资源调配能力和安全分区技术，各分区间内存级通信技术，结合 z/VM虚拟化能力，能够实现最大程度的混合负载安全可靠，最终实现统一的票务和信息服务平台，实现异地售票、联程售票和公众信息服务，提供互联网、电话、代理点、自助终端和移动终端等多种订购票渠道，方便民众出行、提高运行效率和行业监管水平，应用先进的信息技术实现道路客运联动管理、智能决策和旅客出行一体化服务 。

        物理部署上，接入层的乘客移动设备，客运站和其他终端联网设备通过IBM API 管理机制, DataPower 网关接入到渠道服务层，通过IBM HTTP SERVER反向代理机制保证前端访问的负载均衡，然后将请求转发至各渠道层子系统，比如通过渠道层的站务业务系统进行预定，确认，取消等各种操作, 之后统一接入到IBM WAS ESB（企业服务总线）， 在 IBM WebSphere Application Server 中配置MQ，实现WAS和MQ的高度整合，WAS的服务集成总线与 MQ 消息传递网络中的队列管理器之间提供直接连接。 MQ收集来自各种核心子系统的消息，比如触摸式设备子系统，支付相关子系统等，通过和WAS协作，实现统一管理。另外在主机分区上部署WAS集群，使用IBM Tivoli server management(TSM)实现多节点高可用，分区间通信使用Hipersocket实现内存级通信，提升各系统和数据的交互性能，而不像分布式部署需要跨物理器连接节点，使用网络设备，I/O性能大大降低。各核心业务子系统也同时部署相同的业务在各WAS节点下。通过WAS和DB2的连接，将数据请求传递到后端存储，DB2采用一主多从，利用IBM Cloud Manager云平台划分资源，数据同步，子系统有单独的也有共有的，保证数据一致性和高可用的同时，提升总体管理能力。这些部署的区别在于使用IBM原生解决方案能够实现最大的客户价值，另外主机自身的处理能力，高带宽，业界最高的四级缓存，最大10TB的内存和I/O协处理器等机制能够在大并发情况下实现快速响应。依靠主机内的分区和虚拟化技术以及Hipersocket内存通信等技术能够减少I/O瓶颈，实现多个业务系统稳定高效的进行数据交互，保持数据的强一致性和实时性，以确保票务、交易与现金流实时、准确；能在稳定、可靠的体系架构上灵活应对云服务业务的增长； 能够灵活调整资源，应对旺季、淡季及不同时段的业务量变化，以确保提供一致的服务水平。同时提供良好的出行体验，提高公路客运服务水平和运行效率，提升行业监管水平。未来，利用大数据技术基于主机所能带来的数据一致性和实时性的特点，通过部署在主机分区上的大数据应用能够提供及时有效的业务洞察力，提供一流的个性化服务。

针对问题3：电子客票系统服务器如何选型，应该考虑哪些方面的因素？

        先进的电子客票系统需要依托电子化、网络化和大数据化运营管理的技术优势和业务模式的创新，建立一个公路客运电子客票云服务系统，服务对象是一个省或区域内的各级公路客运站以及旅客群体，实现道路客运跨区域的多渠道网络售票、统一电子客票和数据管理以及综合智能决策的一体化服务，整合、共享道路客运信息资源，从而全面促进跨区域，大范围的汽车道路客运行业的现代化发展，大幅提高提升服务水平和管理能力水平，更好地为社会和旅客服务。作为后台核心系统要求具有高性能、高可靠性、高可用性和优秀的数据安全性，以及高可扩展性的优势，可以构建省级或者全国统一的票务和信息服务平台，实现异地售票、联程售票和公众信息服务，提供互联网、电话、代理点、自助终端和移动终端等多种订购票渠道，方便民众出行、提高运行效率和行业监管水平，应用先进的信息技术实现全省甚至全国道路客运联动管理、智能决策和旅客出行一体化服务，通过工程建设完善一套售票联网标准和规范。

        公路客运行业发展在迎接“互联网+”跨产业整合与大数据分析的转型的时候，需要在具备最高数据安全性、可靠性和可扩充性的系统上部署电子客票系统云服务，从而实现多个业务系统稳定高效的进行数据交互，保持数据的强一致性，以确保票务、交易与现金流实时、准确。能在稳定、可靠的体系架构上灵活应对云服务业务的增长；能够灵活调整资源，应对旺季、淡季及不同时段的业务量变化，以确保提供一致的服务水平。

        公路客票系统需要加大与大数据等新兴应用的融合，提供一站式综合服务、旅客个性化服务、一卡通等更为智能化的旅客服务。未来票务系统还需要打破地域的限制，毕竟公路不像航空和铁路很容易集中，需要进行标准化设计，实现不同公路客运站之间的互联互通，最终形成一个服务于全国公路客运服务市场的、高度可靠的网络系统是一大挑战，这就需要一个高扩展性的平台，这也应该是政府或者企业未来需要考虑的基础架构的长期战略。

        另外公路客运服务向“互联网+”转型，在高并发压力下电子客票系统为了实现数据强一致性，需要考虑很多维度，并发涉及到的基础数据量，系统支持的最大用户数，系统响应时间，服务器的吞吐量，关键请求的错误率，以及资源使用率等各项指标。

       中国公路每年出票量在14亿以上，若要建全国性的公路售票系统，这将比铁路系统大9倍。在互联网时代，其现在计算量巨大，系统查询不仅限于公路客票，飞机、铁路、酒店的查询都纳入其中。总之，现代化票务系统提供整套的出行信息，其数据量呈指数级增长。需要一个强健的IT基础架构方案能够提供满足中国市场特定需求的超大规模旅客电子客票系统的关键技术以及适合于铁路、城际、公路、水运等新一代综合的城际旅客出行解决方案。由于公路客运的区域性特点，如果公路客运系统是以省或者地区为单位，非全国公路客户系统，在底层设计上，一省票务系统出票量可达几十万，系统面临诸如清明、五一、端午、暑运、十一及春运等高峰期考验。省级系统一般跨地区几百个车站千公里的路线，且其查询量庞大内容范围复杂。这对系统实时响应、确认检订票满足大规模查询上要求极高。

        根据对公路客运行业背景的理解和分析，结合我们国家交通行业的业务特点，电子客票系统服务器选择集中式部署是未来整合各地区公路客运的必由之路，标准化建设各地客运系统，分步整合集中，不管是客运调配管理还是大数据应用，不会担心数据的不一致或者实时性问题。不管是银行业，公共基础等行业都是采用这样一个路线图，通过集中式部署能够更好的呈现业务。使用集中式部署的好处可以帮助公路行业客户更好的实现实时准确的提供多种订票渠道和异地售票、联程售票和公众信息服务，并实现“一步登乘”。提供良好的出行体验，提高公路客运服务水平和运行效率，提升行业监管水平。通过大数据分析提供及时有效的业务洞察力，提供一流的个性化服务；推进“一卡通”工作，在交通运输行业实行专业化和折扣化的定制服务，扩展至商贸、宾馆、旅游等领域；建立一站式综合服务，一站完成公路客运车票、火车票、机票、酒店订购；建立网上特色商城，提供地方土特产购物平台，一次购足，短时间送达。

         公路客运面临服务“大”“散”“乱”的挑战，需要对公路客运市场特点以及联网售票发展历程进行仔细调研，形成以服务客运车站为核心的、独特的全方位解决方案。IBM LinuxONE大型主机，能够为客户提供一个集高安全性、高可靠性、高可扩展性、高一致性及开放性于一体的领先架构。基于对Linux等开源产品的支持，结合IBM大型主机本身的优势，将推动新兴互联网技术在公路客运行业的落地，进一步提升公路客运的信息化水平。

1. 系统对数据强一致性有要求，就目前来看，仍是集中式架构更符合这个要求，分布式方案就不是很契合了。

2.高并发的话，前端的Web和中间件可以很容易靠负载集群的横向扩展能力来解决。但数据库就没那么好解决了，常见的思路有这么几个：数据库的读写分离，内存数据库、增加节点的的性能处理能力。但是能用内存数据库，读写分离分离的业务毕竟是少数，传统方式还是靠增加数据库节点的处理能力。不过客运其实可以采用这三种手段结合的方法来扩展性能，应对高并发场景。

3. 兼顾性价比的话，可以采用硬件负载+web和中间件使用x86服务器横向扩展+网络使用infoniband提高链路负载+数据库使用小型机集群负载+存储使用自动分层（全闪存+磁盘存储）的方式来设计，此外还可以引进一些流量分流和引导设备来对链路和运营商进行流量负载。

对数据有强一致性要求，那么显然分布式架构有CAP定理，需要在一致性和可用性上进行权衡。因此为了在架构设计中做到平衡，存储层仍然采用传统的集中式存储架构。

一般业务系统的瓶颈都会在IO层，那么我们可以灵活选用存储自动分层技术，通过加入闪存层，提升整体存储系统的性能。

另外时下流行的分布式存储解决方案不是特别成熟，如vsan在传统行业还不是遍地开花，同时官方也有6T容量的性能瓶颈考虑，所以传统的SAN存储架构依然大有用武之地。

服务器的选型，现在X86也是大势所趋，U2L也是愈发火热，而且X86的性能也很强劲，所以可以大胆尝试。用集群、虚拟化架构弥补不稳定性，无论是在成本上还是架构灵活性上都会有比较可观的成效。

应用层采用分布式架构应该没有问题，后端账务处理，目前分布式架构没有广泛应用，的确很多用户有数据强一致的顾虑，还需要有更多的应用场景给予支撑。

另外，在更多关注正常运行时候的性能问题的时候，也需要关注一下，当分布式节点发生问题的时候，对整个性能的影响。

厦门的E通卡，就可以解决上述问题。

大数据环境下如何进行客运调配管理