线上环境使用了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顶不住。数据库应该也早挂了==
