方案一

利用es api实时写入es中

优点：实时性高，能灵活控制写入es的时间

缺点：同步方案与业务逻辑耦合，严重依赖于es api，破坏了原有业务程序逻辑

demo：https://blog.csdn.net/fanrenxiang/article/details/86509688

备注：实时同步的场景比较多，比如后台维护(CRUD)基础数据或者接口调用时候，把es同步写逻辑加入到之前的业务逻辑中，但是写入es这个操作还是要放到kafka这样的消息组件中，像kafka这样子的支持高并发消息读写的组件能较好的解决并发时候数据写入es的问题，这也是为了不影响原来业务逻辑接口响应。同步写入方案里要额外注意，有的时候写入es失败，要采取适当的写入重试策略，并失败的数据集，做好持久化记录，人工或定时任务补偿。

---

方案二

监听mysql的二进制日志，分析binlog将其同步到es中

优点：同步方案和业务逻辑解耦，没有任何关联，业务逻辑无需关系同步

缺点：二进制日志格式binlog_format必须为row，同时引入了新的同步服务，增加了额外的风险和运维成本

demo：https://github.com/siddontang/go-mysql-elasticsearch

备注：要做好同步服务的监听和报警机制

1.canal 监听binlog写入kafka  消费kafka消息写入ES

2.用river插件 写sql，定时同步到es

3.用logstash实现实时同步

---

同步方案技术选型要根据你的项目实际情况选择，如果你的搜索请求要求实时性高一些，由于监听mysql二进制日志的方案相当于异步同步，所以实时性相对同步写入会慢一些，所以可以考虑使用es api实时写入es的方案。

 上一篇: Elastic Search Java API（文档操作API、Query DSL查询API）、es搜索引擎实战demo