mysql数据同步到es

线上环境使用了logstash做mysql和es的数据同步。数据量过大时。可能会出现同步延时的问题。

一般同步方案有三种：

1：logstash等工具同步

2：数据库ES双写

3：消息机制

第一种有点low了，第二种的话双写需要入侵业务代码。第三种最为合理

于是在码云上找了个*https://gitee.com/OrgXxxx/SyncMysqlToElasticsearch。本地起来试一下

首先项目下下来。

然后本地开启es服务

开启成功。

然后打开bin_log并设置为row模式

新建数据库表role: int id,varchar name

新建数据库表user: int id,varchar name

修改项目'binlog'的配置文件 由于本地没有搭kafka,就借用了公司的kafka。所以隐藏处理。数据库是私人的数据库 可以随便玩

项目'kafka'的配置文件 基本不需要修改。只用改一下kafka地址就可以了。

 

然后在数据库新增一条id=1 name=snnnn。查看es 发现新增成功

添加字段的话es无需修改 ，只需要修改json格式化模板即可，如user新增一个sex字段，需要修改pojo以及数据库 还有配置文件的消息格式化模板

此时在修改sex为2 后 观察es 发现修改成功

基本的使用是OK的。但是发现有以下问题

1：代码中还是存在硬编码问题，比如项目‘kafka’的JsonCoumer类中 对消息字段的处理是写死的。这种应该是可以根据消息体来解析出表结构的。而这个项目种表结构是通过配置文件配置的。业务发展中，表会不断扩张，每次修改表结构都去修改这个配置有点过于繁琐。其他的如getEsType方法 也是用switch,case写死了表。若有新增表的话，需要去修改业务代码，这个也不太合理。

2：这个消息中间件是kafka，消息是无序的。在表修改不那么频繁的情况下，可以换成rocketMq来实现，虽然可以通过主键id来辨别。但不排除有些业务场景对数据的顺序性要求很高。 但是我发现目前的同步机制好像很多用的kafka,我也不太清楚是为什么。rocketMq的量级虽然比kafka小。但是十万/s的量级应对mysql是足够的。如果rocketMq顶不住。数据库应该也早挂了==