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

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

        分布式部署面临数据库容量飞速增长的时候，由于本身的处理能力等问题，往往是通过横向扩展，不断增加数据库节点，不断增加服务器和存储数量，随着业务的不断发展，将面临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特性，否则在事务处理的过程中无法保证数据的完整一致性。这也是为什么我认为不能采用分布式数据库,只能采用集中式数据库。分布式的思想是把鸡蛋放到多个篮子,篮子之间是软连接,集中式部署的思想是有限的篮子,但篮子间的连接相对强度较高.很重要的问题是要放几个鸡蛋。集中式部署在不断提高篮子的强度的同时通过先进的高可用和灾备等技术来规避鸡蛋放到同一个篮子的风险。分布式的设计思路是基于多种外部因素的可恢复,恢复复杂冗长.集中式部署的设计思路是内生的快速恢复的思路.比如系统升级。