1、如何保证MySql到ES的数据一致性？

答：ES是一个开元分布式搜索和分析引擎、它提供了全文搜索、结构化搜索分析以及这些组合的能力。

全文搜索能力：ES支持复杂的搜索能力，包括模糊匹配、短语查询、布尔查询等，并且可以快速的返回结果
实时数据分析：实时数据分析，支持对数据进行复杂的统计分析，如计数、求和、平均值、最大值、最小值等，这对于业务的分析非常有作用
扩展性强：ES的分布式架构可以轻松的横向扩展到数白甚至数千台服务器节点，处理PB级的数据量；通过设置副本分片，确保数据沉淀、避免单点故障；
灵活的数据模型：Es使用Json格式来存储数据，这种格式对于现代应用程序来说，非常的友好，易于理解和操作，你可以自定义映射来规范文档结构；同样也允许你自由的添加新字段，无需预先定义模式；
强大的插件生态系统：最熟悉的可能就是Kibana，它是官方提供的可视化界面，提供了一个友好的用户界面，用于搜索可视化和管理ES中的数据；还有其它的一些插件（如Logstash），它们可以帮助收集解析和传输数据到ES;
使用多种应用场景：日志和事件数据分析；电子商务中的相关搜索；安全信息和事务管理等各种大数据量的情况下的使用。

所以ES这个中间件非常适合在“数据量特别大”的情况下，特别还设计到“分库分表”的这种业务场景下的使用。但是引入新的中间件也有需要注意的挑战；

写入性能：当面对极高的写入速度时ES可能会遇到瓶颈，那么就需要对配置进行优化，并且合理的设计索引策略，如使用时间分区索引，或者基于业务逻辑的一些分区（表分区）；
存储成本：ES对硬件资源的要求还是比较高的，尤其是内存，由于他依赖倒排序索引来加速搜索过程，这可能会导致较大的存储开销；
数据一致性：在分布式环境中，确保数据一致是一个挑战，在高并发环境中，如何平衡性能和数据一致性依然是一个需要仔细权衡的问题。

MySql到ES数据一致性同步方案

1、同步双写（硬编码写入MySql的同时，写入ES）
适用场景：适用于逻辑相对来说比较简单，时效性也很高；适用于对数据实时性要求极高，且业务逻辑相对简单的场景，就比如金融交易的记录同步。
优点：
逻辑简单
实时性高

缺点：
硬编码：所有涉及数据库变更操作的地方都需要加上同时对ES的变更操作
性能下降（性能瓶颈）：双写操作导致事务的时间延长，整体的处理时间也大大的加长了。
补偿机制：需要有补偿机制，在操作ES失败的情况下怎么处理呢，回滚MqSql的数据吗？还是补偿ES的操作？

2、定时同步（分布式任务调度）
适用场景：定时同步业务服务只处理MySql的数据，不管ES的数据操作。通过一个同步服务，并且引入分布式任务调度服务（常见分布式任务调度服务有：Quartz Scheduler、XXL-JOB、SchedulerX、ElasticJob），触发进行定时的数据库同步到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（或者自定义同步服务）将数据同步到ES

优点：
无代码侵入：业务服务完全不用新增任何代码
性能高：Canal处理能力完全不用担心，毕竟有阿里的背书
业务隔离：服务间完全解耦，业务服务完全不用考虑业务以外的功能；ES的任何数据同步引发的问题，都不会影响到主业务。

缺点：
系统复杂度：系统业务复杂度显著提升了，毕竟引入了Canal和MQ两个中间件，这些中间件的高可用和异常处理都需要考虑的。

Flink：不仅可以对增量数据进行同步，还可以对存量数据进行同步。

2、什么是Redis的穿透、击穿和雪崩？

Redis崩溃之后会怎么样？系统该如何应对这种情况呢？
答：缓存穿透、击穿和雪崩是缓存中最大的三个问题，要么不出现，一旦出现就是致命性的问题。
Redis是一个开源的，基于内存的数据结构存储系统，使用最多的就是它的缓存功能了，用户的请求到达应用服务后，先到Redis中查找是否有对应的数据，要是存在就直接返回给用户了；若是不存在则从数据库中获取数据返回给用户，同时在Redis中建立一份缓存，这样在一定时间内要是再有获取这份数据，就不用再去请求数据库了。

我们就是利用Redis的高性能来支撑应用服务的高并发，大量的数据请求让Redis挡在数据库之前，大大降低了数据库的读压力，特别是在分布式系统环境下，统一的缓存管理，降低了缓存维护的难度。

缓存穿透、击穿和雪崩是Redis缓存系统中常见的三种问题，它们都可能导致数据库负载突然增加，甚至导致系统崩溃，所以我们要理解并知道他们的解决方案。

缓存穿透
突然有大量的请求来到服务器，在这些请求中，大部分是Redis中没有的数据，这就导致这些请求直接到了数据库上，其实这些数据在数据库中也没有，那自然也无法在Redis中建立缓存，这种恶意攻击请求，每次都视缓存于无物，直接查询数据库，严重的时候甚至会造成数据库直接宕机，这种大量的请求的Redis中没有，数据库中也没有的场景就是缓存穿透。

应对方案：
1、缓存空值：如果这些无效的请求的值变化不大，那么可以缓存这些无效的Key到Redis中，注意设置好过期时间，避免大量的无效的key占用内存（设置较短的过期时间）；

2、布隆过滤器：还可以使用布隆过滤器提前预热，在请求一进来就进行筛选，虽然有一定的误判，但是可以挡住大部分的无效请求。

3、验证、限流、黑名单：还有了，自己的接口也要做好验证（IP、用户限流），对于明显不合理的请求直接返回。如果有预警机制还可以根据用户或者IP对接口进行限流。对于异常频繁的访问行为，甚至还可以采取黑名单的机制。

缓存击穿（导致原因：某个热点数据不存在于缓存中）
大量用户同时发起了对某个热点数据的请求，访问非常频繁，Redis缓存了这个热Key，帮助应用服务轻松抗住高并发，这个Key正处于集中式高并发访问的情况下突然失效，在这个瞬间，大量的请求就击穿了缓存直接请求在数据库，就像在一道屏障上凿开了一个洞，就数据来说，热点key失效数据在数据库中还是存在的。

应对方案：
1、设置永不更新：若缓存的数据基本不会发生更新，则可以尝试将该热点数据设置为永不更新，或者处于可预料的集中式高并发的这个时间段内不过期；

2、加锁：不管是用分布式互斥锁还是本地互斥锁，保证仅少量的请求能够到达数据库，并重新构建缓存，其余线程则在锁释放后能访问到新的缓存。