ElasticSearch数据的同步方案

一、方案背景

  当订单数据量规模足够大或查询统计足够复杂时，通常会采用MySQL + NoSQL的架构方案，这种方案需要将MySQL中数据同步到其它介质，比如ClickHouse、ES等。订单数据的同步面临着诸多挑战，尤其是异构介质，下面会从”数据同步面临的挑战“和以及”订单数据特点“两个维度来分析。

1.1考虑因素

1. 性能和稳定性： 订单系统为每个公司的核心业务系统，数据的同步尽量对订单系统无感，换言之，同步双写的方案会影响订单系统的性能和稳定性；
2. 幂等性： 同步RPC和异步消息，都可能产生重复数据，数据落入ES时需要考虑数据去重，保证幂等性；
3. 顺序性： 由于网络的不确定性，有可能数据库中先更新的数据后到达ES，导致最新的数据被旧数据覆盖；
4. 关联性： 通常订单数据会包含很多信息，库表设计时通常会进行垂直拆分，通过订单号进行关联，当进行数据同步时，如何处理这些关联表的数据需要考虑；

1.2 数据特点

1. 存量数据： 已完成或结束的订单归纳为”存量数据“，其特点是：数据量大、只读（没有变更，无需考虑顺序性）；
2. 增量数据： 未结束的订单归纳为”增量数据“，其特点是：并发量大、数据变更比较频繁（需要考虑顺序性）；

ElasticSearch数据的同步方案

MySQL数据同步到ES中，大致总结可以分为三种方案：

方案1：监听MySQL的Binlog，分析Binlog将数据同步到ES集群中。

流程如下：

• 给mysql开启binlog功能

• mysql完成增、删、改操作都会记录在binlog中

• 订单搜索服务基于canal监听binlog变化，实时更新elasticsearch中的内容

方案2：直接通过ES API将数据写入到ES集群中。 

     

基本步骤如下：

• 订单搜索服务对外提供接口，用来修改elasticsearch中的数据

• 订单管理服务在完成数据库操作后，直接调用订单搜索服务提供的接口

方案3：异步通知

 

流程如下：

• 订单管理服务对mysql数据库数据完成增、删、改后，发送MQ消息

• 订单搜索服务监听MQ，接收到消息后完成elasticsearch数据修改

考虑到订单系统ES服务的业务特殊性，对于订单数据的实时性较高，显然监听Binlog的方式相当于异步同步，有可能会产生较大的延时性。且方案1实质上跟方案2类似，但又引入了新的系统，维护成本也增高。所以订单中心ES采用了直接通过ES API写入订单数据的方式，该方式简洁灵活，能够很好的满足订单中心数据同步到ES的需求。

由于ES订单数据的同步采用的是在业务中写入的方式，当新建或更新文档发生异常时，如果重试势必会影响业务正常操作的响应时间。

所以每次业务操作只更新一次ES，如果发生错误或者异常，在数据库中插入一条补救任务，有Worker任务会实时地扫这些数据，以数据库订单数据为基准来再次更新ES数据。通过此种补偿机制，来保证ES数据与数据库订单数据的最终一致性。

1、实时性要求高的查询走DB

对于ES写入机制的有了解的同学可能会知道，新增的文档会被收集到Indexing Buffer，然后写入到文件系统缓存中，到了文件系统缓存中就可以像其他的文件一样被索引到。

然而默认情况文档从Indexing Buffer到文件系统缓存（即Refresh操作）是每秒分片自动刷新，所以这就是我们说ES是近实时搜索而非实时的原因：文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。

当前订单系统ES采用的是默认Refresh配置，故对于那些订单数据实时性比较高的业务，直接走数据库查询，保证数据的准确性。

2、避免深分页查询

ES集群的分页查询支持from和size参数，查询的时候，每个分片必须构造一个长度为from+size的优先队列，然后回传到网关节点，网关节点再对这些优先队列进行排序找到正确的size个文档。

假设在一个有6个主分片的索引中，from为10000，size为10，每个分片必须产生10010个结果，在网关节点中汇聚合并60060个结果，最终找到符合要求的10个文档。

由此可见，当from足够大的时候，就算不发生OOM，也会影响到CPU和带宽等，从而影响到整个集群的性能。所以应该避免深分页查询，尽量不去使用。

参考：

订单系统设计 —— 数据同步与监控 - 爱码网

有赞订单同步的探索与实践

大促突围：京东到家基于Canal的数据异构设计_架构_dbaplus社群_InfoQ精选文章

百度安全验证

京东到家订单系统高可用架构的迭代实战_老朱的技术博客_51CTO博客

MySQL 数据实时同步到 Elasticsearch的技术方案选型和思考_语言 & 开发_万凯明_InfoQ精选文章