1、如何保证MySql到ES的数据一致性？
答：ES是一个开元分布式搜索和分析引擎、它提供了全文搜索、结构化搜索分析以及这些组合的能力。
- 全文搜索能力：ES支持复杂的搜索能力，包括模糊匹配、短语查询、布尔查询等，并且可以快速的返回结果
- 实时数据分析：实时数据分析，支持对数据进行复杂的统计分析，如计数、求和、平均值、最大值、最小值等，这对于业务的分析非常有作用
- 扩展性强：ES的分布式架构可以轻松的横向扩展到数白甚至数千台服务器节点，处理PB级的数据量；通过设置副本分片，确保数据沉淀、避免单点故障；
- 灵活的数据模型：Es使用Json格式来存储数据，这种格式对于现代应用程序来说，非常的友好，易于理解和操作，你可以自定义映射来规范文档结构；同样也允许你自由的添加新字段，无需预先定义模式；
- 强大的插件生态系统：最熟悉的可能就是Kibana，它是官方提供的可视化界面，提供了一个友好的用户界面，用于搜索可视化和管理ES中的数据；还有其它的一些插件，它们可以帮助收集解析和传输数据到ES;
- 使用多种应用场景：日志和事件数据分析；电子商务中的相关搜索；安全信息和事务管理等各种大数据量的情况下的使用。
所以ES这个中间件非常适合在“数据量特别大”的情况下，特别还设计到“分库分表”的这种业务场景下的使用。但是引入新的中间件也有需要注意的挑战；
- 写入性能：当面对极高的写入速度时ES可能会遇到瓶颈，那么就需要对配置进行优化，并且合理的设计索引策略，如使用时间分区索引，或者基于业务逻辑的一些分区；
- 存储成本：ES对硬件资源的要求还是比较高的，尤其是内存，由于他依赖倒排序索引来加速搜索过程，这可能会导致较大的存储开销；
- 数据一致性：在分布式环境中，确保数据一致是一个挑战，在高并发环境中，如何平衡性能和数据一致性依然是一个需要仔细权衡的问题。
MySql到ES数据一致性同步方案
- 1、同步双写（硬编码写入MySql的同时，写入ES）
适用场景：适用于逻辑相对来说比较简单，时效性也很高；适用于对数据实时性要求极高，且业务逻辑相对简单的场景，就比如金融交易的记录同步。
优点：
逻辑简单
实时性高
缺点：
硬编码：所有涉及数据库变更操作的地方都需要加上同时对ES的变更操作
性能下降（性能瓶颈）：双写操作导致事务的时间延长，整体的处理时间也大大的加长了。
补偿机制：需要有补偿机制，在操作ES失败的情况下怎么处理呢，回滚MqSql的数据吗？还是补偿ES的操作？
2、定时同步（分布式任务调度）
适用场景：定时同步业务服务只处理MySql的数据，不管ES的数据操作。通过一个同步服务，并且引入分布式任务调度服务，触发进行定时的数据库同步到ES的操作优点：
逻辑简单
服务间解耦缺点：
时效性差：数据一致的延迟高
全表扫描：并且对数据库的压力也是比较大的，要优化查询索引，可能会全表扫描。虽然分布式调度任务支持分片，但是在分库分表的情况下，依然要对多个表进行处理。
3、MQ消息队列+同步服务异步同步方案
业务服务操作数据库变更后，向MQ发送一条数据库变更消息，由同步服务消费MQ，获取消息后处理对ES数据的操作。优点：
性能高：保证了对业务数据处理的性能，同时MQ的削峰填谷功能也照顾到了ES在高写入情况下的性能瓶颈
业务隔离：通过MQ将业务主流程和ES数据的处理完全解耦，故障也完全隔离了。缺点:
硬编码：对MySql数据的业务处理都要加上消息队列的发送。
系统复杂度：由于引入了新的中间件，系统的复杂度大大提升了；要保证MQ的高可用，要保证消息的有效投递，这些都需要考虑。4、监听Binlog方案
MySql有个Binlog日志，不管什么存储引擎，只要发生了表数据的更新，都会产生Binlog日志，MySql数据库的主备组成等这些都离不开Binlog日志，需要依靠Binlog来同步数据，保证数据的一致性，那么我们就可以通过监听Binlog日志的方式来进行数据同步。
Canal（阿里云中间件）：支持通过监听Binlog日志，将数据同步到ES功能,，这样大大简化了数据一致性的难度。
要是担心数据量过大的这种情况，频繁的写入影响ES的性能，那么可以考虑先通过Canal Server获取Binglog发送到MQ,再通过Canal Adapter将数据同步到ES。
(1)、Canal Server 获取binlog发送MQ
(2)、MQ
(3)、Canal Adapter（