ES数据同步方案

ES数据同步⽅案
当业务量上升后，由于mysql对全⽂检索或模糊查询⽀持的能⼒不强，在系统中查询的地⽅，往往会出现慢sql等，拖累系统其他模块，造成性能低下。

随着ES使⽤普及率的升⾼，ES是mysql的⼀个有效补充。

我们可以将数据发送到搜索引擎（如ES）上，由搜索引擎来提供专业的服务。

接下来，就结合⼯作中实际⽤到的场景，对数据从mysql到es的同步进⾏⼀些分析。

在实践中我总结出了以下⼏种⽅式。

第1种：同步双写
这是⼀种最为简单的⽅式，在将数据写到mysql时，同时将数据写到ES，实现数据的双写。

优点：
业务逻辑简单。

缺点：
硬编码：有需要写⼊mysql的地⽅都需要添加写⼊ES的代码；业务强耦合；存在双写失败丢数据风险；性能较差：本来mysql的性能就不是很⾼，再加写⼀个ES，系统的性能必然会下降。

说明：
上⾯第3点讲到的双写失败风险，包括以下3种：
ES系统不可⽤；应⽤系统和ES之间的⽹络故障；应⽤系统重启，导致系统来不及写⼊ES等。

针对这种情况，有数据强⼀致性要求的，就必须双写放到事物中来处理，但是⼀旦⽤上事物，则性能下降更加明显。

第2种：异步双写（MQ⽅式）
针对第⼀种同步双写的性能和数据丢失问题，可以考虑引⼊MQ，从⽽形成了异步双写的⽅案，如下图所⽰：
由于MQ的性能基本⽐mysql⾼出⼀个数量级，所以性能可以得到显著的提⾼。

优点：
性能⾼；不存在丢数据问题。

缺点：
硬编码问题：依然存在业务强耦合：依然存在复杂度增加：系统中增加了mq的代码，；可能存在时延问题：程序的写⼊性能提⾼了，但是由于MQ的消费可能由于⽹络或其它原因导致⽤户写⼊的数据不⼀定可以马上看到，造成延时。

第3种：异步双写（Worker⽅式）
上⾯两种⽅案中都存在硬编码问题，也就是有任何对mysq进⾏增删改查的地⽅要么植⼊ES代码，要么替换为MQ代码，代码的侵⼊性太强。

如果对实时性要求不⾼的情况下，可以考虑⽤定时器来处理，具体步骤如下：
数据库的相关表中增加⼀个字段为timestamp的字段，任何crud操作都会导致该字段的时间发⽣变化；原来程序中的CURD操作不做任何变化；增加⼀个定时器程序（京东内部叫Worker），让该程序按⼀定的时间周期扫描指定的表，把该时间段内发⽣变化的数据提取出来；逐条写⼊到ES中。

⼊下图所⽰
优点：
不改变原来代码，没有侵⼊性、没有硬编码；没有业务强耦合；不改变原来程序的性能；Worker代码编写简单不需要考虑增删改查。

缺点：
时效性较差，由于定时器⼯作周期不可能设在秒级，所以实时性没有上⾯2中好；对数据库有⼀定的轮询压⼒，⼀种改进⽅法是将轮询放到压⼒不⼤的重库上。

第4种：Binlog 同步⽅式：
上⾯三种⽅案要么有代码侵⼊，要么有硬编码，要么有时延，第4中⽅案，可以利⽤mysql的binlog来进⾏同步
具体步骤如下：
1）读取mysql的binlog⽇志，获取指定表的⽇志信息；
2）将读取的信息转为MQ；
3）编写⼀个MQ消费程序；
4）不断消费MQ，每消费完⼀条消息，将消息写⼊到ES中。

优点：
没有代码侵⼊、没有硬编码；原有系统不需要任何变化，没有感知；性能⾼；业务解耦，不需要关注原来系统的业务逻辑。

缺点：
构建Binlog系统复杂；也像⽅案⼆，存在MQ延时的风险。