比如我从酒店的官网或者OTA订了一间房，收到了预订确认信息；我到了酒店前台，前台查找到了我的预订信息，成功办理了入住，我对酒店是否快速的帮我办理了入住非常在意，但大多数人都不知道，这张订单，是怎么到达酒店前台的。
今天，我们邀请石基畅联副总经理Helen和石基畅联研发副总监White和我们一起，解读订单背后的秘密。
日均处理数据量过亿，等同于一个350G 内存硬盘的容量，相当于每分钟处理60000条 数据。
这就是一张订单和万千订单传输背后的秘密，也是石基畅联正在做的事情。
“可以说，这10几年来我们只在研究一件事情，就是怎么把一张订单高效、稳定而且准确的在系统之间进行传输”。石基畅联分销解决方案副总经理葛奕霞如是说道。
01. 怎么让车在酒店和渠道之间的这条高速公路上跑起来？
酒店管理集团和渠道之间，存在一条高速公路，这条高速公路就是畅联提供和打造的。
跑在这条公路上的车是什么呢？就是各种ARI（Availability, Rate and Inventory）即产品可用性，房价和库存数据、还有订单相关信息，如客人预订信息、所选酒店房型、抵离店日期等等。
不堵车。数据多了，就像车多了一样，自然会有拥堵的风险。拥堵一旦产生，必然面临数据传输不通畅的问题，也就意味着，客人的订单没有办法传输到酒店，出现客人到了前台“查无此预订”的问题。
不迟到。一旦拥堵，也面临着“迟到”的问题，比如酒店的价格、房态信息变化频繁，一旦发生拥堵，这些信息不能及时到达OTA平台，就会给客人展示不准确的价格和可用性，影响客户体验。
畅联的使命，就是让这条高速公路，无论承载多少的车，都不发生拥堵，不发生事故，让所有车辆及时、安全的抵达终点。
要解决这个怎么办的问题，首先需要理解酒店集团CRS和渠道平台与畅联发生交互的方式。畅联能够与酒店集团以多种方式发生数据交互，比如Push， Pull，CDS， Hybrid等方式。
以Pull模式为例，畅联会从酒店管理集团CRS系统里面把数据Pull过来，与畅联平台上缓存数据进行比对之后，再Push给各个渠道进行发布。
这是什么意思呢？简单来说，Pull就是拉取所有数据，不管这些数据变了还是没变，跟缓存数据一对比，没有变的数据保持不变，一旦发现有些数据发生了变化（比如价格变了，可售卖的客房数量变了），畅联会把这些“变了的数据”主动Push给各个渠道平台进行发布，至于没有变化的数据，就已然保持原样，不进行二次的数据处理了。
“要保持整套系统的高效稳定，离不开完善的技术支持，运营支持和人员支持。”葛奕霞说，“过去两年我们对畅联平台进行了全面重构和升级，采用了分布式架构，提升数据传输效率；监控和预警系统的应用提升了运营服务水平，效果非常显著。”
畅联如今与超过23000家酒店和200多个渠道实现了直连，日均处理数据量接近亿级，订单成功率从2016年的92.7%提升到了2019年的98.3％，这是平台重构后最直接的结果体现，也意味着酒店和渠道之间通过畅联的平台能够更好的实现ARI和订单信息的“上传下达”。
02. 怎么解决”不堵车“的问题？
“有了强大的技术保障，运营所面临的各种压力便迎刃而解！”石基畅联研发副总监王培贤这样来强调技术作为依托的重要性。
分布式架构
我们再来回顾一下刚才说的高速公路。在程序设计方面，目前畅联采用的是负载均衡＋高扩展的分布式架构。也就是说，整个系统是基于阿里云SLB，数据传输不再是通过单一服务器，而是不同的ECS节点。
这些节点，有两个特点：
◆ 能够随时随地无限扩容。
也就是说，公路有2个车道，基于分布式架构，我可以随时把车道扩展为3个、4个、5个、6个，或者更多，没有限制，而且非常容易就可以实现。
这点不同于此前单一服务器，一旦堵死，再去扩容就是很麻烦的一件事情了；而且一旦发生宕机，就会直接影响到交易；有了很多节点意味着我们就不依靠于单一的服务器了。
◆ 这些ECS节点还很智能。
一旦某个节点数据比较多，它还会自我均衡，把多的数据分配到不那么繁忙的“车道”上去。
这样一来，大量数据带给服务器的压力会极大程度上减少，压力少了之后，数据这些“小车辆”在公路上跑的自然会更快，更通畅。
ARI数据和订单类接口池单独管理
此外，要把不同类型的数据接口池分开管理。总的来说，预订数据分为订单数据和ARI数据两类。ARI数据同步则非常庞杂繁复，特别容易发生瞬时过载的情况，相当于陆路交通中名目众多的各类车辆。订单数据则相当于一架架飞机，对数据传输的及时性会有更高要求。因此，畅联为这两类数据提供了分别部署通道，也就是说，陆运和空运通道互不干扰，以确保ARI数据高效传输，同时保证订单数据的快速及时传达。
海外项目数据传输的“特别通道”
海外项目的数据传输效率受国际网络通讯速度影响较大，为了确保这部分数据同样可以高效率的上传下达，畅联部署了MPLS专线，相当于高速公路上的一条跨海大桥，畅通往来。
采用多种高效缓存，更快匹配数据信息
刚才提到了畅联需要从酒店集团CRS系统中Pull出所有的相关的数据信息。这些数据要区分哪些是“没变的”，哪些是“变化的”，再推给渠道方。如何更快速的识别“没变的”和“变化的”数据信息，高效缓存对于解决不堵车的问题，也很关键。因此，畅联采用了多种高效缓存的模式，以便更快匹配数据信息。
此外，巨量的Mapping数据，原先在每台服务器内存中都有N份，造成了资源的浪费和更新的困难，现在采用缓存池进行集中管理和维护。
解决了不堵车的问题，还要进一步加强道路规范，确保车辆行驶的安全有序。这就需要更为智能的落地解决方案。
03. 开启智能落地新时代：高效部署管理
ZooKeeper集中部署，让我们的高速公路快速建成、车辆行驶有序。
如同要修路一样，除了要有钢筋、水泥等原材料，划线、设标这样的措施能够进一步确保车辆的行驶有序。
酒店集团和渠道之间的这条通路也是一样，程序集中部署就是实现道路速成，且质量过硬；“参数配置”则相当于给道路划线、设标。每条车道都需要“参数配置”，给这么多条车道一个一个地配，已经是过时的做法了。
畅联采取的是ZooKeeper集中管理模式，可以实现在N台分布式服务器上一键部署，极大节省人力，并显著提高程序部署及未来升级的效率。这是开启智能落地新时代的重要体现。
智能落地新时代的另外三个重要体现，分别是智能设定和调整落地频率、削峰填谷和项目监控与预警。
程序智能调节，实现热点酒店高频更新，低产酒店低频更新，以加速系统运行
ARI数据庞杂而繁复，从源头上，如果能够筛选出有效ARI数据并及时同步到渠道，同时最大限度缓解服务器压力，这样的智能落地意义深远。“我们会根据项目需要来实现智能调节，科学分段设定ARI数据落地周期与落地频率。”王培贤说，“使热点酒店ARI数据更新频率更及时，同时降低低产量酒店对资源的无谓占用。 ”
削峰填谷，优化服务器资源配置
高峰时段道路拥堵的痛苦相信大家都感同身受。尤其是在ARI数据交互时，畅联的这条高速公路也曾面临“堵车”的风险。
然而，畅联的智能落地程序，通过科学合理的运算，尽可能平均了各个时段对酒店集团ARI接口访问，实现对资源的最大化利用，令畅联这条高速公路不再出现波峰和低谷，数据流缓和而稳定，没有拥堵。
监控+预警，防患未然
“我们可以根据不同项目的不同服务类型，设定预警阈值，一旦监测到任何异常，系统会通过邮件或微信的方式第一时间通知相关人员，来判断是否需要采取措施。”葛奕霞说。
这相当于给数据这辆车装上了“预警”系统。我们和用户可以在第一时间知道，车子哪里可能会出问题，从而规避风险，避免损失。
比如在某一时间段ARI数据总量通常为10万，设置预警阈值之后，当这一时段数据总量明显低于预警阈值时，系统就会自动发送预警通知，畅联运营人员即刻需要深入探究原因，并解决出现的问题。
同理，订单量、成功率等等，都可以设定预警阈值，一旦过低或者过高，都可以及时发现并做相应的处理。
ELK日志管理新工具也是我们平台重构的重要组成部分。
这与减轻生产服务器压力，提升团队对客响应速度直接相关。畅联为每一位用户都安排的客户支持经理，客户支持经理的职责就是帮助用户解决在日常运营中出现的各种大小问题。
以往，支持经理往往需要通过查询日志来定位问题，而要从海量的日志里找到真正我们需要的那一条，是需要大量的运算和检索，对生产服务器带来的压力可想而知，这势必会影响服务器的运行效率，进而影响业务数据交互。
现在畅联采取了ELK集中存储和查询日志的方式，将所有数据交互日志从生产服务器上单独剥离进行集中化管理。生产服务器再也不会因为大量的日志存储和查询而出现性能问题，同时我们支持经理对用户的响应速度也大幅提升。
04. 从92.7%到98.3%的跨越
经过两年的重构与升级，畅联实现了订单成功率从92.7%到98.3%的跨越，不断兑现着对用户的承诺。
“除了上述这些技术、设备等方面的保障以外，我们认为人性化的互动和关怀也是必不可少的。”葛奕霞这样说道，“我们的运营团队随时准备着为用户解决任何在运营层面上的问题，无论大小。从利用数据分析工具，定期与客户分享各项目的前情、现状和发展趋势，到事无巨细的运营支持，我们致力于帮助用户发现问题、解决问题，并对用户未来的业务发展提供支持和思路。”
运营无止境，往往由点滴开始，以量累质，最终实现跨越式发展。这离不开对用户需求的理解、对技术的持续投入、对人员专业性的不断提升。我们从这里，窥见一张订单背后的秘密，看似简单，却倾注心血，只为更美好的旅程。
