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