上篇文章介绍了 ES 的基本概念：Elasticsearch（一）。
对于 ES 来说，必须先存储有数据然后才能搜索到这些数据，而在实际业务中 ES 的数据也常常是与 mysql 保持同步的，所以这里插入这篇文章简单介绍几种同步 mysql 数据到 ES 的方式。
一、业务层直接同步：
最常见就是直接在业务代码层比如操作数据库的 ORM 中定义各种 hooks 钩子，然后在钩子里再进行 ES 的数据操作，其实这里 ES 和 DB 并没有直接关联，而这种方式的缺点就是 ES 的操作会过于分散在各个业务里，不利于扩展和管理。
当然某些情况下，系统中会设计一个数据代理层，专门集中负责有关数据的操作，这时 ES 的数据同步也会自然放到这层，但是仍然将其视为一类好了。
二、独立同步：
区别于上一种，这种方式将 ES 同步数据部分分离出来单独维护，此时业务层只负责查询即可。
如上图所示，这种方式会等到数据写入 DB 完成后，直接从 DB 中同步数据到 ES ，具体的操作又可以细分为两类：
1、插件式：
直接利用第三方插件进行数据同步，缺点是灵活度受插件限制。常用的插件有
logstash-input-jdbc go-mysql-elasticsearch
2、脚本式：
自己写脚本，比较灵活。
最简单的比如定时轮询 mysql，根据表中的最后更新时间这个特殊字段去新增或修改 ES 的数据，但是对于删除数据则需要另外处理，当然也会有某些情况下是不存在删除操作的。
更推荐的方式是通过订阅 mysql 的 binlog 日志从而实时同步数据，在 NodeJS 中推荐使用 zongji 这个库。由于特定的场景，我更关注的点是哪个数据库的哪张表进行了插入、修改、删除操作，所以在 zongji 的基础上我自己稍微修改了一点并过滤了一下返回结果：
如上图所示，通过指定具体哪个库哪些表的增删改操作进行订阅，返回结果就会过滤掉不相干的数据，并且所有返回结果都包含以下四个维度的数据：具体哪个数据库、具体哪张表、进行了增删改哪种操作，操作的数据又是什么。
当然这只是一个 demo 版，感兴趣的可以试试。
本篇完。
