干货 | 携程度假商品千亿日志系统架构演进

作者简介

cd，携程资深后端开发工程师，度假商品系统研发，专注于后端系统性能提升。

团队热招岗位：资深后端开发/专家、资深后端开发-商品后台

在携程旅游度假的线路类商品系统中，由于商品结构复杂，涉及底层数据表上千张，在日常供应商以及业务维护过程中，每日产生6亿+的数据变动记录。这些数据的变动留痕，不但可供录入方查看，也对日常产研的排障起着至关重要的作用，同时也可以提供给BI做数据进一步分析。商品日志系统建设尤为重要，随着商品日志系统不断发展迭代，已经积累达到1700亿条日志。

本文将介绍线路商品日志系统的演进过程以及在其中遇到的问题。

• 一、发展轨迹

• 二、演进过程

• 2.1 V1.0 DB单表存储

• 2.2 V2.0 平台化

• 2.3 V3.0赋能

• 三、结语

一、发展轨迹

线路商品日志系统的发展大致可以分为以下三个阶段：

2019年以前：单表日志

在 2019 年以前，商品系统尚无统一的日志系统来记录商品的变更，在系统中使用DB日志表，该表以非结构化的方式记录商品基本信息的变动。

2020年~2022年：平台化

在系统改造过程中，建立统一的商品系统日志平台，通过配置的方式记录商品的数据变动日志，覆盖商品维护的全部流程。

2023年~2024年：开放

经过在线路商品系统的实践，商品系统日志平台经历百亿级数据的考验，并以灵活的配置方式记录数据变动日志，同时支持自定义索引字段，具有接入和使用成本较低的优势。为此，通过对商品系统日志进行改造，逐步向门票、用车等业务线开放使用。

二、演进过程

2.1 V1.0 DB单表存储

在2019年以前，记录线路商品的变动日志较为简单，在DB中建立一张日志表（id,LogContent）来记录日志，数据变动以非结构化的文本记录在LogContent字段内，且仅覆盖商品最基本的信息，在使用时通过数据库查询工具执行sql语句like关键字进行查询，这种方式带来的问题也显而易见：

• 数据量大，性能低

由于是单表文本字段存储，导致表的数量非常巨大，达到单表10亿+（370GB）的数据，查询超时问题严重，不得不进行定期归档。

• 可读性差，仅开发人员使用

由于日志内容以文本字段存储，在进行日志查询时，一般由开发人员使用 like 语句直接查询 DB，例如：select id, LogContent from log where LogContent