干货 | 数据库压力降低90%，携程机票订单缓存系统实践

作者简介

 

Chaplin，携程资深PMO，平时喜欢解决系统相关的问题，包括但不限于分布式/大数据量/性能/体验等，不畏复杂但更喜欢简单。

本文旨在分享携程机票后服务订单处理团队，在构建机票订单缓存系统过程中的一些思考总结，希望能给大家一些启发或帮助。通篇分为以下七大部分：背景，瓶颈，选型，架构，方案，优化，总结，文章概要如下图：

一、背景

近些年随着携程机票业务的不断发展，用户量和订单量也稳定地增长，再加上用户访问入口的多样性、机票的有效期特别长等特征，导致查询流量不断增长。这些，给基于强依赖订单数据库的订单查询系统带来了不小的压力。

不仅业务上带来的流量压力，技术改造也带来了更多的流量，如微服务化的推进、机票前后台订单业务解耦，不可避免地使得订单查询系统被依赖程度进一步提高。而且我们没有使用类似GraphQL 的技术，之前的前后台服务直连数据库，现在使用查询API，没有高度定制化产生了数据冗余，带来额外的查询压力。

 

作为典型的用户订单详情查询服务，承受着越来越重的压力，峰值时期订单详情查询QPS数倍于同期订单TPS。

为了保障用户的使用体验，支持机票业务的持续发展，保证机票订单查询系统的稳定高效，构建和不断升级机票订单查询系统，自然成为重要且紧急的事情。

 

二、瓶颈

大部分应用系统的瓶颈都会出在比较慢的地方，如外部资源及磁盘IO或数据库，订单系统的瓶颈显而易见，重复高频的订单数据访问，最终带来的是订单数据库访问的压力。

尽管之前通过数据库主从复制、读写分离的手段，一定程度上缓解数据库的压力。但是从节点的增加无疑会带来一些不得不考虑的问题，包括数据同步时的AG延迟问题，数据库服务器的运维成本等。

不仅局部优化有瓶颈，而且我们一直认为局部的优化，不如总线级别的优化来的更有效率，数据库总线跟内存总线对于订单系统数据存取速度的提升并不是一个级别。

基于以上种种，机票订单后处理团队，决定构建一套相对完整的基于内存数据缓存体系，不仅用于缓解机票订单数据库的访问压力，也用来提高订单查询服务的稳定性和容灾能力。

 

三、选型

目前各种类型的缓存都活跃在成千上万的应用服务中，还没有一种缓存方案可以解决一切的业务场景或数据类型，我们需要根据自身的特殊场景和背景，选择最适合的缓存方案。

目前业内用来做缓存的，通常主要有以下几种：Memcache、Redis，MongoDB。关于几者的优劣对比网络上也有不少的相关文章，这里不再详细列举。

选型并非是一个固定不变的标准，虽然系统设计没有银弹，但是路就在脚下，我们必须要结合自己的业务场景及运维能力做出综合判断（取舍），这里说明一下我们关注的点。

（1）故障快速恢复，机票订单的查询服务面临的QPS较高，又是许多上层应用服务的依赖项，由于业务比较核心，所以数据安全问题必须考虑。因此第一要求故障快速恢复，携程的Redis部署是多组多实例多机柜，完全满足需求。

（2）性能要好，机票订单数据的查询，超过92%的场景都是根据订单号的查询ÿ