干货 | 万字长文详解携程酒店订单缓存 & 存储系统升级实践

作者简介

荣华，携程高级研发经理，专注于后端技术项目研发管理。

军威，携程软件技术专家，负责分布式缓存系统开发 & 存储架构迁移项目。

金永，携程资深软件工程师，专注于实时计算，数据分析工程。

俊强，携程高级后端开发工程师，拥有丰富SQLServer使用经验。

前言

携程酒店订单系统的存储设计从1999年收录第一单以来，已经完成了从单一SQLServer数据库到多IDC容灾、完成分库分表等多个阶段，在见证了大量业务奇迹的同时，也开始逐渐暴露出老骥伏枥的心有余而力不足之态。基于更高稳定性与高效成本控制而设计的订单存储系统，已经是携程在疫情后恢复业务的必然诉求。

目前携程酒店订单系统正面临着在业务高增长的同时信息读写管理能力受制于数据库自身性能与稳定性的窘境。综合分析，一则为携程服役了十多年的SQLServer服务器集群的磁盘容量设计，已经跟不上时下新增订单量的空间诉求；二则在系统能力提升上造成了各大业务系统巨大的底层瓶颈与风险，同时又相比业界主流已基于MySQL架构设计存储系统而言，我们的订单存储系统仍基于SQLServer构建也整体推高了运营成本。

为了支撑未来每日千万级订单的业务增长目标，同时满足高可用、高性能、高可扩展的高效成本控制期望，我们为酒店部门的订单DB所有访问开发并落地了一套稳定且可靠的统一中间件封装方案，对现状收敛并提供了全局统一的热点缓存系统，彻底解决了当下订单上层应用与数据库间直连的方案缺陷。

新系统由中间件服务统一实现了对上层应用提供数据链服务，并达成了为现有依赖订单库的应用以及其他直接或间接的数据应用无感的实现存储底层由SQLServer向MySQL技术架构迁移的目标。

一、架构综述

通过对现有系统瓶颈的分析，我们发现核心缺陷集中在订单数据缓存分散导致数据各端不一致，各订单应用则与数据库直连又造成可扩展性差。通过实践我们编写中间件抽象并统一了数据访问层，以及基于数据库部署架构镜像构建了订单缓存统一管理热点数据，解决了各端差异。

图1.1  存储系统架构图

二、应用场景

2.1  新单秒级各端同步

从订单的提交到各端可见的速度为存储服务的核心指标之一，我们对数据链的主要环节进行了优化，覆盖了新单同步、消息实时推送、查询索引构建以及数据平台离线归档等主要环节，使大系统内数据到达速度在3秒以内，即用户刚下完单即可跳转我携列表可见。

• 当新用户创单时，同步服务作为数据链入口将用户订单数据通过中间件写入订单库，此时中间件同时完成订单缓存的构建；

• 当订单完成入库行为和热点数据构建后抛订单消息，实时输出给各子系统；

• 当新单入库完毕即刻构建订单明细信息的ES索引，为第三方提供检索支持；

• 最后数据平台T+1实施当日数据的归档供BI等各类离线业务使用；

图2.1 数据链

2.2  自动发单与工作台

对客、商、员工工作台三端的支持是订单存储系统的基本角色，图2.1数据链在新单提交后为自动发单与工作台起到的衔接作用功不可没。自动发单即在客人提交订单后，以最快的响应速度向商户发送订单明细信息进行核实货位、确认订单等流程。工作台则协助员工介入流程及时获取订单处理人工事件。

图2.2 基于存储系统的发单与工作台关系（缩略细节）

2.3  查询与数据分析

基于订单数据为核心的主要分为在线查询和数据分析两条业务线，以对详情查询为例，访问QPS终年保持在高位，每逢假期高峰则容易造成查询瓶颈，根因复盘后在本次架构升级中我们做了调整来优化相关场景的高可用性。

• 在线查询以订单缓存为主，订单提交即构建热点缓存纾解查询压力，并可按配置时间参数长时段有效。

• 非在线查询场景，以实时消息推送并结合Hive数仓T+1方式交付，凡需要长周期订单数据的场合（例如实时报表）均接入订单消息实时计算。离线BI按年度等大批量数据分析时使用Hive表，并每日凌晨低峰时段以从库低频访问的方式实施数据同步。

如此以上，我们将订单主库的访问保护在订单缓存、实时消息、Hive数仓三架马车之后，与业务尽最大可能的解耦。

三、系统升级实践 

在对携程核心存储系统进行更新换代的过程中，贯穿全程需要做到的是热迁移，并达成所有操作对数据链路上的各应用透明无损的目标。我们的设计通盘分析了集团数据链路的特性，由订单缓存系统提供数据库镜像降低应用与数据库的直连耦合，继而再通过中间件对应用透明掉数据源于SQLServer / MySQL的物理关系，提供底层热迁移的操作空间。

结合无损迁移的工艺设计，注重对每一笔数据库流量的可见及可控，支持全库、Shard级、表级、CRUD操作级的流量分配策略，提供了底层数据迁移足够的实施手段。数仓衔接设计则侧重于解决数据平台百亿级离线数据与双库在线期间的同步问题，以及解决全量接入MySQL期间产生的数据问题。

以下将分三个部分分享我们在这一过程中学到的经验。

3.1  分布式订单缓存

随着业务发展，用户数和访问量越来越大，订单系统应用和服务器的压力也与日俱增。在没有引入订单缓存之前，每个应用独立连接数据库，造成查询出来的数据无法在应用间共享，并且DB每秒查询量和连接数都有上限，而酒店核心交易链路基于DB存储，存在单点故障风险。

经过埋点数据分析，订单系统是典型的读多写少，为了共享热点查询数据以及降低DB负载，一个有效的办法就是引入缓存，如图3.1，用户的请求过来时，优先查询缓存，如果存在缓存数据，则直接返回结果；缓存没有命中，则去查询DB，根据配置策略校验DB结果数据，校验通过则将DB数据写入缓存留作后续查询使用，否则不写入缓存，最后返回DB查询结果。