1. 背景

搜索引擎是电商平台成交链路的核心环节，搜索引擎中的数据全部同步自各个业务系统。随着业务的发展，对接的系统逐渐增多，需要同步的数据量也日益庞大。现有同步系统采用定时全量同步的方式，同步一次数据需要8个小时的时间，已完全无法满足业务的需要。

数据同步作为搜索引擎的重要组成部分，有以下几个突出特点：

• 数据体量大：对接十几个上游系统，商品数量数百万
• 增量消息多：日常业务上下架频繁
• 实时性要求高：业务方通常需要新上架的商品能被尽快检索到

鉴于上述主要特点，本文详细介绍数据同步的改造方案。

2. 数据同步整体架构

正式介绍改造方案之间，需要对现有数据同步的整个架构有一个大致的了解。

2.1 数据同步体系运行流程

搜索引擎对接了十几个业务系统，不同业务系统的表结构、数量差异巨大。为了方便对接，屏蔽不同业务系统之间的差异，每个业务方创建一个视图，同步程序从视图中读取数据，进行相关数据处理之后，写入Elasticsearch集群。

在Elasticsearch集群中，同一个索引，会同时存在A库和B库。在同一时间，A库和B库中只有一个对外提供搜索服务，另一个库用于数据同步。在数据同步开始时，会先删除当前库中的数据，然后开始从视图中分批次读取数据，数据同步完成后通知前端程序切换数据库，进而可以搜到新同步的数据。因此，随着定时全量同步，A库和B库周期性地对调角色。

2.2 团队构成

搜索的运维体系，是一个相当复杂的构成，其中涉及很多团队的鼎力协作。

首先由各业务方提供底层源数据的支撑，然后搜索平台开发团队负责从源数据读取数据，并进行相关处理，写入Elasticsearch集群中。最后搜索引擎团队负责AB库周期切换，并对外提供搜索服务，供不同业务方调用。

3 治理方案

3.1 方案选择

当前的数据同步方案，缺点非常明显，没有扩展性，数据更新的延迟也比较高，占用多一倍的存储空间。***的数据同步方案是首次全量同步加增量更新的方式，实时性高，可以满足高并发场景的需求。

从MySQL数据库增量同步数据，需要解析MySQL的binglog，而MySQL中的视图是一种虚拟表，并没有binlog，因此无法通过视图直接增量更新。

一种改造比较彻底的方案是，各业务系统重新建立一张表，通过解析binlog来实现增量同步。这种方案有以下缺点：

• 所有业务方都需适配改造，不符合解耦的原则
• 部分业务上线时间长，重新梳理业务逻辑，需要花费较长的开发、测试时间，工作量较大

上述方案工作量大，改造时间长，为了适应线上业务的需求，还需要寻求更折中的方案。

通过分析整个同步流程时间开销，我们发现从视图读取数据耗时占了40%以上，同时在一个同步周期内，以串行的方式从各个视图同步数据，因此耗时较长的环节是优化的重点。

3.2 建立同步中间表

每个视图中都包含上百万条数据，一次读取全部数据，会带来比较大的网络和内存的开销，失败的风险较高，因此当前采取分批读取的方式。

分批次读取本质上是一种深翻页的操作，而且根据视图的原理，每次读取视图，都会重新计算关联表中的数据，这更进一步增加了数据库的压力。

为了缓解数据库的压力，编写MySQL存储过程，从视图读取全量数据，写入中间表。在同步开始时，同步程序调用存储过程生成中间表，然后从中间表读取数据。虽然深翻页的操作仍然存在，但避免了分批次读取时生成虚拟表的开销。

3.3 并行同步

串行改并行是性能优化中常用的手段。通过多线程的方式并行读取中间表的数据，并行写入Elasticsearch集群中。相应地，Elasticsearch集群的写入性能也要做出优化，例如调整refresh间隔，在此不再赘述。

3.4 应急预案

任何时候发现线上问题，首先需要快速止血，避免问题的扩大。建立同步工具，当数据同步出现故障导致数据更新不及时或者AB库逻辑错乱时，快速人工介入，手动启用同步工具，短时间内同步重点业务的数据，第一时间恢复线上业务运行。

4. 总结展望

本文主要介绍了数据同步系统改造的方案，主要从工作量、业务满足度、团队协调的复杂度来出发，制定合适的方案。通常情况下，最完美的方案，并不是***的解决方案。在方案落地过程中，会面临各种因素的制约，好的方案往往是妥协的方案。

上述方案落地后，数据同步时间从原来的8个小时缩短至1个小时，业务方感受明显。进步的空间还很大，系统优化永远在路上。