写点什么

4 个 MySQL 数据同步 Elasticsearch 的方案!

  • 2023-01-13
    湖南
  • 本文字数:1227 字

    阅读完需:约 4 分钟

4个MySQL 数据同步 Elasticsearch  的方案!

今天给大家介绍一个电商中常见的场景 —— MySQL 数据同步 Elasticsearch。


点击并拖拽以移动

编辑

商品检索

大家应该都在各种电商网站检索过商品,检索商品一般都是通过什么实现呢?搜索引擎 Elasticsearch。

那么问题来了,商品上架,数据一般写入到 MySQL 的数据库中,那么用于检索的数据又是怎么同步到 Elasticsearch 的呢?


点击并拖拽以移动

编辑

MySQL 同步 ES

1.同步双写

这是能想到的最直接的方式,在写入 MySQL,直接也同步往 ES 里写一份数据。


点击并拖拽以移动

编辑

同步双写

对于这种方式:

  • 优点:实现简单

  • 缺点:

    业务耦合,商品的管理中耦合大量数据同步代码

    影响性能,写入两个存储,响应时间变长

    不便扩展:搜索可能有一些个性化需求,需要对数据进行聚合,这种方式不便实现

2.异步双写

我们也很容易想到异步双写的办法,上架商品的时候,先把商品数据丢进 MQ,为了解耦合,我们一般会拆分一个搜索服务,由搜索服务去订阅商品变动的消息,来完成同步。


点击并拖拽以移动

编辑

异步双写

前面说的,一些数据需要聚合处理成类似宽表的结构怎么办呢?例如商品库的商品品类、spu、sku 表是分开的,但是查询是跨维度的,在 ES 里再聚合一次效率就低一些,最好就是把商品的数据给聚合起来,在 ES 里以类似大宽表的形式存储,这样一来查询效率就高一些。


点击并拖拽以移动

编辑

多维度多条件查询

这种其实没什么好办法,基本上还是得搜索服务直接查库,或者远程调用,再查询一遍商品的数据库,就是所谓的回查。


点击并拖拽以移动

编辑

回查完成聚合

这种方式:

  • 优点:

    解耦合,商品服务无需关注数据同步

    实时性较好,使用 MQ,正常情况下,同步完成在秒级

  • 缺点:

    引入了新的组件和服务,增加了复杂度

3.定时任务

假如我们要快速搞搞,数据量有没那么大,怎么办呢?定时任务也可以。


点击并拖拽以移动

编辑

定时任务

定时任务,最麻烦的一点是频率不好选,频率高的话,会非自然地形成业务的波峰,导致存储的 CPU、内存占用波峰式上升,频率低的话实时性比较差,而且也有波峰的情况。

这种方式:

  • 优点:实现比较简单

  • 缺点:

    实时性难以保证

    对存储压力较大

4.数据订阅

还有一种方式,就是最时兴的数据订阅。

MySQL 通过 binlog 订阅实现主从同步,各路数据订阅框架比如 canal 就依据这个原理,将 client 组件伪装成从库,来实现数据订阅。


点击并拖拽以移动

编辑

MySQL 主从同步

我们以应用最广泛的 canal 为例,canal 通过canal-adapter,支持多种适配器,其中就有 ES 适配器,通过一些配置,启动之后,就可以直接把 MySQL 数据同步到 ES,这个过程是零代码的。


点击并拖拽以移动

编辑

canal 同步数据

但是,和老板了解过,使用 canal 看起来很美好,帮我们把同步的事情都干了,但其实,还是要写代码。为什么呢?

前面提到的多张表数据聚合,canal 的支持没那么好,所以还是得回查。这时候用 canal-adapter 就不合适了,需要自己实现 canal-client,监听和聚合数据,写入 ES:


点击并拖拽以移动

编辑

数据订阅+回查

这种看起来和异步双写比较像,但是第一降低了商品服务的耦合,第二数据的实时性更好。

所以使用数据订阅:

  • 优点:

    业务入侵较少

    实时性较好

至于数据订阅框架的选型,主流的大体上是这些:

除了 MySQL 同步 ES,MySQL 同步到其它的数据存储,例如 HBase,其实大体上都是类似的几种方法。

用户头像

欢迎关注公众号:灵风的架构笔记 2022-10-21 加入

Java后端架构领域丨面题面经丨学习路线丨职业规划丨专业知识丨互联网资讯等分享

评论

发布
暂无评论
4个MySQL 数据同步 Elasticsearch  的方案!_Java_风铃架构日知录_InfoQ写作社区