目录
ES查询数据库
数据同步方案
同步双写
异步双写（MQ方式）
基于Mysql的定时扫描同步
基于Binlog实时同步
使用canal监听binlog同步数据到es（流行方案）
canal原理：
数据迁移同步工具
Mysql业务数据库
核心特点：开源免费、高并发、稳定、支持事务、支持SQL查询
高并发：链接轻量化(线程模式)，优化器、执行器、事务引擎相对简单粗暴，存储引擎做得比较细致
一般用作上游数据源
ES查询数据库
核心特点：支持分词检索，多维筛选性能好，支持海量数据查询
文本搜索：基于倒排索引实现的搜索系统，文本模糊匹配搜索表现较好
多维筛选：亿级规模数据使用宽表预构建（消除join)，配合全字段索引，是的ES在多维筛选上具有压倒性优势
数据同步方案
同步双写
最简单的方式，将数据写到sql>mysql时，同时写到es中
优点：逻辑简单，实时性高
缺点：
异步双写（MQ方式）
适用于多数据源写入的场景，各个源之间写入逻辑互不干扰
优点：
- 性能高（相比同步双写）
- 不易出现数据丢失：MQ消息的保障机制，当ES宕机或写入失败，还能重新雄安飞MQ消息
- 隔离：多数据源之间相互隔离，能写入更多
缺点：
- 不适合实时业务场景，有延时（异步消费模型，写入的数据不一定能马上看到）
- 硬编码：接入新数据源需要编写新的代码
- 复杂度增加：引入了消息中间件
基于Mysql的定时扫描同步
解决了上面2种的硬编码问题（不用ES或者MQ代码）
实时性要求不高：定时器处理
- 数据库：m字段，任何curd操作都会导致该时间发生变化
- 原来程序的CURD操作不做任何变化
- 定时器程序，一定时间周期扫描指定表，该时间段内变化的数据提取出来
- 逐条写入到ES中
典型实现：
基于logstash实现数据同步，原理：定期使用sql查询新增的数据写入ES中，实现数据的增量同步。
优点：上面的+worker代码编写简单不需要考虑增删查改
缺点：
- 时效性差，固定频率刷新，就算秒级也是延时
- 对数据库有轮询压力，可以放到从库中
基于Binlog实时同步
解决上面的硬编码+代码侵入+延迟问题
binlog:binary log
步骤：
优点：
- 解决上面3个问题
- 性能高
- 业务解耦
缺点：
构建Binlog系统复杂
如果采用MQ消费解析的binlog消息，一样存在MQ延时的风险。
使用canal监听binlog同步数据到es（流行方案）
canal ： 根据sql>mysql的binlog日志进行增量同步数据
拓展:sql>mysql的主从复制原理
- 所有create update delete操作都会进入sql>mysql master节点
- master节点会生成Binlog文件，每次操作Mysql都会记录到Binlog文件中
- slave节点会订阅master节点的binlog文件，以增量备份的形式同步数据到slave数据
canal原理：
伪装成sql>mysql的从节点，订阅master节点的binlog日志：
- canal服务端向sql>mysql的master节点传输dump协议
- sql>mysql的master节点接受到dump请求后推送binog日志给canal服务端，解析binlog对象（原始weibyte流）转成Json格式
- canal客户端通过TCP协议或者MQ形式监听canal服务端，同步数据到ES
数据迁移同步工具
参考：【技术选型】Mysql和ES数据同步方案汇总-腾讯云开发者社区-腾讯云 (tencent.com)
