??????歡迎來到我的博客，很高興能夠在這里和您見面！希望您在這里可以感受到一份輕松愉快的氛圍，不僅可以獲得有趣的內(nèi)容和知識(shí)，也可以暢所欲言、分享您的想法和見解。

• 推薦:kwan 的首頁,持續(xù)學(xué)習(xí),不斷總結(jié),共同進(jìn)步,活到老學(xué)到老
• 導(dǎo)航
  • 檀越劍指大廠系列:全面總結(jié) java 核心技術(shù)點(diǎn),如集合,jvm,并發(fā)編程 redis,kafka,Spring,微服務(wù),Netty 等
  • 常用開發(fā)工具系列:羅列常用的開發(fā)工具,如 IDEA,Mac,Alfred,electerm,Git,typora,apifox 等
  • 數(shù)據(jù)庫系列:詳細(xì)總結(jié)了常用數(shù)據(jù)庫 mysql 技術(shù)點(diǎn),以及工作中遇到的 mysql 問題等
  • 懶人運(yùn)維系列:總結(jié)好用的命令,解放雙手不香嗎?能用一個(gè)命令完成絕不用兩個(gè)操作
  • 數(shù)據(jù)結(jié)構(gòu)與算法系列:總結(jié)數(shù)據(jù)結(jié)構(gòu)和算法,不同類型針對(duì)性訓(xùn)練,提升編程思維,劍指大廠

非常期待和您一起在這個(gè)小小的網(wǎng)絡(luò)世界里共同探索、學(xué)習(xí)和成長。?????? ?? 歡迎訂閱本專欄 ??

一.分布式理論

1.CAP 理論

CAP 理論，也被稱為 CAP 定理，是一個(gè)與分布式系統(tǒng)和數(shù)據(jù)庫系統(tǒng)相關(guān)的理論，由計(jì)算機(jī)科學(xué)家埃里克·布魯爾（Eric Brewer）在 2000 年提出。該理論描述了分布式計(jì)算系統(tǒng)中三個(gè)關(guān)鍵概念之間的權(quán)衡：

1. 一致性（Consistency）：在分布式系統(tǒng)中的所有節(jié)點(diǎn)看到的數(shù)據(jù)副本都是一致的。換句話說，如果一個(gè)節(jié)點(diǎn)在某次操作之后讀取了數(shù)據(jù)，那么其他節(jié)點(diǎn)在同一時(shí)間也應(yīng)該能夠讀取到相同的數(shù)據(jù)。

2. 可用性（Availability）：系統(tǒng)在有限時(shí)間內(nèi)對(duì)于客戶端請(qǐng)求的響應(yīng)能力。即使系統(tǒng)中的某些節(jié)點(diǎn)出現(xiàn)故障，也應(yīng)該盡量保持對(duì)外提供服務(wù)，而不是完全不可用。

3. 分區(qū)容錯(cuò)性（Partition Tolerance）：系統(tǒng)能夠繼續(xù)運(yùn)行，即使網(wǎng)絡(luò)中的某些部分無法通信，導(dǎo)致消息在節(jié)點(diǎn)之間可能會(huì)丟失或延遲。

CAP 理論指出，在分布式系統(tǒng)中，無法同時(shí)滿足一致性、可用性和分區(qū)容錯(cuò)性這三個(gè)要求。在任何分布式系統(tǒng)中，只能滿足其中的兩個(gè)。這是因?yàn)楫?dāng)分布式系統(tǒng)遇到網(wǎng)絡(luò)分區(qū)或故障時(shí)，如果要保持一致性，可能會(huì)犧牲可用性，反之亦然。

2.分布式系統(tǒng)類型

根據(jù) CAP 理論的劃分，分布式系統(tǒng)可以分為以下三種類型：

1. CP：保證一致性和分區(qū)容錯(cuò)性，可能犧牲可用性。這意味著系統(tǒng)在遇到網(wǎng)絡(luò)分區(qū)或節(jié)點(diǎn)故障時(shí)，會(huì)停止對(duì)外提供服務(wù)，以確保數(shù)據(jù)的一致性。

2. CA：保證一致性和可用性，但可能會(huì)犧牲分區(qū)容錯(cuò)性。這種情況下，分布式系統(tǒng)在面臨網(wǎng)絡(luò)分區(qū)時(shí)，會(huì)選擇保持一致性和可用性，但可能無法對(duì)所有請(qǐng)求都提供響應(yīng)。

3. AP：保證可用性和分區(qū)容錯(cuò)性，但可能犧牲一致性。在這種情況下，系統(tǒng)會(huì)繼續(xù)對(duì)外提供服務(wù)，即使數(shù)據(jù)在節(jié)點(diǎn)之間不一致。

需要注意的是，CAP 理論的描述是一個(gè)理論性的極端情況，實(shí)際系統(tǒng)往往會(huì)在這三個(gè)屬性之間進(jìn)行權(quán)衡，根據(jù)具體的需求和應(yīng)用場景做出合適的選擇。

3.Base 理論

BASE 理論是一個(gè)與分布式數(shù)據(jù)庫系統(tǒng)和分布式系統(tǒng)設(shè)計(jì)相關(guān)的概念，它是對(duì) CAP 理論的一種實(shí)際應(yīng)用和權(quán)衡。BASE 是一個(gè)縮寫，代表著三個(gè)關(guān)鍵屬性：

1. 基本可用性（Basically Available）：系統(tǒng)保證在有限時(shí)間內(nèi)對(duì)客戶端的請(qǐng)求做出響應(yīng)，即使系統(tǒng)發(fā)生部分故障或者數(shù)據(jù)不一致。

2. 軟狀態(tài)（Soft state）：系統(tǒng)中的數(shù)據(jù)狀態(tài)可能會(huì)隨著時(shí)間的推移而發(fā)生變化，即時(shí)不同節(jié)點(diǎn)間的數(shù)據(jù)副本不一致。

3. 最終一致性（Eventual Consistency）：系統(tǒng)保證在一段時(shí)間內(nèi)，如果不再發(fā)生更新，系統(tǒng)中的所有數(shù)據(jù)副本最終會(huì)達(dá)到一致的狀態(tài)。這與強(qiáng)一致性（如 ACID）不同，強(qiáng)一致性要求在任何時(shí)間點(diǎn)都保持?jǐn)?shù)據(jù)一致，而最終一致性允許在一段時(shí)間內(nèi)存在不一致的狀態(tài)。

BASE 理論的思想是，分布式系統(tǒng)可以放松強(qiáng)一致性的要求，從而獲得更高的可用性和性能。在分布式系統(tǒng)中，由于網(wǎng)絡(luò)延遲、節(jié)點(diǎn)故障等因素，實(shí)現(xiàn)強(qiáng)一致性可能會(huì)導(dǎo)致性能問題。相反，采用最終一致性的策略，允許數(shù)據(jù)在一段時(shí)間內(nèi)不同步，但會(huì)在后續(xù)的處理中逐漸達(dá)到一致狀態(tài)，從而更好地滿足系統(tǒng)的可用性和性能需求。

需要注意的是，BASE 理論并不是絕對(duì)的，它適用于某些分布式系統(tǒng)和應(yīng)用場景，但不適用于所有情況。在設(shè)計(jì)分布式系統(tǒng)時(shí)，根據(jù)具體的業(yè)務(wù)需求和性能要求，可以選擇適當(dāng)?shù)囊恢滦约?jí)別和數(shù)據(jù)管理策略。

4.集群對(duì)比

• rebalance 數(shù)據(jù)重分配
• 擴(kuò)容
• 是否有副本
• 是否有分片
• 是否主從
• 如何負(fù)載均衡
• 集群節(jié)點(diǎn)發(fā)現(xiàn)
• 宕機(jī)自修復(fù)
• 是否節(jié)點(diǎn)對(duì)等

5.鏈?zhǔn)秸{(diào)用

• spring 中的 FilterChain,鏈?zhǔn)秸{(diào)用 filter

• netty 中的 ChannelHandler

• sentinel 中的 slot chain

• java8 中的 stream 處理

• spring 中的狀態(tài)機(jī)模式定義

• gatway 中的謂詞 router

6.框架中的 COW

框架中用到的寫時(shí)復(fù)制,copy on write

• Redis 的 Aof 文件重寫
• SpringCloud Alibaba 中的 Sentinel 中的 slotChain
• ArrayList 擴(kuò)容時(shí)

7.時(shí)間輪算法

時(shí)間輪算法（Time Wheel Algorithm）是一種用于處理定時(shí)事件的數(shù)據(jù)結(jié)構(gòu)和算法。它主要用于操作系統(tǒng)、網(wǎng)絡(luò)通信和其他需要按時(shí)間調(diào)度任務(wù)的場景。時(shí)間輪算法基于一個(gè)循環(huán)的時(shí)間輪結(jié)構(gòu)，類似于一個(gè)時(shí)鐘，其中每個(gè)刻度代表一個(gè)時(shí)間單位，例如毫秒或秒。

時(shí)間輪算法的主要思想是將時(shí)間分成若干個(gè)連續(xù)的間隔，每個(gè)間隔稱為一個(gè)刻度（tick）。每個(gè)刻度上都可以安排一個(gè)或多個(gè)任務(wù)，這些任務(wù)都會(huì)在對(duì)應(yīng)的刻度觸發(fā)執(zhí)行。當(dāng)時(shí)間輪轉(zhuǎn)動(dòng)時(shí)，當(dāng)前刻度會(huì)不斷變化，觸發(fā)相應(yīng)刻度上的任務(wù)執(zhí)行。

算法的基本步驟如下：

1. 初始化時(shí)間輪：創(chuàng)建一個(gè)循環(huán)數(shù)組（或鏈表），每個(gè)元素代表一個(gè)刻度，每個(gè)刻度上存儲(chǔ)需要執(zhí)行的任務(wù)列表。

2. 插入任務(wù)：將需要定時(shí)執(zhí)行的任務(wù)插入到對(duì)應(yīng)的刻度上。如果任務(wù)需要在未來的幾個(gè)刻度后執(zhí)行，可以在相應(yīng)的刻度上存儲(chǔ)任務(wù)信息。

3. 時(shí)間前進(jìn)：隨著時(shí)間的推移，時(shí)間輪會(huì)不斷前進(jìn)。每次時(shí)間輪前進(jìn)一個(gè)刻度，當(dāng)前刻度會(huì)指向下一個(gè)刻度，這時(shí)候會(huì)觸發(fā)當(dāng)前刻度上存儲(chǔ)的所有任務(wù)執(zhí)行。

4. 處理任務(wù)：當(dāng)時(shí)間輪前進(jìn)時(shí)，會(huì)觸發(fā)當(dāng)前刻度上存儲(chǔ)的任務(wù)執(zhí)行。這些任務(wù)可以是需要執(zhí)行的函數(shù)、事件通知等。

5. 移除任務(wù)：一旦任務(wù)被執(zhí)行，它可以從時(shí)間輪中移除。如果任務(wù)是重復(fù)性的，可以在執(zhí)行后重新插入到合適的刻度上，實(shí)現(xiàn)周期性執(zhí)行。

時(shí)間輪算法的優(yōu)勢在于它適用于需要精確時(shí)間控制的場景，同時(shí)具有較高的效率。然而，時(shí)間輪也有其局限性，例如在需要更高時(shí)間精度或動(dòng)態(tài)調(diào)整定時(shí)任務(wù)的情況下可能不太適用。

分層時(shí)間輪:

8.分布式痛點(diǎn)問題有哪些?

需要了解諸如秒殺搶購等場景的架構(gòu)實(shí)現(xiàn)方案，以及方案解決的痛點(diǎn)問題，這類問題往往需要先提煉痛點(diǎn)問題，再針對(duì)痛點(diǎn)問題做優(yōu)化。

分布式系統(tǒng)是由多臺(tái)計(jì)算機(jī)或服務(wù)器組成的系統(tǒng)，它們通過網(wǎng)絡(luò)相互通信和協(xié)作，以完成復(fù)雜的任務(wù)。然而，分布式系統(tǒng)也面臨著許多痛點(diǎn)和挑戰(zhàn)，以下是一些常見的問題：

1. 通信延遲和帶寬限制： 分布式系統(tǒng)中的計(jì)算機(jī)之間需要進(jìn)行網(wǎng)絡(luò)通信，這會(huì)導(dǎo)致通信延遲和帶寬限制。這可能會(huì)影響系統(tǒng)的性能和響應(yīng)時(shí)間。

2. 數(shù)據(jù)一致性： 在分布式系統(tǒng)中，多個(gè)節(jié)點(diǎn)可能并發(fā)地讀寫數(shù)據(jù)，因此需要解決數(shù)據(jù)一致性的問題。維護(hù)一致性通常需要使用復(fù)雜的算法和協(xié)議，如分布式事務(wù)。

3. 故障處理： 分布式系統(tǒng)中的節(jié)點(diǎn)可能會(huì)因?yàn)橛布收?、網(wǎng)絡(luò)問題或軟件錯(cuò)誤而失敗。因此，需要實(shí)現(xiàn)故障檢測和故障恢復(fù)機(jī)制，以確保系統(tǒng)的可用性和可靠性。

4. 分布式存儲(chǔ)： 數(shù)據(jù)的分布式存儲(chǔ)和管理是一個(gè)復(fù)雜的問題。需要考慮數(shù)據(jù)的分片、備份、恢復(fù)等方面，以確保數(shù)據(jù)的可靠性和可用性。

5. 負(fù)載均衡： 在分布式系統(tǒng)中，需要確保各個(gè)節(jié)點(diǎn)之間的負(fù)載均衡，以避免某些節(jié)點(diǎn)過載，而其他節(jié)點(diǎn)空閑的情況。

6. 安全性： 分布式系統(tǒng)需要保護(hù)數(shù)據(jù)的機(jī)密性和完整性，同時(shí)還需要考慮身份驗(yàn)證、授權(quán)和防止網(wǎng)絡(luò)攻擊等安全問題。

7. 系統(tǒng)復(fù)雜性： 分布式系統(tǒng)往往比單一系統(tǒng)更加復(fù)雜，因?yàn)樯婕暗蕉鄠€(gè)節(jié)點(diǎn)、多個(gè)組件和多個(gè)網(wǎng)絡(luò)連接。這增加了開發(fā)、調(diào)試和維護(hù)的難度。

8. 性能調(diào)優(yōu)： 在分布式系統(tǒng)中，性能調(diào)優(yōu)是一個(gè)挑戰(zhàn)，需要仔細(xì)設(shè)計(jì)和配置系統(tǒng)，以確保在高負(fù)載時(shí)仍能提供良好的性能。

9. 擴(kuò)展性： 隨著業(yè)務(wù)的增長，分布式系統(tǒng)可能需要擴(kuò)展，這要求系統(tǒng)具備良好的可擴(kuò)展性，能夠容易地添加新的節(jié)點(diǎn)或資源。

10. 監(jiān)控和診斷： 對(duì)于分布式系統(tǒng)，監(jiān)控和診斷問題變得更加復(fù)雜。需要使用專業(yè)的工具和技術(shù)來監(jiān)控系統(tǒng)的健康狀況，并快速定位和解決問題。

這些問題只是分布式系統(tǒng)中的一部分挑戰(zhàn)，解決它們需要深入的技術(shù)知識(shí)和合適的工具和方法。因此，分布式系統(tǒng)的設(shè)計(jì)和管理是一項(xiàng)復(fù)雜而具有挑戰(zhàn)性的任務(wù)。

二.分布式事務(wù)

1.分布式事務(wù)解決方案

分布式事務(wù)是在分布式系統(tǒng)中處理跨多個(gè)資源、服務(wù)或數(shù)據(jù)庫的事務(wù)操作的問題。由于分布式系統(tǒng)的特性，確保一致性和可靠性變得更加復(fù)雜。為了解決這個(gè)問題，出現(xiàn)了多種分布式事務(wù)解決方案。以下是一些常見的分布式事務(wù)解決方案：

1. 兩階段提交（Two-Phase Commit，2PC）：在這種協(xié)議中，有一個(gè)協(xié)調(diào)者（Coordinator）和多個(gè)參與者（Participants）。在第一階段，協(xié)調(diào)者詢問所有參與者是否準(zhǔn)備好提交事務(wù)。如果所有參與者都準(zhǔn)備好了，協(xié)調(diào)者會(huì)發(fā)送一個(gè)提交請(qǐng)求，然后進(jìn)入第二階段。在第二階段，所有參與者會(huì)執(zhí)行實(shí)際的提交操作。如果有一個(gè)參與者出現(xiàn)問題，整個(gè)事務(wù)會(huì)回滾。

2. 三階段提交（Three-Phase Commit，3PC）：3PC 在 2PC 的基礎(chǔ)上增加了一個(gè)準(zhǔn)備階段，以減少某些情況下的阻塞和超時(shí)問題。在第一階段，協(xié)調(diào)者詢問所有參與者是否準(zhǔn)備好提交事務(wù)。在第二階段，協(xié)調(diào)者會(huì)告知所有參與者是否要提交或中止事務(wù)。在第三階段，所有參與者執(zhí)行實(shí)際的提交或回滾操作。

3. XA 協(xié)議（Two-Phase Commit）： XA 協(xié)議是一種傳統(tǒng)的分布式事務(wù)協(xié)議，它通過協(xié)調(diào)器（Coordinator）來確保分布式事務(wù)的一致性。在這個(gè)協(xié)議中，參與事務(wù)的各個(gè)資源管理器（Resource Manager）會(huì)向協(xié)調(diào)器報(bào)告事務(wù)的執(zhí)行狀態(tài)，并在協(xié)調(diào)器的協(xié)調(diào)下執(zhí)行事務(wù)的提交或回滾。XA 協(xié)議具有強(qiáng)一致性，但也有較高的性能開銷和單點(diǎn)故障的風(fēng)險(xiǎn)。

4. TCC（Try-Confirm-Cancel）：TCC 是一種補(bǔ)償型的分布式事務(wù)解決方案，它將事務(wù)分為三個(gè)階段：嘗試（Try）、確認(rèn)（Confirm）和取消（Cancel）。在嘗試階段，參與者會(huì)嘗試執(zhí)行事務(wù)操作，但不會(huì)真正提交。在確認(rèn)階段，參與者確認(rèn)操作，并提交更改。如果有問題，可以在取消階段進(jìn)行回滾操作。

5. Saga 模式：Saga 是一種長時(shí)間運(yùn)行的事務(wù)，通過將大事務(wù)分解為一系列較小的子事務(wù)來處理。每個(gè)子事務(wù)負(fù)責(zé)自己的提交和回滾邏輯。如果一個(gè)子事務(wù)失敗，相應(yīng)的補(bǔ)償操作將會(huì)觸發(fā)。Saga 模式依賴于應(yīng)用程序的邏輯來處理一致性和回滾。

6. 消息隊(duì)列：使用消息隊(duì)列作為分布式事務(wù)的一部分，將事務(wù)操作封裝為消息，并將其發(fā)送到隊(duì)列中。接收者在處理消息時(shí)執(zhí)行相應(yīng)的操作。如果操作失敗，可以通過消息重試機(jī)制或者定制的補(bǔ)償操作來處理。

7. 基于時(shí)間戳的一致性：通過記錄操作的時(shí)間戳和狀態(tài)信息來實(shí)現(xiàn)一致性。參與者可以根據(jù)時(shí)間戳來判斷是否可以執(zhí)行操作，從而避免沖突。

8. GTM（Global Transaction Manager）： GTM 是一種集中式的全局事務(wù)管理器，它負(fù)責(zé)協(xié)調(diào)分布式事務(wù)的提交和回滾。不同于 Seata，GTM 通常將事務(wù)數(shù)據(jù)存儲(chǔ)在單獨(dú)的數(shù)據(jù)庫中，而不是嵌入到應(yīng)用的業(yè)務(wù)數(shù)據(jù)庫中。

每種解決方案都有其優(yōu)缺點(diǎn)，具體的選擇要取決于應(yīng)用程序的需求、性能要求以及容忍的一致性級(jí)別。在實(shí)際應(yīng)用中，根據(jù)業(yè)務(wù)場景的不同，可能需要結(jié)合多種解決方案來實(shí)現(xiàn)分布式事務(wù)的一致性和可靠性。

2.如何解決 TCC 中懸掛問題？

TCC（Try-Confirm-Cancel）是一種用于分布式事務(wù)處理的模式，它將一個(gè)大的事務(wù)拆分為三個(gè)階段：嘗試（Try）、確認(rèn)（Confirm）和取消（Cancel）。每個(gè)階段對(duì)應(yīng)一個(gè)操作，而整個(gè)事務(wù)的一致性由這三個(gè)操作共同保證。TCC 模式能夠在分布式環(huán)境中實(shí)現(xiàn)較高的事務(wù)一致性和可靠性。

懸掛問題是 TCC 模式中的一個(gè)關(guān)鍵挑戰(zhàn)，指的是在執(zhí)行過程中，一個(gè)分支事務(wù)的確認(rèn)操作成功，但由于某些原因?qū)е缕浜罄m(xù)的分支事務(wù)的確認(rèn)或取消操作無法繼續(xù)執(zhí)行。這可能會(huì)導(dǎo)致部分事務(wù)的狀態(tài)不一致，影響整個(gè)分布式事務(wù)的一致性。

以下是解決 TCC 中懸掛問題的一些方法：

1. 超時(shí)機(jī)制： 在 TCC 模式中，可以為每個(gè)分支事務(wù)設(shè)置一個(gè)超時(shí)時(shí)間。如果一個(gè)分支事務(wù)的確認(rèn)或取消操作在超時(shí)時(shí)間內(nèi)未完成，系統(tǒng)可以自動(dòng)執(zhí)行一些補(bǔ)救操作，如執(zhí)行重試、回滾等，以確保事務(wù)的完整性。

2. 事務(wù)狀態(tài)標(biāo)記： 在 TCC 模式中，可以為每個(gè)分支事務(wù)引入狀態(tài)標(biāo)記，表示事務(wù)的當(dāng)前狀態(tài)（嘗試、確認(rèn)、取消）。當(dāng)一個(gè)分支事務(wù)的確認(rèn)操作成功時(shí)，將狀態(tài)標(biāo)記為“已確認(rèn)”；當(dāng)取消操作成功時(shí)，將狀態(tài)標(biāo)記為“已取消”。系統(tǒng)可以定期掃描未完成的事務(wù)，檢查狀態(tài)標(biāo)記，然后采取相應(yīng)的補(bǔ)救措施。

3. 異步通知與補(bǔ)償： 當(dāng)一個(gè)分支事務(wù)的確認(rèn)操作成功時(shí)，可以異步地通知其他相關(guān)的分支事務(wù)進(jìn)行確認(rèn)或取消操作。這樣即使一個(gè)分支事務(wù)的確認(rèn)操作懸掛，其他事務(wù)可以繼續(xù)執(zhí)行，然后系統(tǒng)可以通過補(bǔ)償操作來糾正狀態(tài)不一致的情況。

4. 定時(shí)任務(wù)： 引入定時(shí)任務(wù)來檢查未完成的事務(wù)，發(fā)現(xiàn)懸掛事務(wù)并進(jìn)行處理。這可以是一個(gè)周期性的任務(wù)，負(fù)責(zé)掃描系統(tǒng)中的事務(wù)狀態(tài)并執(zhí)行相應(yīng)的補(bǔ)救操作。

5. 日志和審計(jì)： 在 TCC 模式中，記錄詳細(xì)的事務(wù)日志和審計(jì)信息。這些信息可以幫助系統(tǒng)管理員或開發(fā)人員識(shí)別和解決懸掛問題，以及執(zhí)行必要的恢復(fù)操作。

解決 TCC 中懸掛問題需要結(jié)合超時(shí)機(jī)制、事務(wù)狀態(tài)標(biāo)記、異步通知與補(bǔ)償、定時(shí)任務(wù)以及日志審計(jì)等方法，以確保在分布式環(huán)境中維護(hù)事務(wù)的一致性和可靠性。

3.如何回滾 MQ 和 Redis?

在分布式事務(wù)場景中，涉及到 Redis 和消息隊(duì)列（MQ）的回滾是一個(gè)復(fù)雜的問題，因?yàn)檫@涉及到多個(gè)不同的存儲(chǔ)系統(tǒng)之間的一致性?；貪L策略可以根據(jù)具體的業(yè)務(wù)需求和技術(shù)選型來確定。以下是關(guān)于如何處理分布式事務(wù)中的 Redis 和 MQ 回滾的一些一般策略：

Redis 回滾：

Redis 本身不支持傳統(tǒng)的分布式事務(wù)，但您可以通過以下方法來實(shí)現(xiàn)一定程度的回滾：

1. 操作日志： 在進(jìn)行分布式事務(wù)操作時(shí)，將涉及到的 Redis 操作記錄到一個(gè)日志中。如果事務(wù)的后續(xù)步驟發(fā)生錯(cuò)誤，您可以根據(jù)日志信息進(jìn)行回滾，即撤銷已執(zhí)行的操作。

2. 備份和恢復(fù)： 在事務(wù)開始之前，可以將涉及到的 Redis 數(shù)據(jù)進(jìn)行備份。如果事務(wù)失敗，您可以使用備份數(shù)據(jù)來恢復(fù)到事務(wù)之前的狀態(tài)。

3. 使用 MULTI/EXEC 命令： Redis 提供了MULTI和EXEC命令來創(chuàng)建事務(wù)塊。您可以在事務(wù)塊中執(zhí)行多個(gè)命令，并在執(zhí)行失敗時(shí)使用DISCARD命令來取消事務(wù)，或者使用EXEC命令提交事務(wù)。如果事務(wù)失敗，您可以使用DISCARD來回滾之前的操作。

消息隊(duì)列（MQ）回滾：

在消息隊(duì)列中處理回滾通常需要考慮以下策略：

1. 事務(wù)消息： 一些消息隊(duì)列系統(tǒng)（如 Apache Kafka）支持事務(wù)消息。您可以將數(shù)據(jù)庫操作和消息發(fā)送放在同一個(gè)事務(wù)中，然后在提交事務(wù)時(shí)同時(shí)提交消息和數(shù)據(jù)庫操作，或者在回滾時(shí)同時(shí)進(jìn)行回滾。

2. 消息狀態(tài)管理： 如果消息隊(duì)列不支持事務(wù)消息，您可以在數(shù)據(jù)庫中維護(hù)消息的狀態(tài)。當(dāng)事務(wù)開始時(shí)，將消息狀態(tài)設(shè)置為“待處理”。如果事務(wù)成功，則將消息狀態(tài)設(shè)置為“已處理”。如果事務(wù)失敗，則將消息狀態(tài)設(shè)置為“待處理”，以便稍后重新處理。

3. 死信隊(duì)列： 一些消息隊(duì)列支持死信隊(duì)列，用于處理處理失敗的消息。您可以將處理失敗的消息移動(dòng)到死信隊(duì)列，并在稍后處理。

需要注意的是，處理分布式事務(wù)回滾是一個(gè)復(fù)雜的問題，需要根據(jù)具體的業(yè)務(wù)需求和技術(shù)選型來選擇合適的回滾策略。在實(shí)際應(yīng)用中，您可能需要結(jié)合數(shù)據(jù)庫事務(wù)和消息隊(duì)列的特性，設(shè)計(jì)適合自己應(yīng)用場景的回滾機(jī)制。

4.最終一致性

分布式最終一致性是指在分布式系統(tǒng)中，盡管在一段時(shí)間內(nèi)數(shù)據(jù)副本之間可能存在不一致的狀態(tài)，但經(jīng)過一段時(shí)間后，系統(tǒng)最終會(huì)達(dá)到一致的狀態(tài)。這種一致性模型允許在分布式系統(tǒng)中的各個(gè)節(jié)點(diǎn)之間存在一段時(shí)間的數(shù)據(jù)不一致，但最終數(shù)據(jù)會(huì)收斂到一致狀態(tài)，從而保證系統(tǒng)的可用性和可靠性。

分布式最終一致性通常涉及以下幾種策略和模式：

1. 異步復(fù)制： 分布式系統(tǒng)中的數(shù)據(jù)副本可能會(huì)異步地復(fù)制到其他節(jié)點(diǎn)，導(dǎo)致在某個(gè)時(shí)間點(diǎn)上節(jié)點(diǎn)之間的數(shù)據(jù)狀態(tài)不一致。但隨著時(shí)間的推移，副本會(huì)趨于一致。

2. 事件驅(qū)動(dòng)： 將系統(tǒng)中的數(shù)據(jù)變更表示為事件，并通過消息隊(duì)列將這些事件傳播到其他節(jié)點(diǎn)。每個(gè)節(jié)點(diǎn)按照接收到的事件按序處理數(shù)據(jù)更新，最終達(dá)到一致狀態(tài)。

3. 版本控制： 為每個(gè)數(shù)據(jù)副本引入版本控制，記錄每次數(shù)據(jù)變更，然后通過協(xié)調(diào)機(jī)制在副本之間傳播這些變更，確保數(shù)據(jù)最終一致。

4. 定時(shí)同步： 定期在各個(gè)節(jié)點(diǎn)之間進(jìn)行數(shù)據(jù)同步，通過定時(shí)任務(wù)將數(shù)據(jù)從一個(gè)節(jié)點(diǎn)同步到其他節(jié)點(diǎn)，逐步實(shí)現(xiàn)數(shù)據(jù)的一致性。

5. 基于時(shí)間戳： 在數(shù)據(jù)副本上附加時(shí)間戳，然后使用時(shí)間戳來解決數(shù)據(jù)沖突和合并問題，使數(shù)據(jù)逐漸趨于一致。

6. 基于版本號(hào)： 為每個(gè)數(shù)據(jù)副本引入版本號(hào)，允許數(shù)據(jù)更新時(shí)指定版本號(hào)，協(xié)調(diào)機(jī)制根據(jù)版本號(hào)解決并發(fā)寫入的問題。

分布式最終一致性是一種折衷方案，權(quán)衡了分布式系統(tǒng)中的性能、可用性和數(shù)據(jù)一致性。這種一致性模型適用于一些弱一致性要求，例如社交網(wǎng)絡(luò)的點(diǎn)贊數(shù)、閱讀數(shù)等數(shù)據(jù)，在短時(shí)間內(nèi)的不一致并不會(huì)嚴(yán)重影響用戶體驗(yàn)。然而，對(duì)于某些領(lǐng)域，如金融、電子商務(wù)等，強(qiáng)一致性可能更為重要，因此需要根據(jù)具體的業(yè)務(wù)需求選擇合適的一致性模型。

5.分布式 session 共享問題

分布式 Session 共享是指在一個(gè)分布式系統(tǒng)中，多個(gè)服務(wù)或節(jié)點(diǎn)需要共享用戶會(huì)話（Session）數(shù)據(jù)，以保持用戶在不同請(qǐng)求之間的狀態(tài)和登錄信息。這種情況常見于使用負(fù)載均衡、微服務(wù)架構(gòu)或多節(jié)點(diǎn)的系統(tǒng)中。然而，實(shí)現(xiàn)分布式 Session 共享可能涉及一些挑戰(zhàn)和考慮事項(xiàng)。

以下是與分布式 Session 共享相關(guān)的問題和解決方案：

問題：

1. 一致性問題： 各節(jié)點(diǎn)之間的數(shù)據(jù)一致性可能受到網(wǎng)絡(luò)延遲和故障的影響，可能會(huì)導(dǎo)致不同節(jié)點(diǎn)上的 Session 數(shù)據(jù)不一致。

2. 性能問題： 分布式 Session 共享可能涉及跨網(wǎng)絡(luò)的數(shù)據(jù)傳輸，可能會(huì)對(duì)性能產(chǎn)生一定影響。

3. Session 管理問題： 如何有效管理 Session 的過期和清理是一個(gè)挑戰(zhàn)，特別是在分布式環(huán)境中。

解決方案：

1. 共享存儲(chǔ)： 使用共享存儲(chǔ)（如數(shù)據(jù)庫、緩存系統(tǒng)）作為 Session 存儲(chǔ)的后端，以確保各節(jié)點(diǎn)可以訪問和更新相同的 Session 數(shù)據(jù)。這種方式需要考慮一致性問題，如使用分布式鎖來保護(hù) Session 數(shù)據(jù)的更新。

2. 無狀態(tài)服務(wù)： 將 Session 數(shù)據(jù)從應(yīng)用層移至客戶端或無狀態(tài)的服務(wù)，以避免 Session 共享的復(fù)雜性。使用 Token 驗(yàn)證可以在每個(gè)請(qǐng)求中傳遞用戶身份和狀態(tài)信息，而不依賴于服務(wù)器端的 Session 數(shù)據(jù)。

3. 分布式緩存： 使用分布式緩存系統(tǒng)，如 Redis，來存儲(chǔ) Session 數(shù)據(jù)。這可以提高讀寫性能并提供一致性保證。同時(shí)，要關(guān)注緩存的失效策略。

4. 一致性算法： 對(duì)于需要強(qiáng)一致性的場景，可以使用一致性算法（如 Paxos、Raft）來確保各節(jié)點(diǎn)上的 Session 數(shù)據(jù)保持一致。

5. 版本控制： 在 Session 數(shù)據(jù)中引入版本控制，以便在更新時(shí)檢測到?jīng)_突并解決。

6. 定時(shí)清理： 使用定時(shí)任務(wù)來清理過期的 Session 數(shù)據(jù)，以避免存儲(chǔ)占用過多空間。

7. 分布式事務(wù)： 在需要的情況下，使用分布式事務(wù)來確保 Session 數(shù)據(jù)的一致性。

8. 負(fù)載均衡策略： 在負(fù)載均衡時(shí)，盡量確保同一用戶的請(qǐng)求被路由到相同的節(jié)點(diǎn)，以減少 Session 數(shù)據(jù)的遷移。

無論選擇哪種解決方案，都需要根據(jù)具體場景和需求權(quán)衡不同的權(quán)衡，綜合考慮一致性、性能、可靠性等因素。

6.注冊(cè)中心腦裂問題?

從腦裂問題剖析 Nacos&Eureka&Zookeeper 架構(gòu)

Nacos、Eureka 和 Zookeeper 都是用于服務(wù)注冊(cè)與發(fā)現(xiàn)、配置管理等分布式系統(tǒng)領(lǐng)域的重要工具或框架。下面將分析這三者在面臨腦裂問題時(shí)的架構(gòu)特點(diǎn)和應(yīng)對(duì)策略。

Nacos:
Nacos 是一個(gè)全面的服務(wù)發(fā)現(xiàn)、配置管理和服務(wù)管理平臺(tái)。它的架構(gòu)和應(yīng)對(duì)腦裂問題的方式如下：

• 架構(gòu)： Nacos 采用集群架構(gòu)，由多個(gè)節(jié)點(diǎn)組成。其中，有一個(gè)或多個(gè)節(jié)點(diǎn)被選為主節(jié)點(diǎn)，負(fù)責(zé)協(xié)調(diào)服務(wù)注冊(cè)、配置管理等任務(wù)。

• 應(yīng)對(duì)策略： Nacos 使用心跳機(jī)制來監(jiān)測節(jié)點(diǎn)的健康狀態(tài)。如果一個(gè)節(jié)點(diǎn)被認(rèn)為不健康，主節(jié)點(diǎn)可以將其標(biāo)記為不可用，從而避免不一致性。Nacos 也支持使用多數(shù)投票（Quorum）來進(jìn)行決策，確保操作的可靠性。

Eureka:
Eureka 是由 Netflix 開發(fā)的服務(wù)注冊(cè)與發(fā)現(xiàn)系統(tǒng)。其架構(gòu)和應(yīng)對(duì)腦裂問題的方式如下：

• 架構(gòu)： Eureka 由多個(gè)相互獨(dú)立的節(jié)點(diǎn)組成，每個(gè)節(jié)點(diǎn)都可以扮演服務(wù)器和客戶端角色。每個(gè)節(jié)點(diǎn)都會(huì)維護(hù)一個(gè)服務(wù)注冊(cè)表，記錄可用的服務(wù)實(shí)例。

• 應(yīng)對(duì)策略： Eureka 使用心跳和定時(shí)任務(wù)來監(jiān)測節(jié)點(diǎn)和服務(wù)實(shí)例的狀態(tài)。當(dāng)一個(gè)節(jié)點(diǎn)或?qū)嵗徽J(rèn)為不可用時(shí)，其他節(jié)點(diǎn)會(huì)進(jìn)行剔除或標(biāo)記。Eureka 在節(jié)點(diǎn)之間的通信中引入了"自我保護(hù)模式"，在網(wǎng)絡(luò)分區(qū)等情況下，可以避免錯(cuò)誤地移除健康實(shí)例。

Zookeeper:
Zookeeper 是一個(gè)分布式協(xié)調(diào)服務(wù)，可用于服務(wù)發(fā)現(xiàn)、配置管理等。其架構(gòu)和應(yīng)對(duì)腦裂問題的方式如下：

• 架構(gòu)： Zookeeper 使用集群架構(gòu)，每個(gè)節(jié)點(diǎn)都知道其他節(jié)點(diǎn)的狀態(tài)。集群中的節(jié)點(diǎn)會(huì)選舉一個(gè)主節(jié)點(diǎn)，其他節(jié)點(diǎn)作為從節(jié)點(diǎn)。

• 應(yīng)對(duì)策略： Zookeeper 使用心跳機(jī)制和選主算法來監(jiān)測節(jié)點(diǎn)的狀態(tài)和選舉主節(jié)點(diǎn)。在腦裂問題中，如果網(wǎng)絡(luò)分區(qū)導(dǎo)致主節(jié)點(diǎn)和從節(jié)點(diǎn)無法通信，Zookeeper 的主從選舉算法可以確保只有一個(gè)主節(jié)點(diǎn)被選出，從而避免數(shù)據(jù)的不一致性。

總體來說，Nacos、Eureka 和 Zookeeper 都考慮了腦裂問題，并采用了不同的機(jī)制來應(yīng)對(duì)，如心跳監(jiān)測、選主算法、多數(shù)投票等。無論選擇哪個(gè)工具或框架，都需要根據(jù)實(shí)際需求、性能要求和可靠性等因素來進(jìn)行選擇和配置。

三.分布式鎖

1.分布式鎖與單機(jī)鎖的區(qū)別？

分布式鎖和單機(jī)鎖之間有幾個(gè)關(guān)鍵區(qū)別，這些區(qū)別主要涉及到鎖的范圍、性能、可用性和實(shí)現(xiàn)復(fù)雜性等方面：

1. 鎖的范圍：

   • 單機(jī)鎖：單機(jī)鎖是在單個(gè)進(jìn)程或單個(gè)計(jì)算機(jī)上的線程之間使用的鎖。它們適用于單個(gè)應(yīng)用程序或單個(gè)進(jìn)程內(nèi)的并發(fā)控制。

   • 分布式鎖：分布式鎖用于在分布式系統(tǒng)中的多個(gè)進(jìn)程或計(jì)算機(jī)之間進(jìn)行并發(fā)控制。它們用于協(xié)調(diào)不同計(jì)算機(jī)上的線程，以確保在整個(gè)分布式系統(tǒng)中的互斥操作。

2. 性能：

   • 單機(jī)鎖：單機(jī)鎖通常比分布式鎖性能更高，因?yàn)樗鼈儾簧婕熬W(wǎng)絡(luò)通信和跨進(jìn)程的同步。單機(jī)鎖只需要在單個(gè)進(jìn)程內(nèi)部完成，開銷相對(duì)較低。

   • 分布式鎖：分布式鎖涉及到網(wǎng)絡(luò)通信，因此通常比單機(jī)鎖更消耗資源和時(shí)間。分布式鎖的性能通常不如單機(jī)鎖，但在分布式環(huán)境中是必要的。

3. 可用性：

   • 單機(jī)鎖：單機(jī)鎖的可用性受限于單個(gè)進(jìn)程或計(jì)算機(jī)的可用性。如果進(jìn)程或計(jì)算機(jī)崩潰或不可用，那么與之關(guān)聯(lián)的單機(jī)鎖也將不可用。

   • 分布式鎖：分布式鎖可以提高可用性，因?yàn)樗鼈兛梢栽诙鄠€(gè)計(jì)算機(jī)上復(fù)制。即使某個(gè)計(jì)算機(jī)或進(jìn)程不可用，其他計(jì)算機(jī)上的鎖仍然可以正常運(yùn)行。

4. 實(shí)現(xiàn)復(fù)雜性：

   • 單機(jī)鎖：單機(jī)鎖的實(shí)現(xiàn)通常較簡單，可以使用內(nèi)置的 Java 鎖（如synchronized）或標(biāo)準(zhǔn)庫中的鎖來輕松實(shí)現(xiàn)。

   • 分布式鎖：分布式鎖的實(shí)現(xiàn)較復(fù)雜，需要考慮網(wǎng)絡(luò)通信、故障恢復(fù)、一致性等因素。常見的分布式鎖實(shí)現(xiàn)包括基于數(shù)據(jù)庫、緩存、ZooKeeper 等技術(shù)，這些實(shí)現(xiàn)通常需要更多的工程和設(shè)計(jì)考慮。

分布式鎖和單機(jī)鎖之間的主要區(qū)別在于它們的范圍、性能、可用性和實(shí)現(xiàn)復(fù)雜性。選擇哪種類型的鎖取決于您的應(yīng)用程序需求和環(huán)境。在分布式系統(tǒng)中，使用分布式鎖可以確保多個(gè)進(jìn)程或計(jì)算機(jī)之間的數(shù)據(jù)一致性和互斥操作，但需要額外的開銷和復(fù)雜性。在單機(jī)環(huán)境中，通常使用單機(jī)鎖足以滿足并發(fā)控制的需求。

2.分布式鎖的特征？

• 高性能
• 可重入
• 線程互斥

分布式鎖是用于在分布式系統(tǒng)中實(shí)現(xiàn)同步和互斥操作的一種機(jī)制。它具有以下特征和屬性：

1. 互斥性（Mutual Exclusion）：分布式鎖確保在任何給定時(shí)間點(diǎn)只有一個(gè)客戶端或進(jìn)程可以持有鎖。這意味著一旦一個(gè)客戶端成功獲取鎖，其他客戶端將被阻止或排隊(duì)，直到鎖被釋放。

2. 可重入性（Reentrancy）：分布式鎖通常支持可重入性，允許同一個(gè)客戶端多次獲取同一個(gè)鎖，而不會(huì)發(fā)生死鎖。每次獲取鎖后，鎖計(jì)數(shù)器會(huì)遞增，而每次釋放鎖后，鎖計(jì)數(shù)器會(huì)遞減，直到為零才能完全釋放鎖。

3. 超時(shí)機(jī)制（Timeout）：分布式鎖通常支持超時(shí)機(jī)制，允許客戶端設(shè)置獲取鎖的超時(shí)時(shí)間。如果在指定的超時(shí)時(shí)間內(nèi)無法獲取鎖，客戶端可以選擇放棄或重試。

4. 阻塞和非阻塞模式：分布式鎖通常支持阻塞和非阻塞兩種模式。在阻塞模式下，如果無法獲取鎖，客戶端將被阻塞，直到鎖可用。在非阻塞模式下，如果無法獲取鎖，客戶端會(huì)立即返回，而不會(huì)阻塞。

5. 高可用性和容錯(cuò)性：分布式鎖通常具有高可用性和容錯(cuò)性。它們可以在多個(gè)節(jié)點(diǎn)上部署，以確保即使某些節(jié)點(diǎn)或資源不可用，鎖仍然可以正常工作。

6. 自動(dòng)釋放（Automatic Release）：分布式鎖通常支持自動(dòng)釋放機(jī)制，以防止鎖被長時(shí)間持有。客戶端通常需要在一段時(shí)間后自動(dòng)釋放鎖，以防止鎖被意外持有。

7. 實(shí)現(xiàn)方式多樣：有多種方式可以實(shí)現(xiàn)分布式鎖，包括基于數(shù)據(jù)庫、緩存、ZooKeeper、Redis 等技術(shù)。每種實(shí)現(xiàn)方式都有其自身的特點(diǎn)和適用場景。

8. 一致性保證：分布式鎖通常會(huì)考慮數(shù)據(jù)一致性的問題，以確保在多個(gè)節(jié)點(diǎn)上的鎖操作是一致的。這包括使用分布式事務(wù)或一致性協(xié)議來保證鎖的正確性。

分布式鎖是一種用于分布式系統(tǒng)中的并發(fā)控制的重要機(jī)制，具有互斥性、可重入性、超時(shí)機(jī)制、阻塞和非阻塞模式、高可用性、自動(dòng)釋放等特征。選擇合適的分布式鎖實(shí)現(xiàn)方式和配置參數(shù)取決于具體的應(yīng)用場景和需求。

3.分布式鎖的種類

分布式鎖是用于在分布式系統(tǒng)中實(shí)現(xiàn)同步和互斥操作的一種機(jī)制。有多種分布式鎖的實(shí)現(xiàn)方式，以下是一些常見的分布式鎖種類：

1. 基于數(shù)據(jù)庫的分布式鎖：可以使用數(shù)據(jù)庫的事務(wù)來實(shí)現(xiàn)分布式鎖。在這種方式下，數(shù)據(jù)庫表中的某一行記錄代表鎖，通過數(shù)據(jù)庫的事務(wù)來對(duì)這行記錄進(jìn)行加鎖和釋放鎖操作。通常使用數(shù)據(jù)庫的行級(jí)鎖來確保互斥性。

2. 基于緩存的分布式鎖：使用分布式緩存系統(tǒng)如 Redis 或 Memcached 來實(shí)現(xiàn)分布式鎖。在這種方式下，鎖的狀態(tài)通常是存儲(chǔ)在緩存中的，可以使用緩存的原子操作來實(shí)現(xiàn)鎖的獲取和釋放。

3. 基于 ZooKeeper 的分布式鎖：ZooKeeper 是一個(gè)分布式協(xié)調(diào)服務(wù)，可以用于實(shí)現(xiàn)分布式鎖。通過在 ZooKeeper 中創(chuàng)建臨時(shí)節(jié)點(diǎn)來表示鎖的狀態(tài)，可以確保在同一時(shí)刻只有一個(gè)客戶端能夠擁有這個(gè)鎖。

4. 基于文件系統(tǒng)的分布式鎖：使用共享文件系統(tǒng)（如 NFS）來實(shí)現(xiàn)分布式鎖。在這種方式下，鎖的狀態(tài)通常是存儲(chǔ)在共享文件系統(tǒng)上的文件或目錄，通過文件系統(tǒng)的鎖機(jī)制來實(shí)現(xiàn)互斥操作。

5. 基于分布式算法的分布式鎖：一些分布式算法（如基于 Paxos 或 Raft 的一致性算法）也可以用于實(shí)現(xiàn)分布式鎖。這些算法可以確保多個(gè)節(jié)點(diǎn)之間的數(shù)據(jù)一致性，從而實(shí)現(xiàn)分布式鎖。

6. 基于數(shù)據(jù)庫樂觀鎖的分布式鎖：使用數(shù)據(jù)庫中的樂觀鎖機(jī)制（例如，版本號(hào)或時(shí)間戳）來實(shí)現(xiàn)分布式鎖?？蛻舳藝L試通過更新數(shù)據(jù)庫記錄來獲取鎖，并檢查是否成功。這種方式下，需要處理沖突和重試。

7. 基于消息隊(duì)列的分布式鎖：使用分布式消息隊(duì)列來實(shí)現(xiàn)分布式鎖。鎖的狀態(tài)可以作為消息隊(duì)列中的消息來表示，通過消息隊(duì)列的原子性操作來實(shí)現(xiàn)鎖的獲取和釋放。

每種分布式鎖實(shí)現(xiàn)方式都有其優(yōu)點(diǎn)和局限性，選擇適合您應(yīng)用需求的方式取決于多個(gè)因素，包括性能、復(fù)雜性、可用性和一致性要求等。不同的應(yīng)用場景可能需要不同類型的分布式鎖。

4.分布式鎖的實(shí)現(xiàn)?

使用 ReentrantLock 的 tryLock 方法進(jìn)行加鎖,ReentrantLock 可以解決重入鎖的問題,進(jìn)而解決續(xù)期的問題。

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface RedisLock {
    String value() default "";

    @AliasFor("key")
    String name() default "";

    @AliasFor("name")
    String key() default "";

    long expire() default 30000; // 默認(rèn)鎖的過期時(shí)間，單位毫秒

    long timeout() default 0; // 默認(rèn)獲取鎖的超時(shí)時(shí)間，單位毫秒

    boolean fair() default false; // 是否使用公平鎖
}

@Aspect
@Component
@Order(1)  // 設(shè)置切面優(yōu)先級(jí)
public class RedisLockAspect {

    private final StringRedisTemplate redisTemplate;

    public RedisLockAspect(StringRedisTemplate redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    @Around("@annotation(redisLock)")
    public Object doWithLock(ProceedingJoinPoint joinPoint, RedisLock redisLock) throws Throwable {
        String lockKey = getLockKey(redisLock);
        Lock lock = new ReentrantLock(redisLock.fair());
        boolean locked = false;

        try {
            locked = lock.tryLock(redisLock.timeout(), TimeUnit.MILLISECONDS);
            if (locked) {
                if (StringUtils.hasText(lockKey)) {
                    redisTemplate.opsForValue().set(lockKey, "locked", redisLock.expire(), TimeUnit.MILLISECONDS);
                }
                return joinPoint.proceed();
            } else {
                throw new RuntimeException("Failed to acquire lock.");
            }
        } finally {
            if (locked) {
                lock.unlock();
                if (StringUtils.hasText(lockKey)) {
                    redisTemplate.delete(lockKey);
                }
            }
        }
    }

    private String getLockKey(RedisLock redisLock) {
        String lockKey = redisLock.key();
        if (!StringUtils.hasText(lockKey)) {
            lockKey = redisLock.name();
        }
        return lockKey;
    }
}

5.分布式鎖的續(xù)期?

分布式鎖的續(xù)期是指在某個(gè)持有分布式鎖的客戶端需要延長鎖的持有時(shí)間，以防止在執(zhí)行長時(shí)間操作時(shí)鎖過期導(dǎo)致其他客戶端獲取鎖并干擾正在進(jìn)行的操作。續(xù)期分布式鎖通常涉及以下步驟：

1. 獲取鎖： 客戶端通過某種機(jī)制（如 Redis 的SETNX命令）嘗試獲取分布式鎖。如果成功獲取鎖，那么鎖的持有者就是該客戶端。

2. 設(shè)置鎖的過期時(shí)間： 在獲取鎖成功后，客戶端可以通過設(shè)置鎖的過期時(shí)間來確保即使在某些情況下鎖沒有被顯式釋放，也能在一定時(shí)間后自動(dòng)釋放。這通常使用 Redis 的EXPIRE命令或類似的機(jī)制來完成。

3. 續(xù)期： 在客戶端持有鎖的過程中，如果該客戶端需要繼續(xù)執(zhí)行一些耗時(shí)的操作，可以選擇續(xù)期鎖的持有時(shí)間。續(xù)期通常涉及以下步驟：

   • 客戶端在執(zhí)行操作時(shí)，可以定期檢查自己是否還持有鎖，以避免過期。
   • 在續(xù)期時(shí)，客戶端可以通過更新鎖的過期時(shí)間，將鎖的持有時(shí)間延長。

   在 Redis 中，可以使用類似于EXPIRE命令的PEXPIRE（以毫秒為單位的過期時(shí)間）來更新鍵的過期時(shí)間，從而實(shí)現(xiàn)鎖的續(xù)期。

4. 釋放鎖： 當(dāng)客戶端操作完成后，它可以通過刪除鎖的方式來釋放鎖，或者讓鎖在過期時(shí)自動(dòng)釋放。

需要注意的是，分布式鎖的續(xù)期需要小心處理，以避免潛在的問題，如死鎖或者某個(gè)客戶端長時(shí)間持有鎖而不釋放。續(xù)期應(yīng)該在合理的時(shí)間間隔內(nèi)進(jìn)行，以確保其他等待獲取鎖的客戶端有機(jī)會(huì)獲得鎖資源。同時(shí)，續(xù)期操作可能會(huì)在某些極端情況下失敗，如網(wǎng)絡(luò)問題或鎖服務(wù)的故障，因此需要考慮異常情況的處理。

6.Redisson 分布式鎖公平鎖

在代碼和 Lua 中怎么做到加鎖、解鎖、鎖續(xù)期

Redisson 是一個(gè)基于 Redis 的分布式鎖框架，它提供了多種類型的分布式鎖，包括公平鎖。在 Redisson 中，公平鎖的實(shí)現(xiàn)會(huì)涉及到以下幾個(gè)關(guān)鍵概念：鎖的持有者、鎖的等待隊(duì)列、鎖的釋放與續(xù)期。下面是使用 Redisson 實(shí)現(xiàn)公平鎖的一些關(guān)鍵細(xì)節(jié)：

1. 加鎖：

使用 Redisson 實(shí)現(xiàn)公平鎖時(shí)，可以通過以下方式加鎖：

RLock fairLock = redisson.getFairLock("myFairLock");
fairLock.lock();
try {
    // 在這里執(zhí)行被鎖保護(hù)的代碼
} finally {
    fairLock.unlock();
}

這段代碼首先獲取一個(gè)公平鎖對(duì)象fairLock，然后調(diào)用lock()方法來獲取鎖。如果鎖當(dāng)前不可用，線程將被阻塞，直到鎖可用為止。一旦鎖可用，線程就可以執(zhí)行被鎖保護(hù)的代碼。請(qǐng)注意，使用try-finally塊確保鎖一定會(huì)被釋放，以防止死鎖。

2. 解鎖：

解鎖操作是自動(dòng)的，當(dāng)調(diào)用unlock()方法時(shí)，Redisson 會(huì)自動(dòng)釋放鎖。在上面的示例中，try-finally塊確保了在退出鎖保護(hù)的代碼塊后一定會(huì)釋放鎖。

3. 鎖續(xù)期：

Redisson 會(huì)自動(dòng)續(xù)期鎖的持有時(shí)間。如果一個(gè)線程在持有鎖時(shí)出現(xiàn)了長時(shí)間的阻塞（例如，由于執(zhí)行耗時(shí)的操作），Redisson 會(huì)定期為該鎖續(xù)期，以確保其他等待鎖的線程不會(huì)因?yàn)殒i的過期而獲取到鎖。

4. 實(shí)現(xiàn)細(xì)節(jié)：

Redisson 在底層使用了 Redis 的原子操作來實(shí)現(xiàn)鎖。它會(huì)使用 Lua 腳本來確保鎖的原子性操作。以下是一些細(xì)節(jié)：

• 當(dāng)一個(gè)線程嘗試獲取鎖時(shí)，Redisson 會(huì)生成一個(gè)唯一的標(biāo)識(shí)符（例如，UUID），然后將該標(biāo)識(shí)符與鎖關(guān)聯(lián)，并將其設(shè)置為鎖的值。
• 如果鎖已經(jīng)被其他線程持有，嘗試獲取鎖的線程會(huì)將自己加入到鎖的等待隊(duì)列中。
• 當(dāng)一個(gè)線程釋放鎖時(shí)，Redisson 會(huì)檢查鎖的值是否與其標(biāo)識(shí)符匹配，如果匹配，則釋放鎖；否則，鎖將保持不變，等待持有鎖的線程繼續(xù)執(zhí)行。
• 續(xù)期操作是通過定期更新鎖的過期時(shí)間來實(shí)現(xiàn)的。

使用 Redisson 可以很容易地實(shí)現(xiàn)分布式公平鎖，Redisson 會(huì)處理鎖的加鎖、解鎖和鎖的續(xù)期等細(xì)節(jié)，使得在分布式環(huán)境中實(shí)現(xiàn)鎖變得相對(duì)簡單。在底層，Redisson 利用了 Redis 強(qiáng)大的原子操作能力來確保鎖的正確性和一致性。

7.Redisson 分布式鎖非公平鎖

Redisson 支持非公平鎖（Unfair Lock），與公平鎖相比，非公平鎖允許多個(gè)線程爭奪鎖的時(shí)候，不一定按照先來后到的順序獲取鎖，而是按照競爭的速度獲取鎖。以下是使用 Redisson 實(shí)現(xiàn)非公平鎖的一些關(guān)鍵細(xì)節(jié)：

1. 加鎖：

使用 Redisson 實(shí)現(xiàn)非公平鎖時(shí)，可以通過以下方式加鎖：

RLock unfairLock = redisson.getLock("myUnfairLock");
unfairLock.lock();
try {
    // 在這里執(zhí)行被鎖保護(hù)的代碼
} finally {
    unfairLock.unlock();
}

這段代碼首先獲取一個(gè)非公平鎖對(duì)象unfairLock，然后調(diào)用lock()方法來獲取鎖。與公平鎖不同，非公平鎖不會(huì)保證等待鎖的線程按照先后順序獲取鎖，而是允許競爭速度更快的線程更早地獲取到鎖。

2. 解鎖：

解鎖操作與公平鎖一樣，也是自動(dòng)的。當(dāng)調(diào)用unlock()方法時(shí)，Redisson 會(huì)自動(dòng)釋放鎖。

3. 實(shí)現(xiàn)細(xì)節(jié)：

Redisson 在底層使用了 Redis 的原子操作來實(shí)現(xiàn)非公平鎖。以下是一些細(xì)節(jié)：

• 當(dāng)一個(gè)線程嘗試獲取鎖時(shí)，Redisson 會(huì)使用SET命令來嘗試將鎖的值設(shè)置為一個(gè)唯一的標(biāo)識(shí)符（例如，UUID）。
• 如果鎖已經(jīng)被其他線程持有，嘗試獲取鎖的線程將無法成功，但它不會(huì)進(jìn)入等待隊(duì)列，而是會(huì)立即返回。
• 當(dāng)一個(gè)線程釋放鎖時(shí)，Redisson 會(huì)檢查鎖的值是否與其標(biāo)識(shí)符匹配，如果匹配，則釋放鎖；否則，鎖將保持不變。

Redisson 可以輕松實(shí)現(xiàn)分布式非公平鎖，它使用 Redis 的原子操作來確保鎖的正確性和一致性。與公平鎖不同，非公平鎖允許多個(gè)線程競爭鎖，并且允許競爭速度更快的線程更早地獲取鎖，適用于某些場景下對(duì)性能更高要求的情況。

8.Redisson 實(shí)現(xiàn)分布式鎖讀寫鎖

Redisson 是一個(gè)基于 Redis 的分布式 Java 對(duì)象服務(wù)框架，它提供了分布式鎖的實(shí)現(xiàn)，包括讀寫鎖。下面是使用 Redisson 實(shí)現(xiàn)分布式讀寫鎖的一些關(guān)鍵細(xì)節(jié)：

1. 讀寫鎖的加鎖：

Redisson 提供了RLock接口用于表示分布式鎖，其中包括讀寫鎖。要使用讀寫鎖，可以通過以下方式加鎖：

RReadWriteLock rwLock = redisson.getReadWriteLock("myReadWriteLock");
RLock readLock = rwLock.readLock();
RLock writeLock = rwLock.writeLock();

// 獲取讀鎖
readLock.lock();
try {
    // 執(zhí)行讀操作
} finally {
    readLock.unlock();
}

// 獲取寫鎖
writeLock.lock();
try {
    // 執(zhí)行寫操作
} finally {
    writeLock.unlock();
}

這段代碼首先獲取一個(gè)讀寫鎖對(duì)象rwLock，然后從中分別獲取讀鎖readLock和寫鎖writeLock。讀鎖允許多個(gè)線程同時(shí)持有，而寫鎖是互斥的，只允許一個(gè)線程持有。

2. 讀寫鎖的釋放：

與通常的 Java 鎖一樣，Redisson 的讀寫鎖也要求在使用完畢后顯式釋放。在上面的示例中，使用了try-finally塊確保鎖一定會(huì)被釋放。

3. 實(shí)現(xiàn)細(xì)節(jié)：

Redisson 使用 Redis 的原子操作來實(shí)現(xiàn)讀寫鎖。以下是一些細(xì)節(jié)：

• 當(dāng)一個(gè)線程獲取讀鎖時(shí)，Redisson 會(huì)在 Redis 中記錄當(dāng)前持有讀鎖的線程數(shù)量，并且在鎖的值中增加一個(gè)標(biāo)識(shí)符，表示這個(gè)線程持有讀鎖。
• 當(dāng)一個(gè)線程獲取寫鎖時(shí)，Redisson 會(huì)將鎖的值設(shè)置為一個(gè)唯一的標(biāo)識(shí)符，表示這個(gè)線程持有寫鎖。此時(shí)，其他線程無法獲取讀鎖或?qū)戞i。
• 讀鎖和寫鎖在釋放時(shí)會(huì)根據(jù)鎖的類型（讀鎖或?qū)戞i）來更新鎖的值，并在不再持有鎖的情況下將其清除。

Redisson 還提供了一些其他功能，如讀鎖的重入性和鎖的自動(dòng)續(xù)期等，以增強(qiáng)鎖的功能?？傊琑edisson 使得在分布式環(huán)境中實(shí)現(xiàn)讀寫鎖變得相對(duì)簡單，使用了 Redis 的原子操作來確保鎖的正確性和一致性。

四.高并發(fā)高可用

1.什么是接口冪等性?

接口冪等性是指無論調(diào)用接口的次數(shù)是一次還是多次，對(duì)系統(tǒng)的影響都是相同的。換句話說，無論接口被調(diào)用多少次，最終的結(jié)果應(yīng)該是一致的。這個(gè)概念通常在分布式系統(tǒng)、Web 服務(wù)、API 設(shè)計(jì)等領(lǐng)域中討論，旨在確保系統(tǒng)的穩(wěn)定性、一致性和可靠性。

冪等性的一個(gè)常見用例是在進(jìn)行寫操作時(shí)，如創(chuàng)建、更新或刪除數(shù)據(jù)。在這些情況下，如果多次請(qǐng)求接口，結(jié)果都應(yīng)該是相同的，不會(huì)產(chǎn)生意外的重復(fù)操作或錯(cuò)誤。

舉個(gè)例子，考慮一個(gè)銀行轉(zhuǎn)賬的接口。無論你調(diào)用這個(gè)接口一次還是多次，最終賬戶的余額變化應(yīng)該是一樣的。如果接口在多次調(diào)用時(shí)引發(fā)了多次轉(zhuǎn)賬，可能會(huì)導(dǎo)致賬戶余額錯(cuò)誤或不一致。

確保接口冪等性通常需要以下一些方法：

1. 唯一標(biāo)識(shí)符： 在每次請(qǐng)求中使用唯一標(biāo)識(shí)符（如請(qǐng)求 ID、事務(wù) ID）來標(biāo)識(shí)每個(gè)請(qǐng)求。服務(wù)器端可以使用這些標(biāo)識(shí)符來檢測是否已經(jīng)處理過相同的請(qǐng)求。

2. 冪等操作設(shè)計(jì)： 設(shè)計(jì)接口的操作，使得多次執(zhí)行相同的操作不會(huì)產(chǎn)生額外的影響。例如，如果已經(jīng)創(chuàng)建了某個(gè)資源，再次創(chuàng)建同一個(gè)資源應(yīng)該返回相同的結(jié)果，而不會(huì)重復(fù)創(chuàng)建。

3. 事務(wù)和狀態(tài)管理： 對(duì)于需要修改系統(tǒng)狀態(tài)的操作，使用事務(wù)來確保一致性。事務(wù)可以在操作失敗時(shí)回滾之前的狀態(tài)，從而避免重復(fù)修改。

4. 冪等性檢測： 在服務(wù)器端檢測已經(jīng)處理過的請(qǐng)求，如果檢測到重復(fù)請(qǐng)求，則返回相同的結(jié)果而不會(huì)產(chǎn)生副作用。

5. 冪等性標(biāo)記： 為接口添加冪等性標(biāo)記，允許客戶端指定請(qǐng)求為冪等操作，從而通知服務(wù)器端在處理請(qǐng)求時(shí)保持冪等性。

6. 響應(yīng)和狀態(tài)碼： 使用適當(dāng)?shù)?HTTP 狀態(tài)碼和響應(yīng)來表示操作的結(jié)果。例如，對(duì)于重復(fù)的冪等請(qǐng)求，可以使用 200 OK 表示之前已經(jīng)執(zhí)行過相同的操作。

確保接口的冪等性對(duì)于分布式系統(tǒng)和 API 設(shè)計(jì)至關(guān)重要，它可以減少因網(wǎng)絡(luò)問題、重試或其他因素導(dǎo)致的數(shù)據(jù)不一致性和錯(cuò)誤。

2.冪等和防重提交的區(qū)別

冪等性（Idempotence）和防重提交（Prevent Duplicate Submissions）是兩個(gè)不同概念，它們通常用于描述不同方面的操作和處理，特別是在網(wǎng)絡(luò)和分布式系統(tǒng)中。下面我會(huì)為你解釋它們的區(qū)別：

1. 冪等性（Idempotence）：

   • 冪等性是指無論對(duì)同一個(gè)操作執(zhí)行多少次，結(jié)果都是一致的，也就是說，重復(fù)執(zhí)行相同的操作不會(huì)產(chǎn)生不同的效果。這對(duì)于網(wǎng)絡(luò)請(qǐng)求和分布式系統(tǒng)中的操作非常重要，因?yàn)樗梢源_保在網(wǎng)絡(luò)中的各種情況下，操作不會(huì)重復(fù)執(zhí)行或?qū)е乱馔獾母弊饔谩?/li>
   • 舉例：HTTP 請(qǐng)求方法中的 GET 和 DELETE 通常是冪等的，因?yàn)樗鼈儾粫?huì)更改服務(wù)器的狀態(tài)，并且多次執(zhí)行相同的請(qǐng)求不會(huì)產(chǎn)生不同的結(jié)果。

2. 防重提交（Prevent Duplicate Submissions）：

   • 防重提交是一種策略，用于防止用戶或系統(tǒng)在同一操作上重復(fù)提交數(shù)據(jù)。這通常與表單提交和數(shù)據(jù)更新有關(guān)。如果不采取防重提交措施，用戶可能會(huì)多次提交相同的表單或數(shù)據(jù)，導(dǎo)致不必要的重復(fù)操作。
   • 舉例：當(dāng)用戶提交一個(gè)在線表單時(shí)，服務(wù)器通常會(huì)生成一個(gè)唯一的標(biāo)識(shí)符（例如，令牌或會(huì)話 ID）并將其與提交的數(shù)據(jù)關(guān)聯(lián)起來。如果用戶再次提交相同的表單，服務(wù)器會(huì)檢查該標(biāo)識(shí)符，如果已經(jīng)處理過相同的請(qǐng)求，則拒絕重復(fù)提交。

總結(jié)：
冪等性強(qiáng)調(diào)相同操作的重復(fù)執(zhí)行不會(huì)改變結(jié)果，而防重提交則強(qiáng)調(diào)防止相同數(shù)據(jù)或請(qǐng)求的重復(fù)提交。在某些情況下，可以同時(shí)使用這兩個(gè)概念，以確保在網(wǎng)絡(luò)和分布式系統(tǒng)中的操作具有一致性并避免重復(fù)處理。

3.冪等在項(xiàng)目中的應(yīng)用?

冪等性在不同的應(yīng)用場景中具有重要作用：

冪等性是指對(duì)同一操作的多次執(zhí)行具有相同的效果，無論執(zhí)行多少次，結(jié)果都是一致的。這是在分布式系統(tǒng)中非常重要的概念，因?yàn)樵诰W(wǎng)絡(luò)通信中，消息可能會(huì)重復(fù)發(fā)送或處理。以下是一些應(yīng)用場景：

• 支付系統(tǒng)： 在金融領(lǐng)域，冪等性非常重要。例如，如果用戶多次點(diǎn)擊支付按鈕，系統(tǒng)應(yīng)該只執(zhí)行一次支付操作，而不會(huì)多次扣款。

• 消息隊(duì)列處理： 當(dāng)消息隊(duì)列用于分發(fā)任務(wù)或消息時(shí)，消費(fèi)者應(yīng)該能夠多次接收相同的消息，但只處理一次，以確保任務(wù)的冪等性。

• REST API 設(shè)計(jì)： 在設(shè)計(jì) RESTful API 時(shí)，應(yīng)該使 API 具有冪等性，以便客戶端可以多次調(diào)用相同的請(qǐng)求而不會(huì)產(chǎn)生不一致的結(jié)果。

在項(xiàng)目中，應(yīng)用冪等性具體方式取決于項(xiàng)目的需求和架構(gòu)。通常，使用冪等性可以確保系統(tǒng)在面對(duì)網(wǎng)絡(luò)中斷、消息重復(fù)或其他異常情況時(shí)仍然能夠保持一致性。

4.一致性 hash 在項(xiàng)目中的應(yīng)用?

一致性哈希是一種用于分布式數(shù)據(jù)存儲(chǔ)和負(fù)載均衡的技術(shù)，它允許數(shù)據(jù)在不同節(jié)點(diǎn)之間進(jìn)行分布，同時(shí)保持節(jié)點(diǎn)的動(dòng)態(tài)可擴(kuò)展性。以下是一些應(yīng)用場景：

• 分布式緩存： 一致性哈希可用于將緩存數(shù)據(jù)分布到多個(gè)緩存節(jié)點(diǎn)，以實(shí)現(xiàn)負(fù)載均衡和水平擴(kuò)展。

• 分布式數(shù)據(jù)庫： 在分布式數(shù)據(jù)庫中，一致性哈?？梢杂糜跊Q定將數(shù)據(jù)存儲(chǔ)在哪個(gè)節(jié)點(diǎn)上，同時(shí)支持節(jié)點(diǎn)的動(dòng)態(tài)添加和移除。

• 負(fù)載均衡： 一致性哈?？捎糜谠诜植际较到y(tǒng)中均勻地分布請(qǐng)求，以避免某些節(jié)點(diǎn)過載。

• 分布式文件系統(tǒng)： 一致性哈?？捎糜趯⑽募K分布到不同的存儲(chǔ)節(jié)點(diǎn)上，以實(shí)現(xiàn)高可用性和容錯(cuò)性。

一致性哈希則有助于解決負(fù)載均衡和分布式數(shù)據(jù)存儲(chǔ)的問題，提高系統(tǒng)的性能和可擴(kuò)展性。

5.什么是布隆過濾器?

布隆過濾器（Bloom Filter）是一種空間效率很高的概率數(shù)據(jù)結(jié)構(gòu)，用于判斷一個(gè)元素是否存在于一個(gè)集合中。它基于哈希函數(shù)，可以快速地進(jìn)行成員查詢，但是在查詢結(jié)果方面存在一定的概率性。

布隆過濾器的主要特點(diǎn)是：

1. 快速成員查詢： 布隆過濾器能夠在常數(shù)時(shí)間內(nèi)（與集合大小無關(guān)）進(jìn)行成員查詢，無需遍歷整個(gè)集合，因此在處理大量數(shù)據(jù)時(shí)速度非?？?。

2. 空間效率高： 布隆過濾器只需要使用很少的額外內(nèi)存空間來存儲(chǔ)元素信息，這使得它在存儲(chǔ)大量數(shù)據(jù)時(shí)占用的空間非常小。

3. 概率性判斷： 布隆過濾器在判斷元素存在時(shí)是概率性的，即可能存在誤判（判斷某個(gè)元素存在，但實(shí)際上不存在）和漏判（判斷某個(gè)元素不存在，但實(shí)際上存在）。

4. 不支持元素刪除： 布隆過濾器一般不支持從集合中刪除元素，因?yàn)閯h除操作可能影響到其他元素的判斷。

布隆過濾器的實(shí)現(xiàn)原理是通過一系列的哈希函數(shù)將每個(gè)元素映射到一個(gè)位數(shù)組（bit array）中的多個(gè)位置上，將這些位置置為 1。查詢時(shí)，將待查詢?cè)亟?jīng)過相同的哈希函數(shù)映射到位數(shù)組上，如果所有對(duì)應(yīng)位置都為 1，則認(rèn)為元素可能存在于集合中；如果有任何一個(gè)位置不為 1，則元素肯定不存在于集合中。

6.布隆過濾器作用?

由于布隆過濾器存在概率性誤判的問題，因此適用于對(duì)于判斷是否存在的問題，并且可以容忍一定的誤判率。常見的應(yīng)用包括：

• 緩存系統(tǒng)中判斷某個(gè)數(shù)據(jù)是否在緩存中，從而避免無效的數(shù)據(jù)庫查詢。
• 網(wǎng)絡(luò)爬蟲中避免重復(fù)爬取相同的 URL。
• 分布式系統(tǒng)中的去重操作，避免重復(fù)處理相同的數(shù)據(jù)。

需要注意的是，布隆過濾器不能提供精確的查詢結(jié)果，但在很多場景下，其高效的查詢速度和較小的內(nèi)存占用使其成為一個(gè)有價(jià)值的工具。

7.常見的分布式日志方案?

分布式日志方案是用于在分布式系統(tǒng)中管理、收集、存儲(chǔ)和分析日志數(shù)據(jù)的解決方案。這些方案旨在處理大量的日志數(shù)據(jù)，以便識(shí)別問題、監(jiān)控系統(tǒng)健康狀況和進(jìn)行數(shù)據(jù)分析。以下是一些常見的分布式日志方案：

1. ELK Stack（Elasticsearch, Logstash, Kibana）： ELK Stack 是一個(gè)開源的分布式日志處理方案，由 Elasticsearch 用于存儲(chǔ)和索引日志數(shù)據(jù)，Logstash 用于采集、處理和轉(zhuǎn)發(fā)日志，Kibana 用于展示和可視化日志數(shù)據(jù)。它們的組合可以提供強(qiáng)大的日志分析和查詢功能。

2. Graylog: Graylog 是一個(gè)開源的日志管理和分析平臺(tái)，提供收集、存儲(chǔ)、搜索和分析日志的功能。它支持高可用部署、靈活的數(shù)據(jù)處理流水線以及實(shí)時(shí)搜索和可視化。

3. Fluentd: Fluentd 是一個(gè)開源的日志收集和傳輸工具，用于將日志從不同的源傳輸?shù)讲煌哪繕?biāo)。它支持多種數(shù)據(jù)源和數(shù)據(jù)目標(biāo)，可以將日志聚合到中央存儲(chǔ)或分發(fā)到多個(gè)位置。

4. Splunk: Splunk 是一個(gè)商業(yè)的日志管理和分析平臺(tái)，可以用于收集、索引、搜索和分析大量的日志數(shù)據(jù)。它提供實(shí)時(shí)搜索、可視化、報(bào)表和警報(bào)功能，適用于大規(guī)模的日志分析需求。

5. Apache Kafka: 雖然 Kafka 主要是用于分布式消息傳遞，但它也可以用作日志收集工具。通過將日志數(shù)據(jù)發(fā)送到 Kafka 主題中，然后由訂閱者消費(fèi)和處理日志數(shù)據(jù)，可以實(shí)現(xiàn)分布式日志收集。

6. Prometheus: 雖然主要是一個(gè)監(jiān)控和報(bào)警系統(tǒng)，Prometheus 也可以用于日志收集。它提供強(qiáng)大的數(shù)據(jù)存儲(chǔ)和查詢能力，可用于存儲(chǔ)和查詢?nèi)罩緮?shù)據(jù)。

7. Apache Hadoop: Hadoop 生態(tài)系統(tǒng)中的組件，如 HDFS 和 HBase，可以用于存儲(chǔ)和管理大規(guī)模的日志數(shù)據(jù)。這對(duì)于需要進(jìn)行大數(shù)據(jù)分析的場景特別有用。

這些分布式日志方案都有其優(yōu)勢和適用場景，選擇適合自己需求的方案時(shí)，需要考慮數(shù)據(jù)量、性能需求、可用性、可視化和分析功能等因素。

8.簡介 prometheus

Prometheus 是一個(gè)開源的監(jiān)控和警報(bào)系統(tǒng)，旨在幫助用戶收集、存儲(chǔ)、查詢和可視化系統(tǒng)和服務(wù)的時(shí)間序列數(shù)據(jù)。它由 SoundCloud 開發(fā)并于 2012 年開源發(fā)布。Prometheus 是一個(gè)獨(dú)立的項(xiàng)目，但也與云原生生態(tài)系統(tǒng)和容器技術(shù)（如 Kubernetes）緊密集成。

以下是 Prometheus 的一些主要特點(diǎn)和功能：

1. 多維數(shù)據(jù)模型： Prometheus 使用具有標(biāo)簽（Label）的時(shí)間序列數(shù)據(jù)模型，這意味著每個(gè)樣本數(shù)據(jù)都帶有鍵-值對(duì)標(biāo)簽。這樣的模型支持多個(gè)維度的靈活查詢和聚合。

2. 數(shù)據(jù)采集和存儲(chǔ)： Prometheus 支持多種方式的數(shù)據(jù)采集，可以從各種應(yīng)用、服務(wù)、操作系統(tǒng)和中間件中收集指標(biāo)數(shù)據(jù)。收集的數(shù)據(jù)會(huì)存儲(chǔ)在本地的時(shí)間序列數(shù)據(jù)庫中。

3. 查詢語言： Prometheus 提供了 PromQL 查詢語言，可以用于從存儲(chǔ)的數(shù)據(jù)中進(jìn)行查詢、聚合和計(jì)算。PromQL 支持范圍查詢、聚合操作、數(shù)學(xué)計(jì)算等功能。

4. 數(shù)據(jù)可視化： Prometheus 可以與多種數(shù)據(jù)可視化工具集成，如 Grafana，用于創(chuàng)建儀表盤和圖表，以便對(duì)監(jiān)控?cái)?shù)據(jù)進(jìn)行直觀的可視化。

5. 告警和警報(bào)： Prometheus 具有強(qiáng)大的告警機(jī)制，可以根據(jù)指標(biāo)數(shù)據(jù)的閾值設(shè)置警報(bào)規(guī)則，并在條件滿足時(shí)觸發(fā)警報(bào)通知。

6. 自動(dòng)發(fā)現(xiàn)： Prometheus 支持自動(dòng)發(fā)現(xiàn)和目標(biāo)服務(wù)的配置，通過服務(wù)發(fā)現(xiàn)機(jī)制可以動(dòng)態(tài)地添加、刪除或更新監(jiān)控目標(biāo)。

7. 高度可擴(kuò)展： Prometheus 支持水平擴(kuò)展，可以通過添加更多的實(shí)例來處理更大規(guī)模的監(jiān)控工作負(fù)載。

8. 云原生集成： Prometheus 與云原生技術(shù)（如 Kubernetes）集成緊密，可以自動(dòng)發(fā)現(xiàn)和監(jiān)控容器、Pod 等資源。

Prometheus 在云原生生態(tài)系統(tǒng)中得到廣泛應(yīng)用，適用于監(jiān)控分布式系統(tǒng)、微服務(wù)架構(gòu)、容器化應(yīng)用等場景。它的靈活的數(shù)據(jù)模型、強(qiáng)大的查詢語言和可擴(kuò)展性使其成為了一個(gè)流行的監(jiān)控和告警解決方案。

9.簡介 Grafana

Grafana 是一個(gè)開源的數(shù)據(jù)可視化和監(jiān)控平臺(tái)，用于創(chuàng)建儀表盤、圖表和報(bào)表，幫助用戶將復(fù)雜的數(shù)據(jù)轉(zhuǎn)化為可視化的圖形形式，從而更直觀地理解數(shù)據(jù)。Grafana 最初是為 Graphite 設(shè)計(jì)的，但現(xiàn)在已經(jīng)成為一個(gè)通用的多數(shù)據(jù)源監(jiān)控和可視化平臺(tái)。

以下是 Grafana 的一些主要特點(diǎn)和功能：

1. 多數(shù)據(jù)源支持： Grafana 支持連接多種不同的數(shù)據(jù)源，包括時(shí)間序列數(shù)據(jù)庫（如 Prometheus、InfluxDB）、日志數(shù)據(jù)庫（如 Elasticsearch）、關(guān)系型數(shù)據(jù)庫（如 MySQL、PostgreSQL）等。

2. 豐富的可視化選項(xiàng)： Grafana 提供各種可視化選項(xiàng)，包括折線圖、柱狀圖、餅圖、儀表盤、地圖等，用戶可以根據(jù)需要選擇最適合的圖表類型。

3. 高度可定制： 用戶可以自定義圖表的樣式、顏色、標(biāo)簽等，以及儀表盤的布局和外觀，從而創(chuàng)建符合自己需求的數(shù)據(jù)可視化界面。

4. 告警和警報(bào)： Grafana 支持設(shè)置告警規(guī)則，當(dāng)指標(biāo)數(shù)據(jù)滿足預(yù)定義條件時(shí)，可以觸發(fā)警報(bào)通知，幫助用戶及時(shí)發(fā)現(xiàn)和解決問題。

5. 插件生態(tài)系統(tǒng)： Grafana 有豐富的插件生態(tài)系統(tǒng)，用戶可以通過插件擴(kuò)展功能，集成不同的數(shù)據(jù)源、圖表類型等。

6. 團(tuán)隊(duì)協(xié)作： Grafana 支持多用戶和團(tuán)隊(duì)協(xié)作，可以為不同用戶設(shè)置權(quán)限，共享儀表盤和報(bào)表。

7. 云原生支持： Grafana 可以與云原生技術(shù)（如 Kubernetes）緊密集成，通過自動(dòng)發(fā)現(xiàn)和監(jiān)控容器、Pod 等資源。

Grafana 的易用性和靈活性使其成為了一個(gè)受歡迎的數(shù)據(jù)可視化和監(jiān)控平臺(tái)。無論是在開發(fā)者、運(yùn)維人員，還是數(shù)據(jù)分析師等角色中，Grafana 都能夠幫助用戶更好地理解和利用數(shù)據(jù)。

五.分布式協(xié)議與算法

1.選舉算法

在分布式系統(tǒng)中采用的是主從架構(gòu)，也就是有一個(gè)主節(jié)點(diǎn)，若干個(gè)從節(jié)點(diǎn)。主節(jié)點(diǎn)可以執(zhí)行讀寫操作，從節(jié)點(diǎn)只執(zhí)行讀操作。采用這種一主多從的方案，可以有效保證了數(shù)據(jù)的一致性（哪怕不是強(qiáng)一致性，也能有效保證最終一致性）。

在開源的 Redis，MongoDB，Zookeeper 等軟件中也都采用了的選舉算法，常用的選舉算法有以下三種：Bully 算法，Raft 算法，ZAB 算法。

2.Bully 算法

Bully 算法是一種簡單直接的算法，因?yàn)樗倪x舉原則是取 ID 的最大值作為主節(jié)點(diǎn)。在 Bully 算法中，有兩種節(jié)點(diǎn)角色：普通節(jié)點(diǎn)和主節(jié)點(diǎn)。初始化的時(shí)候，所有節(jié)點(diǎn)都是普通節(jié)點(diǎn)。當(dāng)主節(jié)點(diǎn)掛掉了，才會(huì)發(fā)起下一輪選舉。

在選舉中，有三種消息，分別是Election消息，用于發(fā)起選舉。Alive消息，對(duì)Elelction消息的回復(fù)。Victory消息是選主成功后向其他節(jié)點(diǎn)發(fā)送的通知消息。選舉過程如下:

1. 集群中每個(gè)節(jié)點(diǎn)判斷一下自己的節(jié)點(diǎn) ID 是否為存活節(jié)點(diǎn)中最大，如果是則直接發(fā)送 Victory 消息，宣布自己為主節(jié)點(diǎn)。

2. 如果自己不是最大的 ID 節(jié)點(diǎn)，則向比自己大的節(jié)點(diǎn)發(fā)送 Election 消息，等待其他節(jié)點(diǎn)回復(fù)。

3. 在指定時(shí)間內(nèi)沒有收到其他節(jié)點(diǎn) Alive 信息，則認(rèn)為自己是主節(jié)點(diǎn)，然后向其他節(jié)點(diǎn)發(fā)送 Victory 消息，宣布自己是主節(jié)點(diǎn)。如果收到比自己 ID 大的節(jié)點(diǎn) Alive 消息，則等待其他節(jié)點(diǎn)發(fā)送 Victory 消息。

4. 如果收到比自己節(jié)點(diǎn) ID 小的消息，則回復(fù) Alive 消息，告訴對(duì)方重新選舉。

該算法簡單易于實(shí)現(xiàn)，但是當(dāng)頻繁有節(jié)點(diǎn)加入或退出，會(huì)造成頻繁主節(jié)點(diǎn)切換。當(dāng)應(yīng)用在節(jié)點(diǎn)數(shù)量穩(wěn)定的系統(tǒng)中，該算法的通用性可能還不錯(cuò)。此外，在 MongoDB 中故障遷移也采用了這個(gè)算法，它是采用最后操作的時(shí)間戳作為節(jié)點(diǎn) ID，在實(shí)際生產(chǎn)中，我們還可以使用啟動(dòng)的時(shí)間作為 ID。

3.Raft 算法

提起分布式系統(tǒng)，Raft 算法是一個(gè)基礎(chǔ)的算法。這種算法開創(chuàng)了投票選舉的先例。核心思想就是“少數(shù)服從多數(shù)”，獲得投票最多的節(jié)點(diǎn)就是主節(jié)點(diǎn)。

在 Raft 算法中，節(jié)點(diǎn)有三種角色：

• Leader：主節(jié)點(diǎn)，同一時(shí)刻只有一個(gè)主節(jié)點(diǎn)。

• Candidate:候選節(jié)點(diǎn)，節(jié)點(diǎn)處于該狀態(tài)才能選舉為 Leader 節(jié)點(diǎn)。

• Follower：Leader 節(jié)點(diǎn)的跟隨者，不能發(fā)起選舉。

Raft 選舉流程如下：

1. 初始化階段，每個(gè)節(jié)點(diǎn)都是 Follower 狀態(tài)。

2. 進(jìn)入選舉階段時(shí)，每個(gè)節(jié)點(diǎn)進(jìn)入 Candidate 狀態(tài)，并向其他節(jié)點(diǎn)發(fā)送選舉 Vote 請(qǐng)求。

3. 其他節(jié)點(diǎn)根據(jù)收到選舉請(qǐng)求的順序回復(fù)是否同意成為主節(jié)點(diǎn)，在每一輪選舉中每個(gè)候選人只有一張選票。

4. 若發(fā)起選舉的節(jié)點(diǎn)超過一半選票，則成為主節(jié)點(diǎn)，狀態(tài)轉(zhuǎn)換為 Leader，其他節(jié)點(diǎn)狀態(tài)有 Candidate 轉(zhuǎn)換為 Follower，leader 和 follower 之間有周期性的心跳包，用于檢測主節(jié)點(diǎn)存活。

5. Leader 節(jié)點(diǎn)的周期到了，會(huì)自動(dòng)降為 Follower，進(jìn)入下一輪選主。當(dāng)然了，當(dāng)前 Leader 節(jié)點(diǎn)掛掉了也會(huì)由 Follower 發(fā)起新一輪選舉。

目前集群管理容器 Kubernetes 采用的 etcd 組件就是采用 Raft 選舉算法進(jìn)行的?？傊琑aft 算法選舉速度快，缺點(diǎn)是要求系統(tǒng)內(nèi)每個(gè)節(jié)點(diǎn)都可以通信，因此通信容量大。

Nacos 中集群保證一致性算法采用 Raft 協(xié)議模式，采用心跳機(jī)制實(shí)現(xiàn)選舉的。

Raft 協(xié)議是分布式系統(tǒng)領(lǐng)域中的一種一致性算法，用于實(shí)現(xiàn)分布式系統(tǒng)中多個(gè)節(jié)點(diǎn)之間的一致性和協(xié)調(diào)。與 Paxos 等其他一致性算法相比，Raft 協(xié)議的設(shè)計(jì)更加直觀和易于理解，因此在教學(xué)和實(shí)際應(yīng)用中都得到了廣泛的關(guān)注和應(yīng)用。Raft 協(xié)議由 Diego Ongaro 和 John Ousterhout 在 2013 年提出。

Raft 協(xié)議的核心思想是將分布式一致性問題分解為三個(gè)關(guān)鍵的角色：領(lǐng)導(dǎo)者（Leader）、跟隨者（Follower）和候選人（Candidate）。協(xié)議的運(yùn)作分為以下幾個(gè)階段：

1. 領(lǐng)導(dǎo)者選舉（Leader Election）： 初始狀態(tài)下，所有節(jié)點(diǎn)都是候選人。候選人在一輪選舉中請(qǐng)求其他節(jié)點(diǎn)的選票，獲得大多數(shù)選票的候選人成為領(lǐng)導(dǎo)者。領(lǐng)導(dǎo)者負(fù)責(zé)提出日志條目和復(fù)制日志。

2. 日志復(fù)制（Log Replication）： 領(lǐng)導(dǎo)者負(fù)責(zé)提出日志條目，并將其廣播給其他節(jié)點(diǎn)。其他節(jié)點(diǎn)將接收到的日志條目存儲(chǔ)在本地日志中，并向領(lǐng)導(dǎo)者發(fā)送確認(rèn)。一旦領(lǐng)導(dǎo)者確認(rèn)大多數(shù)節(jié)點(diǎn)已經(jīng)存儲(chǔ)了特定的日志條目，該條目被視為“已提交”。

3. 安全性保障： Raft 協(xié)議通過約束性質(zhì)來確保安全性。具體來說，一個(gè)已經(jīng)提交的日志條目在以后的日志中不會(huì)被覆蓋或更改。

Raft 協(xié)議的主要目標(biāo)是確保以下性質(zhì)：

• 一致性： 在任何時(shí)間，所有節(jié)點(diǎn)的日志內(nèi)容是一致的。
• 可用性： 只要多數(shù)節(jié)點(diǎn)可用，系統(tǒng)就能夠接受讀取和寫入請(qǐng)求。
• 安全性： 只有領(lǐng)導(dǎo)者可以提出新的日志條目，而其他節(jié)點(diǎn)會(huì)遵循領(lǐng)導(dǎo)者的日志來保持一致。

Raft 協(xié)議的設(shè)計(jì)使得它相對(duì)于一些復(fù)雜的算法（如 Paxos）來說更容易理解和實(shí)現(xiàn)，因此在分布式系統(tǒng)領(lǐng)域得到了廣泛的應(yīng)用。許多開源項(xiàng)目和數(shù)據(jù)庫，如 etcd、CockroachDB 等，都使用了 Raft 協(xié)議作為底層的一致性算法。

4.ZAB 算法

ZAB算法英文叫 Zookeeper Atomic Broadcast，是改進(jìn)了 Raft 算法而用于zookeeper分布式協(xié)調(diào)服務(wù)的一種算法。這種算法引入了節(jié)點(diǎn) ID 和數(shù)據(jù) ID 作為參考進(jìn)行選擇主節(jié)點(diǎn)。節(jié)點(diǎn) ID 或數(shù)據(jù) ID 越大，表示數(shù)據(jù)越新。所以相比 Raft 算法，ZAB 算法盡可能保證了數(shù)據(jù)的最新。

ZAB 算法有三種角色：

• Laeder 節(jié)點(diǎn)。即主節(jié)點(diǎn)
• Follower 節(jié)點(diǎn)，也就是從節(jié)點(diǎn)。
• Obserer 節(jié)點(diǎn)，觀察節(jié)點(diǎn)，無投票權(quán)利。

選舉過程中，節(jié)點(diǎn)擁有四種狀態(tài)。分別是：

• Looking 狀態(tài)：即選舉狀態(tài)，當(dāng)進(jìn)入這種狀態(tài)，節(jié)點(diǎn)會(huì)認(rèn)為集群中沒有主節(jié)點(diǎn)，自己會(huì)進(jìn)入選舉狀態(tài)。
• Leading 狀態(tài)：表示已經(jīng)選出了主節(jié)點(diǎn)，當(dāng)前節(jié)點(diǎn)為 Leader。
• Following 狀態(tài)：表示集群中已經(jīng)選出了主節(jié)點(diǎn)，其他非主節(jié)點(diǎn)更新自己的狀態(tài)為 Following。
• Observer 狀態(tài)：當(dāng)前節(jié)點(diǎn)處于該狀態(tài)沒有投票和選舉權(quán)。

投票過程中,每個(gè)節(jié)點(diǎn)有一個(gè)唯一的三元組(server_id,server_zxid,epoch),其中 Server_id 代表當(dāng)前節(jié)點(diǎn)的 ID,server_zxid代表數(shù)據(jù)（事務(wù) id）,該值越大表示數(shù)據(jù)越新。epoch 為當(dāng)前選舉輪數(shù)。選舉原則為 server_zxid 最大為主節(jié)點(diǎn)，若相同則 server_id 最大為主節(jié)點(diǎn)。

該算法性能很好，對(duì)系統(tǒng)無特殊要求，一般采用廣播的方式發(fā)送消息。但是當(dāng)集群內(nèi)集群數(shù)據(jù)龐大，也容易出現(xiàn)網(wǎng)絡(luò)風(fēng)暴。此外，選舉過程需要節(jié)點(diǎn) ID 和數(shù)據(jù)事務(wù) ID，因此選舉周期可能稍長。不過有新節(jié)點(diǎn)的加入也不一定觸發(fā)新的選舉。

4.Paxos 協(xié)議

Paxos 協(xié)議是分布式系統(tǒng)領(lǐng)域中的一種一致性算法，用于在分布式系統(tǒng)中實(shí)現(xiàn)多個(gè)節(jié)點(diǎn)之間的一致性和協(xié)調(diào)。Paxos 協(xié)議由 Leslie Lamport 于 1989 年首次提出，它解決了分布式系統(tǒng)中的狀態(tài)機(jī)復(fù)制問題，即如何在不同節(jié)點(diǎn)之間復(fù)制和保持相同的狀態(tài)。

Paxos 協(xié)議的核心思想是通過投票和協(xié)商來達(dá)成共識(shí)，使得多個(gè)節(jié)點(diǎn)能夠就某個(gè)值達(dá)成一致意見。Paxos 協(xié)議分為多個(gè)階段，每個(gè)階段都有不同的角色和任務(wù)。主要包括以下幾個(gè)階段：

1. 提議階段（Prepare Phase）： 在這個(gè)階段，一個(gè)節(jié)點(diǎn)（稱為提議者）向其他節(jié)點(diǎn)發(fā)送一個(gè)提案，請(qǐng)求其他節(jié)點(diǎn)在不同條件下對(duì)提案進(jìn)行批準(zhǔn)或拒絕。提案包括提案編號(hào)和提議的值。

2. 批準(zhǔn)階段（Promise Phase）： 在收到提案后，其他節(jié)點(diǎn)（稱為接收者）會(huì)比較提案編號(hào)，如果提案編號(hào)更高且沒有承諾過其他提案，則接收者會(huì)向提議者發(fā)送一個(gè)承諾，表示愿意接受提案。

3. 提交階段（Accept Phase）： 如果提議者收到足夠的承諾，表示提案可以提交。提議者向所有節(jié)點(diǎn)發(fā)送提案，并要求節(jié)點(diǎn)接受該提案作為共識(shí)值。

Paxos 協(xié)議的主要目標(biāo)是保證以下性質(zhì)：

• 一致性： 所有正確的節(jié)點(diǎn)最終都會(huì)達(dá)成相同的共識(shí)值。
• 安全性： 如果一個(gè)值被選定為共識(shí)值，那么它一定是一個(gè)被提議者提出過的值。
• 活性： 只要大多數(shù)節(jié)點(diǎn)是正確的，提案最終會(huì)被選定為共識(shí)值。

盡管 Paxos 協(xié)議是一個(gè)經(jīng)典的一致性算法，但其復(fù)雜性使得理解和實(shí)現(xiàn)都具有一定難度。因此，許多分布式系統(tǒng)和數(shù)據(jù)庫在實(shí)際中使用了基于 Paxos 的變種或改進(jìn)，如 Multi-Paxos、Fast Paxos、Zookeeper 中的 Zab 協(xié)議等，來滿足分布式一致性需求。

5.選舉算法對(duì)比

1.zookeeper 主從選舉

zookeeper 作為一個(gè)分布式應(yīng)用程序協(xié)調(diào)服務(wù)，在大型網(wǎng)站中，其本身也是集群部署的，安裝 zookeeper 的時(shí)候最好是單數(shù)節(jié)點(diǎn)，因?yàn)橐x舉。Zookeeper 的 leader 節(jié)點(diǎn)是集群工作的核心，用來更新并保證 leader 和 server 具有相同的系統(tǒng)狀態(tài)，F(xiàn)ollower 服務(wù)器是 leader 的跟隨者，用于接收客戶端的請(qǐng)求并向客戶端返回結(jié)果，在選舉過程中參與投票。對(duì)于客戶端而言，每個(gè) zookeeper 都是一樣的。

zookeeper 提供了三種選舉策略：

• LeaderElection
• AuthFastLeaderElection
• FastLeaderElection

下面主要講解 FastLeaderElection 的選舉原理
1.myId
每個(gè) ZooKeeper 服務(wù)器，都需要在數(shù)據(jù)文件夾下創(chuàng)建一個(gè)名為 myid 的文件，該文件包含整個(gè) ZooKeeper 集群唯一的 ID（整數(shù)）。例如，某 ZooKeeper 集群包含三臺(tái)服務(wù)器，hostname 分別為 zoo1、zoo2 和 zoo3，其 myid 分別為 1、2 和 3，則在配置文件中其 ID 與 hostname 必須一一對(duì)應(yīng)，如下所示。在該配置文件中，server. 后面的數(shù)據(jù)即為 myid

server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888

2.zxid
服務(wù)器的事務(wù) id，數(shù)據(jù)越新，zxid 越大；

3.epoch
邏輯時(shí)鐘，在服務(wù)端是一個(gè)自增序列，每次進(jìn)入下一輪投票后，就會(huì)加 1；

4.服務(wù)器狀態(tài)

• LOOKING： 不確定 Leader 狀態(tài)。該狀態(tài)下的服務(wù)器認(rèn)為當(dāng)前集群中沒有 Leader，會(huì)發(fā)起 Leader 選舉。
• FOLLOWING： 跟隨者狀態(tài)。表明當(dāng)前服務(wù)器角色是 Follower，并且知道 Leader 是誰。
• LEADING： 領(lǐng)導(dǎo)者狀態(tài)。表明當(dāng)前服務(wù)器角色為 Leader 角色，它會(huì)維護(hù)與 Follower 間的心跳。
• OBSERVING： 觀察者狀態(tài)。表明當(dāng)前服務(wù)器角色是 Observer，與 Follower 的唯一不同在于不參與選舉，也不參與集群寫操作時(shí)的投票。

5.選票的數(shù)據(jù)結(jié)構(gòu)
每個(gè)服務(wù)器在進(jìn)行領(lǐng)導(dǎo)選舉時(shí)，會(huì)發(fā)送如下關(guān)鍵信息：

• logicClock 每個(gè)服務(wù)器會(huì)維護(hù)一個(gè)自增的整數(shù)，名為 logicClock，它表示這是該服務(wù)器發(fā)起的第多少輪投票。
• state 當(dāng)前服務(wù)器的狀態(tài)。
• self_id 當(dāng)前服務(wù)器的 myid。
• self_zxid 當(dāng)前服務(wù)器上所保存的數(shù)據(jù)的最大 zxid。
• vote_id 被推舉的服務(wù)器的 myid。
• vote_zxid 被推舉的服務(wù)器上所保存的數(shù)據(jù)的最大 zxid。

6.投票流程
當(dāng)系統(tǒng)啟動(dòng)或者 leader 崩潰后，就會(huì)開始 leader 的選舉。

1. 狀態(tài)變更。服務(wù)器啟動(dòng)的時(shí)候每個(gè) server 的狀態(tài)時(shí) Looking，如果是 leader 掛掉后進(jìn)入選舉，那么余下的非 Observer 的 Server 就會(huì)將自己的服務(wù)器狀態(tài)變更為 Looking，然后開始進(jìn)入 Leader 的選舉狀態(tài)；

2. 發(fā)起投票。每個(gè) server 會(huì)產(chǎn)生一個(gè)（myid，zxid）的投票，系統(tǒng)初始化的時(shí)候 zxid 都是 0，如果是運(yùn)行期間，每個(gè) server 的 zxid 可能都不同，這取決于最后一次更新的數(shù)據(jù)。將投票發(fā)送給集群中的所有機(jī)器；

3. 接收并檢查投票。server 收到投票后，會(huì)先檢查是否是本輪投票，是否來自 looking 狀態(tài)的 server；

4. 處理投票。對(duì)自己的投票和接收到的投票進(jìn)行 PK：

5. 先檢查zxid，較大的優(yōu)先為leader
   如果zxid一樣，myid較大的為leader
   根據(jù)PK結(jié)果更新自己的投票，在次發(fā)送自己的投票
   

6. 統(tǒng)計(jì)投票。每次投票后，服務(wù)器統(tǒng)計(jì)投票信息，如果有過半機(jī)器接收到相同的投票，那么 leader 產(chǎn)生，如果否，那么進(jìn)行下一輪投票；

7. 改變 server 狀態(tài)，一旦確定了 Leader，server 會(huì)更新自己的狀態(tài)為 Following，選舉結(jié)束。

補(bǔ)充說明：

1. 在步驟 2 發(fā)送投票的時(shí)候，投票的信息除了 myid 和 zxid，還有：
   • electionEpoch：邏輯時(shí)鐘，用來判斷多個(gè)投票是否在同一輪選舉周期中，該值在服務(wù)端是一個(gè)自增序列，每次進(jìn)入新一輪的投票后，都會(huì)對(duì)該值進(jìn)行加 1 操作。
   • peerEpoch：被推舉的 Leader 的 epoch。
   • state：當(dāng)前服務(wù)器的狀態(tài)。
2. 為了能夠相互投票，每兩臺(tái)服務(wù)器之間都會(huì)建立網(wǎng)絡(luò)連接，為避免重復(fù)建立 TCP 連接，zk 的 server 只允許 myid 大于自己的服務(wù)器與自己建立連接，否則斷開當(dāng)前連接，并主動(dòng)和對(duì)方建立連接。

2.ES master 選舉

選舉時(shí)間點(diǎn)
Elasticsearch 在滿足如下時(shí)間點(diǎn)的時(shí)候會(huì)觸發(fā)選舉

1. 集群啟動(dòng)初始化。
2. 集群 Master 崩潰的時(shí)候。
3. 任何一個(gè)節(jié)點(diǎn)發(fā)現(xiàn)當(dāng)前集群中 Master 節(jié)點(diǎn)沒有得到 n/2+1 個(gè)節(jié)點(diǎn)的認(rèn)可的時(shí)候，觸發(fā)選舉。

選舉流程
1.篩選 activeMaster 列表
Es 的 master 就是從 activeMasters 列表或者 masterCandidates（master 候選節(jié)點(diǎn)）列表選舉出來，所以選舉之前 es 首先需要得到這兩個(gè)列表。Elasticsearch 節(jié)點(diǎn)成員首先向集群中的所有成員發(fā)送 Ping 請(qǐng)求，elasticsearch 默認(rèn)等待 discovery.zen.ping_timeout 時(shí)間，然后 elasticsearch 針對(duì)獲取的全部 response 進(jìn)行過濾，篩選出其中 activeMasters 列表，activeMaster 列表是其它節(jié)點(diǎn)認(rèn)為的當(dāng)前集群的 Master 節(jié)點(diǎn)。

源碼如下：

List<DiscoveryNode> activeMasters = new ArrayList<>();
for (ZenPing.PingResponse pingResponse : pingResponses) {
    //不允許將自己放在activeMasters列表中
    if (pingResponse.master() != null && !localNode.equals(pingResponse.master())) {
        activeMasters.add(pingResponse.master());
    }
}

可以看到 elasticsearch 在獲取 activeMasters 列表的時(shí)候會(huì)排除本地節(jié)點(diǎn)，目的是為了避免腦裂，假設(shè)這樣一個(gè)場景，當(dāng)前最小編號(hào)的節(jié)點(diǎn) P0 認(rèn)為自己就是 master 并且 P0 和其它節(jié)點(diǎn)發(fā)生網(wǎng)絡(luò)分區(qū)，同時(shí) es 允許將自己放在 activeMaster 中，因?yàn)?P0 編號(hào)最小，那么 P0 永遠(yuǎn)會(huì)選擇自己作為 master 節(jié)點(diǎn)，那么就會(huì)出現(xiàn)腦裂的情況。

2.篩選 masterCandidates 列表
masterCandidates 列表是當(dāng)前集群有資格成為 Master 的節(jié)點(diǎn)，如果我們?cè)?elasticsearch.yml 中配置了如下參數(shù)，那么這個(gè)節(jié)點(diǎn)就沒有資格成為 Master 節(jié)點(diǎn)，也就不會(huì)被篩選進(jìn)入 masterCandidates 列表。

# 配置某個(gè)節(jié)點(diǎn)沒有成為master資格
node.master:false

源代碼如下所示：

List<ElectMasterService.MasterCandidate> masterCandidates = new ArrayList<>();
for (ZenPing.PingResponse pingResponse : pingResponses) {
    if (pingResponse.node().isMasterNode()) {
        masterCandidates.add(new ElectMasterService.MasterCandidate(pingResponse.node(), 		    pingResponse.getClusterStateVersion()));
    }
}

3.從 activeMasters 列表選舉 Master 節(jié)點(diǎn)
activeMaster 列表是其它節(jié)點(diǎn)認(rèn)為的當(dāng)前集群的 Master 節(jié)點(diǎn)列表，如果 activeMasters 列表不為空，elasticsearch 會(huì)優(yōu)先從 activeMasters 列表中選舉，選舉的算法是 Bully 算法，Bully 算法會(huì)涉及到優(yōu)先級(jí)比較， 在 activeMasters 列表優(yōu)先級(jí)比較的時(shí)候，如果節(jié)點(diǎn)有成為 master 的資格，那么優(yōu)先級(jí)比較高，如果 activeMaster 列表有多個(gè)節(jié)點(diǎn)具有 master 資格，那么選擇 id 最小的節(jié)點(diǎn)。

代碼如下：

private static int compareNodes(DiscoveryNode o1, DiscoveryNode o2) {
    if (o1.isMasterNode() && !o2.isMasterNode()) {
        return -1;
    }
    if (!o1.isMasterNode() && o2.isMasterNode()) {
        return 1;
    }
    return o1.getId().compareTo(o2.getId());
}

//取ID最小的
public DiscoveryNode tieBreakActiveMasters(Collection<DiscoveryNode> activeMasters) {
    return activeMasters.stream().min(ElectMasterService::compareNodes).get();
}

4.從 masterCandidates 列表選舉 Master 節(jié)點(diǎn)
如果 activeMaster 列表為空，那么會(huì)在 masterCandidates 中選舉，masterCandidates 選舉也會(huì)涉及到優(yōu)先級(jí)比較，masterCandidates 選舉的優(yōu)先級(jí)比較和 activemasters 選舉的優(yōu)先級(jí)比較不同。它首先會(huì)判斷 masterCandidates 列表成員數(shù)目是否達(dá)到了最小數(shù)目 discovery.zen.minimum_master_nodes。如果達(dá)到的情況下比較優(yōu)先級(jí)，優(yōu)先級(jí)比較的時(shí)候首先比較節(jié)點(diǎn)擁有的集群狀態(tài)版本編號(hào)，然后再比較 id，這一流程的目的是讓擁有最新集群狀態(tài)的節(jié)點(diǎn)成為 master。

代碼如下：

public static int compare(MasterCandidate c1, MasterCandidate c2) {
    //比較集群狀態(tài)版本編碼，取版本大的，使擁有集群最新狀態(tài)的節(jié)點(diǎn)成為master
    int ret = Long.compare(c2.clusterStateVersion, c1.clusterStateVersion);
    //如果版本號(hào)一樣，則比較ID
    if (ret == 0) {
        ret = compareNodes(c1.getNode(), c2.getNode());
    }
    return ret;
}

5.本地節(jié)點(diǎn)是 master
經(jīng)過上述選舉之后，會(huì)選舉出一個(gè)準(zhǔn) master 節(jié)點(diǎn)， 準(zhǔn) master 節(jié)點(diǎn)會(huì)等待其它節(jié)點(diǎn)的投票，如果有 discovery.zen.minimum_master_nodes-1 個(gè)節(jié)點(diǎn)投票認(rèn)為當(dāng)前節(jié)點(diǎn)是 master，那么選舉就成功，準(zhǔn) master 會(huì)等待 discovery.zen.master_election.wait_for_joins_timeout 時(shí)間，如果超時(shí)，那么就失敗。在代碼實(shí)現(xiàn)上準(zhǔn) master 通過注冊(cè)一個(gè)回調(diào)來實(shí)現(xiàn)，同時(shí)借助了 AtomicReference 和 CountDownLatch 等并發(fā)構(gòu)建實(shí)現(xiàn)

if (clusterService.localNode().equals(masterNode)) {
final int requiredJoins = Math.max(0, electMaster.minimumMasterNodes() - 1);
nodeJoinController.waitToBeElectedAsMaster(requiredJoins, masterElectionWaitForJoinsTimeout,
        new NodeJoinController.ElectionCallback() {
            @Override
            public void onElectedAsMaster(ClusterState state) {
                joinThreadControl.markThreadAsDone(currentThread);
                nodesFD.updateNodesAndPing(state); // start the nodes FD
            }
            @Override
            public void onFailure(Throwable t) {
                logger.trace("failed while waiting for nodes to join, rejoining", t);
                joinThreadControl.markThreadAsDoneAndStartNew(currentThread);
            }
        }
);

本地節(jié)點(diǎn)是 Master 的時(shí)候，Master 節(jié)點(diǎn)會(huì)開啟錯(cuò)誤檢測 (NodeFaultDetection 機(jī)制)，它節(jié)點(diǎn)會(huì)定期掃描集群所有的成員，將失活的成員移除集群，同時(shí)將最新的集群狀態(tài)發(fā)布到集群中，集群成員收到最新的集群狀態(tài)后會(huì)進(jìn)行相應(yīng)的調(diào)整，比如重新選擇主分片，進(jìn)行數(shù)據(jù)復(fù)制等操作。

6.本地節(jié)點(diǎn)不是 master
當(dāng)前節(jié)點(diǎn)判定在集群當(dāng)前狀態(tài)下如果自己不可能是 master 節(jié)點(diǎn)，首先會(huì)禁止其他節(jié)點(diǎn)加入自己，然后投票選舉出準(zhǔn) Master 節(jié)點(diǎn)。同時(shí)監(jiān)聽 master 發(fā)布的集群狀態(tài) (MasterFaultDetection 機(jī)制)，如果集群狀態(tài)顯示的 master 節(jié)點(diǎn)和當(dāng)前節(jié)點(diǎn)認(rèn)為的 master 節(jié)點(diǎn)不是同一個(gè)節(jié)點(diǎn)，那么當(dāng)前節(jié)點(diǎn)就重新發(fā)起選舉。

非 Master 節(jié)點(diǎn)也會(huì)監(jiān)聽 Master 節(jié)點(diǎn)進(jìn)行錯(cuò)誤檢測，如果成員節(jié)點(diǎn)發(fā)現(xiàn) master 連接不上，重新加入新的 Master 節(jié)點(diǎn)，如果發(fā)現(xiàn)當(dāng)前集群中有很多節(jié)點(diǎn)都連不上 master 節(jié)點(diǎn)，那么會(huì)重新發(fā)起選舉。

3.Redis 哨兵選舉

哨兵的工作方式：

1. 每個(gè) Sentinel（哨兵）進(jìn)程以每秒一次的頻率向整個(gè)集群中的 Master 主服務(wù)器、Slave 從服務(wù)器以及其他哨兵進(jìn)程發(fā)送一個(gè) PING 命令。

2. 如果一個(gè)實(shí)例距離最后一次有效回復(fù) PING 命令的時(shí)間超過 down-after-milliseconds 選型所指定的值，則這個(gè)實(shí)例會(huì)被哨兵進(jìn)程標(biāo)記為主觀下線。

3. 如果一個(gè) Master 主服務(wù)器被標(biāo)記為主觀下線，則正在監(jiān)視這個(gè) Master 主服務(wù)器的所有哨兵進(jìn)程要以每秒一次的頻率來確認(rèn) Master 主服務(wù)器是否的確進(jìn)入了主觀下線狀態(tài)。

4. 如果有足夠數(shù)量（quorum 數(shù)量）的哨兵進(jìn)程認(rèn)為 Master 主服務(wù)器下線，則 Master 主服務(wù)器會(huì)被標(biāo)記成客觀下線。

5. 在一般情況下，每個(gè)哨兵進(jìn)程以每秒一次的頻率向集群中的所有 master 主服務(wù)器、Slave 從服務(wù)器發(fā)送 Info 命令。當(dāng) Master 主服務(wù)器被標(biāo)記為客觀下線后，Info 命令的頻率從 10 秒一次改成 1 秒一次。

6. 若沒有足夠數(shù)量的 Sentinel（哨兵）進(jìn)程同意 Master 主服務(wù)器下線， Master 主服務(wù)器的客觀下線狀態(tài)就會(huì)被移除。若 Master 主服務(wù)器重新向 Sentinel（哨兵）進(jìn)程發(fā)送 PING 命令返回有效回復(fù)，Master 主服務(wù)器的主觀下線狀態(tài)就會(huì)被移除。

選舉方式：
如果一個(gè) Master 主服務(wù)器被標(biāo)記為客觀下線，并且 Majority 數(shù)量的哨兵都允許進(jìn)行主備切換（如果沒有 Majority 數(shù)量的哨兵同一主備切換時(shí)，是不允許進(jìn)行主備切換的），選舉一個(gè)領(lǐng)頭的哨兵進(jìn)行主備切換。

選舉領(lǐng)頭的哨兵
選舉領(lǐng)頭 sentinel 遵循以下規(guī)則：

1. 所有的 sentinel 都有公平被選擇成領(lǐng)頭的資格。

2. 所有的 sentinel 都只有一次將某個(gè) sentinel 選舉成領(lǐng)頭的機(jī)會(huì)（在一輪選舉中），一旦選舉，則不能修改。

3. 先到先得，一旦當(dāng)前 sentinel 設(shè)置了領(lǐng)頭 sentinel，以后要求設(shè)置 sentinel 都會(huì)被拒絕。

4. 每個(gè)發(fā)現(xiàn)服務(wù)器客觀下線的哨兵，都會(huì)要求其他哨兵將自己設(shè)置成領(lǐng)頭哨兵。

5. 當(dāng)一個(gè)哨兵（源哨兵）向另一個(gè)哨兵（目標(biāo)哨兵）發(fā)送is-master-down-by-addr ip port current_epoch runid命令的時(shí)候，runid 參數(shù)不是*，而是sentinel運(yùn)行 id，就表示源sentinel要求目標(biāo)sentinel選舉其為領(lǐng)頭。

6. 源哨兵會(huì)檢查目標(biāo)哨兵對(duì)其設(shè)置成領(lǐng)頭的回復(fù)，如果回復(fù)的leader_runid和leader_epoch為源哨兵，表示目標(biāo)哨兵同意將源哨兵設(shè)置成領(lǐng)頭。

7. 如果某個(gè)哨兵被半數(shù)以上的哨兵設(shè)置成領(lǐng)頭哨兵，則該哨兵就成為領(lǐng)頭哨兵。

8. 如果在限定時(shí)間內(nèi)，沒有選舉出領(lǐng)頭哨兵，暫停一段時(shí)間，再選舉。

Master 主服務(wù)器選舉

領(lǐng)頭哨兵會(huì)對(duì)已客觀宕機(jī)的 Master 主服務(wù)器和 Slave 從服務(wù)器進(jìn)行主備切換。
選舉 Slave 需要考慮以下的信息：

1. 如果一個(gè)slave跟master斷開連接的時(shí)間已經(jīng)超過了down-after-milliseconds的 10 倍，外加 master 宕機(jī)的時(shí)長，那么認(rèn)為該slave不適合選舉為master。

2. 按照slave的優(yōu)先級(jí)進(jìn)行排序，slave priority越低，優(yōu)先級(jí)越高。

3. 如果slave的優(yōu)先級(jí)一致，那么看replica offset，哪個(gè) slave 復(fù)制了越多的數(shù)據(jù)，offset越靠后，優(yōu)先級(jí)就越高。

4. 如果優(yōu)先級(jí)和offset都一樣，那么選擇一個(gè)run ID比較小的那個(gè)slave。

4.Redis cluster 選舉

判斷節(jié)點(diǎn)宕機(jī)

如果一個(gè)節(jié)點(diǎn)認(rèn)為另外一個(gè)節(jié)點(diǎn)宕機(jī)，那么就是 pfail ，主觀宕機(jī)。如果多個(gè)節(jié)點(diǎn)都認(rèn)為另外一個(gè)節(jié)點(diǎn)宕機(jī)了，那么就是 fail ，客觀宕機(jī)，跟哨兵的原理幾乎一樣，sdown，odown。

在 cluster-node-timeout 內(nèi)，某個(gè)節(jié)點(diǎn)一直沒有返回 pong ，那么就被認(rèn)為 pfail 。

如果一個(gè)節(jié)點(diǎn)認(rèn)為某個(gè)節(jié)點(diǎn) pfail 了，那么會(huì)在 gossip ping 消息中， ping 給其他節(jié)點(diǎn)，如果超過半數(shù)的節(jié)點(diǎn)都認(rèn)為 pfail 了，那么就會(huì)變成 fail 。

Redis Cluster Master 主服務(wù)器選舉：
對(duì)宕機(jī)的 master node，從其所有 slave node 中，選擇一個(gè)切換成 master node。

1. 檢查每個(gè)slave node與 master node 斷開連接的時(shí)間，如果超過了 cluster-node-timeout * cluster-slave-validity-factor，那么沒有資格切換成 master。

2. 每個(gè)從節(jié)點(diǎn)，根據(jù)自己對(duì) master 復(fù)制數(shù)據(jù)的offset，來設(shè)置一個(gè)選舉時(shí)間，offset越大（復(fù)制的數(shù)據(jù)越多）的從節(jié)點(diǎn)，選舉時(shí)間越靠前，優(yōu)先進(jìn)行選舉。

3. 所有的master node開始slave選舉投票，給要進(jìn)行選舉的slave node進(jìn)行投票，如果大部分master(N/2+1)都投票給某個(gè)從節(jié)點(diǎn)，那么選舉通過，那個(gè)從節(jié)點(diǎn)可以切換成master。

4. 從節(jié)點(diǎn)進(jìn)行主備切換，從節(jié)點(diǎn)切換成主節(jié)點(diǎn)。

5.kafka parition 選舉

Kafka 的 Leader 選舉是通過在 zookeeper 上創(chuàng)建 /controller 臨時(shí)節(jié)點(diǎn)來實(shí)現(xiàn) leader 選舉，并在該節(jié)點(diǎn)中寫入當(dāng)前 broker 的信息 {“version”:1,”brokerid”:1,”timestamp”:”1512018424988”}。利用 Zookeeper 的強(qiáng)一致性特性，一個(gè)節(jié)點(diǎn)只能被一個(gè)客戶端創(chuàng)建成功，創(chuàng)建成功的 broker 即為 leader，即先到先得原則，leader 也就是集群中的 controller，負(fù)責(zé)集群中所有大小事務(wù)。當(dāng) leader 和 zookeeper 失去連接時(shí)，臨時(shí)節(jié)點(diǎn)會(huì)刪除，而其他 broker 會(huì)監(jiān)聽該節(jié)點(diǎn)的變化，當(dāng)節(jié)點(diǎn)刪除時(shí)，其他 broker 會(huì)收到事件通知，重新發(fā)起 leader 選舉。

kafka 在所有 broker 中選出一個(gè) controller，所有 Partition 的 Leader 選舉都由 controller 決定。controller 會(huì)將 Leader 的改變直接通過 RPC 的方式（比 zookeeper queue 的方式有效）通知給需要為此作出響應(yīng)的 Broker。同時(shí) controller 也負(fù)責(zé)增刪 Topic 以及 Replica 的分配。

六.Raft 算法

1.Raft 算法基本原理

共識(shí)算法就是保證一個(gè)集群的多臺(tái)機(jī)器協(xié)同工作，在遇到請(qǐng)求時(shí)，數(shù)據(jù)能夠保持一致。即使遇到機(jī)器宕機(jī)，整個(gè)系統(tǒng)仍然能夠?qū)ν獗３址?wù)的可用性。

Raft 協(xié)議強(qiáng)依賴 Leader 節(jié)點(diǎn)來確保集群數(shù)據(jù)一致性。即 client 發(fā)送過來的數(shù)據(jù)均先到達(dá) Leader 節(jié)點(diǎn)，Leader 接收到數(shù)據(jù)后，先將數(shù)據(jù)標(biāo)記為 uncommitted 狀態(tài)，隨后 Leader 開始向所有 Follower 復(fù)制數(shù)據(jù)并等待響應(yīng)，在獲得集群中大于 N/2 個(gè) Follower 的已成功接收數(shù)據(jù)完畢的響應(yīng)后，Leader 將數(shù)據(jù)的狀態(tài)標(biāo)記為 committed，隨后向 client 發(fā)送數(shù)據(jù)已接收確認(rèn)，在向 client 發(fā)送出已數(shù)據(jù)接收后，再向所有 Follower 節(jié)點(diǎn)發(fā)送通知表明該數(shù)據(jù)狀態(tài)為 committed。

2.Raft 三個(gè)子問題

Raft 將共識(shí)問題分解三個(gè)子問題：

• Leader election 領(lǐng)導(dǎo)選舉：有且僅有一個(gè) leader 節(jié)點(diǎn)，如果 leader 宕機(jī)，通過選舉機(jī)制選出新的 leader；
• Log replication 日志復(fù)制：leader 從客戶端接收數(shù)據(jù)更新/刪除請(qǐng)求，然后日志復(fù)制到 follower 節(jié)點(diǎn)，從而保證集群數(shù)據(jù)的一致性；
• Safety 安全性：通過安全性原則來處理一些特殊 case，保證 Raft 算法的完備性；

3.Raft 算法核心流程

Raft 算法核心流程可以歸納為：

• 首先選出 leader，leader 節(jié)點(diǎn)負(fù)責(zé)接收外部的數(shù)據(jù)更新/刪除請(qǐng)求；
• 然后日志復(fù)制到其他 follower 節(jié)點(diǎn)，同時(shí)通過安全性的準(zhǔn)則來保證整個(gè)日志復(fù)制的一致性；
• 如果遇到 leader 故障，followers 會(huì)重新發(fā)起選舉出新的 leader；

4.raft 協(xié)議角色

• Leader: 處理所有客戶端交互，日志復(fù)制等，一般一次只有一個(gè) Leader.
• Follower: 類似選民，完全被動(dòng)
• Candidate（候選人）: 可以被選為一個(gè)新的領(lǐng)導(dǎo)人。

Leader 全權(quán)負(fù)責(zé)所有客戶端的請(qǐng)求，以及將數(shù)據(jù)同步到 Follower 中（同一時(shí)刻系統(tǒng)中只存在一個(gè) Leader）。

Follower 被動(dòng)響應(yīng)請(qǐng)求 RPC，從不主動(dòng)發(fā)起請(qǐng)求 RPC。

Candidate 由 Follower 向 Leader 轉(zhuǎn)換的中間狀態(tài)

5.領(lǐng)導(dǎo)選舉

集群中每個(gè)節(jié)點(diǎn)只能處于 Leader、Follower 和 Candidate 三種狀態(tài)的一種:

（1）follower 從節(jié)點(diǎn)：

• 節(jié)點(diǎn)默認(rèn)是 follower；
• 如果剛剛開始或和 leader 通信超時(shí)，follower 會(huì)發(fā)起選舉，變成 candidate，然后去競選 leader；
• 如果收到其他 candidate 的競選投票請(qǐng)求，按照先來先得 & 每個(gè)任期只能投票一次的投票原則投票;

（2）candidate 候選者：

• follower 發(fā)起選舉后就變?yōu)?candidate，會(huì)向其他節(jié)點(diǎn)拉選票。candidate 的票會(huì)投給自己，所以不會(huì)向其他節(jié)點(diǎn)投票；
• 如果獲得超過半數(shù)的投票，candidate 變成 leader，然后馬上和其他節(jié)點(diǎn)通信，表明自己的 leader 的地位；
• 如果選舉超時(shí)，重新發(fā)起選舉；
• 如果遇到更高任期 Term 的 leader 的通信請(qǐng)求，轉(zhuǎn)化為 follower；

（3）leader 主節(jié)點(diǎn)：

• 成為 leader 節(jié)點(diǎn)后，此時(shí)可以接受客戶端的數(shù)據(jù)請(qǐng)求，負(fù)責(zé)日志同步；
• 如果遇到更高任期 Term 的 candidate 的通信請(qǐng)求，這說明 candidate 正在競選 leader，此時(shí)之前任期的 leader 轉(zhuǎn)化為 follower，且完成投票；
• 如果遇到更高任期 Term 的 leader 的通信請(qǐng)求，這說明已經(jīng)選舉成功新的 leader，此時(shí)之前任期的 leader 轉(zhuǎn)化為 follower；

Raft 算法把時(shí)間軸劃分為不同任期 Term。每個(gè)任期 Term 都有自己的編號(hào) TermId，該編號(hào)全局唯一且單調(diào)遞增。如下圖，每個(gè)任務(wù)的開始都 Leader Election 領(lǐng)導(dǎo)選舉。如果選舉成功，則進(jìn)入維持任務(wù) Term 階段，此時(shí) leader 負(fù)責(zé)接收客戶端請(qǐng)求并，負(fù)責(zé)復(fù)制日志。Leader 和所有 follower 都保持通信，如果 follower 發(fā)現(xiàn)通信超時(shí)，TermId 遞增并發(fā)起新的選舉。如果選舉成功，則進(jìn)入新的任期。如果選舉失敗，TermId 遞增，然后重新發(fā)起選舉直到成功。

舉個(gè)例子，參考下圖，Term N 選舉成功，Term N+1 和 Term N+2 選舉失敗，Term N+3 重新選舉成功。

具體的說，Leader 在任期內(nèi)會(huì)周期性向其他 follower 節(jié)點(diǎn)發(fā)送心跳來維持地位。follower 如果發(fā)現(xiàn)心跳超時(shí)，就認(rèn)為 leader 節(jié)點(diǎn)宕機(jī)或不存在。隨機(jī)等待一定時(shí)間后，follower 會(huì)發(fā)起選舉，變成 candidate，然后去競選 leader。選舉結(jié)果有三種情況：

（1）獲取超過半數(shù)投票，贏得選舉：

• 當(dāng) Candidate 獲得超過半數(shù)的投票時(shí)，代表自己贏得了選舉，且轉(zhuǎn)化為 leader。此時(shí)，它會(huì)馬上向其他節(jié)點(diǎn)發(fā)送請(qǐng)求，從而確認(rèn)自己的 leader 地位，從而阻止新一輪的選舉；
• 投票原則**：當(dāng)多個(gè) Candidate 競選 Leader 時(shí)**
  • 一個(gè)任期內(nèi)，follower 只會(huì)投票一次票，且投票先來先得；
  • Candidate 存儲(chǔ)的日志至少要和 follower 一樣新（安全性準(zhǔn)則），否則拒絕投票；

（2）投票未超過半數(shù)，選舉失?。?/strong>

#部門表設(shè)計(jì)
CREATE TABLE `department` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL,
  `parent_id` int(11) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `remark` varchar(100) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `created_at` datetime DEFAULT NULL,
  `deleted` tinyint(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `department_parent_id_IDX` (`parent_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='部門';

//java代碼邏輯處理優(yōu)化
public DepartmentDTO findAll() {
    DepartmentDTO departmentDTO = new DepartmentDTO();
    departmentDTO.setId(0L);
    queryChildren(departmentDTO);
    return departmentDTO;
}

// 遞歸查詢
private void queryChildren(DepartmentDTO parent) {
    List<DepartmentPO> children = departmentDao.queryByParentId(parent.getId());
    if (CollectionUtils.isEmpty(children)) {
        return;
    }

    for (DepartmentPO po : children) {
        DepartmentDTO departmentDTO = new DepartmentDTO();
        BeanUtil.copyProperties(po, departmentDTO);
        parent.getChildren().add(departmentDTO);
        queryChildren(departmentDTO);
    }
}

private void queryChildren2(DepartmentDTO root) {
    // 一次性取出所有數(shù)據(jù)
    List<DepartmentPO> list = departmentDao.findAll(Sort.by("parentId", "id").ascending());
    Map<Long, DepartmentDTO> departmentMap = new HashMap<>();
    departmentMap.put(root.getId(), root);
    // 遍歷數(shù)據(jù)，組成樹形結(jié)構(gòu)
    for(DepartmentPO po : list) {
        DepartmentDTO departmentDTO = new DepartmentDTO();
        BeanUtil.copyProperties(po, departmentDTO);
        departmentMap.put(po.getId(), departmentDTO);
        DepartmentDTO parent = departmentMap.get(po.getParentId());
        parent.getChildren().add(departmentDTO);
    }
}

public DepartmentDTO findAll() {
    // 查詢緩存
    DepartmentDTO departmentDTO = (DepartmentDTO) redisTemplate.opsForValue().get(DEPARTMENT_CACHE_KEY);
    // 緩存不存在則查詢數(shù)據(jù)庫
    if (Objects.isNull(departmentDTO)) {
        departmentDTO = new DepartmentDTO();
        departmentDTO.setId(0L);
        queryChildren2(departmentDTO);
    }
    // 更新緩存
    redisTemplate.opsForValue().set(DEPARTMENT_CACHE_KEY, departmentDTO, 1, TimeUnit.MINUTES);

    return departmentDTO;
}

<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <version>3.1.2</version>
</dependency>

@Configuration
@EnableCaching
public class CacheConfig {

    @Bean
    public Caffeine<Object, Object> caffeineConfig() {
        return Caffeine.newBuilder()
                .expireAfterWrite(10, TimeUnit.MINUTES) // 設(shè)置緩存失效時(shí)間為10分鐘
                .maximumSize(10_000) // 設(shè)置緩存的最大容量為10_000
                .recordStats(); // 啟用統(tǒng)計(jì)信息，可通過Cache.stats()獲取緩存命中率等統(tǒng)計(jì)數(shù)據(jù)
    }

    @Bean
    public CacheManager cacheManager(Caffeine<Object, Object> caffeine) {
        CaffeineCacheManager cacheManager = new CaffeineCacheManager();
        cacheManager.setCaffeine(caffeine);
        return cacheManager;
    }
}

@Cacheable("department-cache")
public DepartmentDTO findAll() {
    // 省略其它代碼
}

http {
    gzip on;
    gzip_types text/plain text/css application/json;
    gzip_comp_level 5;
}

http {
    proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
}

server {
    location /api/department {
        proxy_cache my_cache;
        proxy_cache_valid 200 1d;
        proxy_pass http://backend_server;
    }
}

location /purge-cache {
    proxy_cache_purge my_cache "$scheme$request_method$host$request_uri";
}

public DepartmentDTO findAll() {
    DepartmentDTO root = new DepartmentDTO();
    root.setId(0L);
    // 從10個(gè)key里獲取緩存數(shù)據(jù)，放入到根節(jié)點(diǎn)的children集合里
    for (int i = 0; i< 10; i++) {
        DepartmentDTO child = (DepartmentDTO)  redisTemplate.opsForValue().get(DEPARTMENT_CACHE_KEY + i);
        // 沒有緩存數(shù)據(jù)
        if (Objects.isNull(child)) {
            root.setChildren(new ArrayList<>());
            break;
        }
        root.getChildren().add(child);
    }

    if (root.getChildren().size() == 0) {
       // 查詢數(shù)據(jù)庫
       queryChildren2(root);
    }

    // 將數(shù)據(jù)按照1級(jí)部門存儲(chǔ)到10個(gè)key
    List<DepartmentDTO> children = root.getChildren();
    for (int i = 0 ; i < 10; i++) {
        redisTemplate.opsForValue().set(DEPARTMENT_CACHE_KEY + i, children.get(i), 1, TimeUnit.HOURS);
    }
    return root;
}