【分佈式】分佈式場景下面試題

有使用過緩存嗎？Redis和Memcached有什麼區別？

redis相比memcached有哪些優勢:

• memcached所有的值均是簡單的字符串，redis作爲其替代者，支持更爲豐富的數據類型
• redis的速度比memcached快很多
• redis可以持久化其數據

參考鏈接：redis和memcached的優缺點及區別

Redis的線程模型？單線程的Redis如何實現高性能的？

線程模型:

Redis 基於 Reactor 模式開發了自己的網絡事件處理器： 這個處理器被稱爲文件事件處理器（file event handler）：

• 文件事件處理器使用 **I/O 多路複用（multiplexing）**程序來同時監聽多個套接字， 並根據套接字目前執行的任務來爲套接字關聯不同的事件處理器。

• 當被監聽的套接字準備好執行連接應答（accept）、讀取（read）、寫入（write）、關閉（close）等操作時， 與操作相對應的文件事件就會產生， 這時文件事件處理器就會調用套接字之前關聯好的事件處理器來處理這些事件。

雖然文件事件處理器以單線程方式運行， 但通過使用 I/O 多路複用程序來監聽多個套接字， 文件事件處理器既實現了高性能的網絡通信模型， 又可以很好地與 redis 服務器中其他同樣以單線程方式運行的模塊進行對接， 這保持了 Redis 內部單線程設計的簡單性。
詳細介紹：Redis線程模型

什麼是分佈式鎖？使用Redis實現過分佈式鎖

分佈式鎖的四個條件:

• 互斥性：任意時刻，只能有一個客戶端獲取鎖，不能同時有兩個客戶端獲取到鎖。
• 安全性：鎖只能被持有該鎖的客戶端刪除，不能由其它客戶端刪除。
• 死鎖：獲取鎖的客戶端因爲某些原因(如down機等)而未能釋放鎖，其它客戶端再也無法獲取到該鎖。
• 容錯：當部分節點(redis節點等)down機時，客戶端仍然能夠獲取鎖和釋放鎖。

分佈式鎖三種實現方式:

• 數據庫樂觀鎖
• 基於Redis的分佈式鎖
• 基於ZooKeeper的分佈式鎖

Redis實現分佈式鎖:

• Jedis開源組件的jedis.set(String key, String value, String nxxx, String expx, int time)方法獲取鎖
• 釋放鎖；使用jedis.eval()方法調用Luau腳本代碼，eval()方法是將Lua代碼交給Redis服務端執行；例如Lua腳本文本：

if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end

詳細介紹：Redis分佈式鎖的正確實現方式

Zookeeper實現的分佈式鎖和Redis有何區別？

• Zookeeper使用會話有效期方式解決死鎖現象。
• Redis 是對key設置有效期解決死鎖現象

可靠性:

從可靠性角度分析，Zookeeper可靠性比Redis更好。

因爲Redis有效期不是很好控制，可能會產生有效期延遲，Zookeeper就不一樣，因爲Zookeeper臨時節點先天性可控的有效期，所以相對來說Zookeeper比Redis更好

Zookeeper和Redis分佈式鎖詳細介紹：爲什麼分佈式要有分佈式鎖！

Redis的key過期處理策略

• 定時刪除：在設置鍵的過期時間的時候創建一個定時器，當過期時間到的時候立馬執行刪除操作。不過這種處理方式是即時的，不管這個時間內有多少過期鍵，不管服務器現在的運行狀況，都會立馬執行，所以對CPU不是很友好。

• 惰性刪除：惰性刪除策略不會在鍵過期的時候立馬刪除，而是當外部指令獲取這個鍵的時候纔會主動刪除。處理過程爲：接收get執行、判斷是否過期（這裏按過期判斷）、執行刪除操作、返回nil（空）。

• 定期刪除：定期刪除是設置一個時間間隔，每個時間段都會檢測是否有過期鍵，如果有執行刪除操作。這個概念應該很好理解。

分佈式事務有了解嗎？如何實現分佈式事務？

分佈式事務用於在分佈式系統中保證不同節點之間的數據一致性。
分佈式事務的實現有很多種，最具有代表性的是由Oracle Tuxedo系統提出的XA分佈式事務協議。XA協議包含兩階段提交（2PC）和三階段提交（3PC）兩種實現

在XA協議中包含着兩個角色：事務協調者和事務參與者。

• 2PC成功處理

第一階段

作爲事務協調者的節點會首先向所有的參與者節點發送Prepare請求。

在接到Prepare請求之後，每一個參與者節點會各自執行與事務有關的數據更新，寫入Undo Log和Redo Log。如果參與者執行成功，暫時不提交事務，而是向事務協調節點返回“完成”消息。

當事務協調者接到了所有參與者的返回消息，整個分佈式事務將會進入第二階段。

第二階段

如果事務協調節點在之前所收到都是正向返回，那麼它將會向所有事務參與者發出Commit請求。

接到Commit請求之後，事務參與者節點會各自進行本地的事務提交，並釋放鎖資源。當本地事務完成提交後，將會向事務協調者返回“完成”消息。

當事務協調者接收到所有事務參與者的“完成”反饋，整個分佈式事務完成。

• 2PC失敗處理
  在XA的第一階段，如果某個事務參與者反饋失敗消息，說明該節點的本地事務執行不成功，必須回滾。
  於是在第二階段，事務協調節點向所有的事務參與者發送Abort請求。接收到Abort請求之後，各個事務參與者節點需要在本地進行事務的回滾操作，回滾操作依照Undo Log來進行。

第一階段

第二階段

XA兩階段提交的不足

性能問題；XA協議遵循強一致性。在事務執行過程中，各個節點佔用着數據庫資源，只有當所有節點準備完畢，事務協調者纔會通知提交，參與者提交後釋放資源。這樣的過程有着非常明顯的性能問題。

協調者單點故障問題；事務協調者是整個XA模型的核心，一旦事務協調者節點掛掉，參與者收不到提交或是回滾通知，參與者會一直處於中間狀態無法完成事務。

丟失消息導致的不一致問題；在XA協議的第二個階段，如果發生局部網絡問題，一部分事務參與者收到了提交消息，另一部分事務參與者沒收到提交消息，那麼就導致了節點之間數據的不一致。

參考鏈接：漫畫：什麼是分佈式事務？

XA三階段提交（3PC）

三階段提交在兩提交的基礎上增加了CanCommit階段，並且引入了超時機制。一旦事務參與者遲遲沒有接收到協調者的commit請求，會自動進行本地commit。這樣有效解決了協調者單點故障的問題。但是性能問題和不一致的問題仍然沒有根本解決。