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、加鎖：不管是用分布式互斥鎖還是本地互斥鎖，保證僅少量的請求能夠到達數據庫，并重新構建緩存，其余線程則在鎖釋放后能訪問到新的緩存。

• 緩存雪崩（導致原因：緩存中的大量或者所有數據失效）
  大量用戶發起了對各類數據的請求，這各類數據在Redi