# 阿爾及利亞分布式搜索網絡的體系結構 > 原文： [http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html](http://highscalability.com/blog/2015/3/9/the-architecture-of-algolias-distributed-search-network.html)  *[Julien Lemoine](https://www.linkedin.com/in/julienlemoine) 的共同發布者的 CTO [阿爾及利亞 ]](http://www.algolia.com/) ，開發人員友好的搜索即服務 API。* Algolia 于 2012 年作為移動設備的離線搜索引擎 SDK 開始。 目前，我們還不知道在兩年內我們將建立一個全球分布式搜索網絡。 如今，阿爾戈利亞每月在全球 12 個地區提供超過 20 億個用戶生成的查詢，我們的平均服務器響應時間為 6.7 毫秒，其中 90％的查詢在不到 15 毫秒內得到答復。 我們的搜索不可用率低于 10 ^-6 ，這表示每月少于 3 秒。 離線移動 SDK 面臨的挑戰是移動性質帶來的技術限制。 這些挑戰迫使我們在開發算法時會采取不同的思路，因為經典的服務器端方法無法正常工作。 從那時起，我們的產品有了很大的發展。 我們想分享我們在這些算法之上構建和擴展 REST API 的經驗。 **我們將說明我們如何使用分布式共識來實現全球不同地區的數據的高可用性和同步，以及如何通過任意播 DNS** 將查詢路由到最近的位置 。 # 數據大小誤解 在設計架構之前，我們首先必須確定我們需要支持的主要用例。 在考慮我們的擴展需求時尤其如此。 我們必須知道我們的客戶是否需要索引千兆字節，太字節或 PB 的數據。 架構會有所不同，具體取決于我們需要處理多少個用例。 當人們想到搜索時，大多數人會想到非常大的用例，例如 Google 的網頁索引或 Facebook 的數萬億帖子索引。 如果停下來想一想每天看到的搜索框，則大多數搜索框都不會搜索大型數據集。 **Netflix 搜索約 10,000 種圖書，亞馬遜在美國的數據庫包含約 200,000,000 種產品。 這兩種情況下的數據都可以存儲在單臺機器** **中！** 我們并不是說擁有一臺計算機是一個很好的設置，但是要記住所有數據都可以在一臺計算機上存儲是非常重要的，因為跨計算機同步是復雜性和性能損失的主要來源。 # 高可用性之路 構建 SaaS API 時，高可用性是一個大問題，因為消除所有單點故障（SPOF）極具挑戰性。 我們花了數周的時間為我們的服務集體討論理想的搜索架構，同時牢記我們的產品將面向面向用戶的搜索。 ## 主從與主從 通過將問題暫時限制為存儲在單個計算機上的每個索引，我們將高可用性設置簡化為托管在不同數據中心的多臺計算機。 通過這種設置，我們想到的第一個解決方案是進行主從設置，其中一臺主機接收所有索引操作，然后將它們復制到一個或多個從機。 使用這種方法，我們可以輕松地在所有計算機之間負載均衡搜索查詢。 這種主從方法的問題在于我們的高可用性僅適用于搜索查詢。 所有索引操作都需要轉到主服務器。 對于服務公司來說，這種架構風險太大。 要做的只是使主服務器停機，這將發生，并且客戶端將開始出現索引錯誤。 **我們必須實現主-主架構** **！** 啟用主-主設置的關鍵要素是要在一組機器之間就單個結果達成一致。 我們需要在所有機器之間共享**知識，這些知識在所有情況下**都保持一致，即使機器之間存在網絡分離。 ## 引入分布式一致性 對于搜索引擎，引入此共享知識的最佳方法之一是**將寫入操作視為必須按特定順序應用的唯一操作流**。 當我們有多個操作恰好同時出現時，我們需要為其分配一個序列 ID。 然后，可以使用該 ID 來確保將序列完全相同地應用于所有副本。 為了分配序列 ID（每個作業后一個數字遞增 1），我們需要在機器之間的下一個序列 ID 上具有共享的全局狀態。 [ZooKeeper](http://zookeeper.apache.org/) 開源軟件是針對集群中分布式知識的實際解決方案，我們最初開始按以下順序使用 ZooKeeper： 1. 當機器收到作業時，它將使用臨時名稱將作業復制到所有副本。 2. 然后，該機器將獲得分布式鎖。 3. 讀取 ZooKeeper 中的最后一個序列 ID，并發送命令以在所有機器上將臨時文件復制為序列 ID + 1。 這等效于兩階段提交。 4. 如果我們從計算機（定額）中獲得大多數肯定答案，則將序列 ID +1 保存在 Zookeeper 中。 5. 然后釋放分布式鎖。 6. 最后，將結果通知發送作業的客戶端。 如果有大多數提交，這將是成功的。 不幸的是，此順序不正確，因為如果獲取鎖的機器在步驟 3 和 4 之間崩潰或重新啟動，我們可能會以作業在某些機器上提交的狀態結束，這需要更復雜的順序。 ZooKeeper 通過 TCP 連接作為外部服務打包非常困難，并且需要使用較大的超時（默認超時設置為 4 秒，表示兩個滴答聲，每個滴答聲為 2 秒）。 因此，無論是硬件還是軟件，每個失敗事件都將在此超時時間內凍結整個系統。 這似乎是可以接受的，但在我們的案例中，我們想經常在生產中測試故障（例如 Netflix 的 Monkey 測試方法）。 ## 木筏共識算法 大約在我們遇到這些問題的時候， [RAFT 共識算法](https://raftconsensus.github.io/) 已發布。 顯然，該算法非常適合我們的用例。 RAFT 的狀態機是我們的索引，日志是要執行的索引作業的列表。 我已經知道 PAXOS 協議，但是對它以及所有變體的理解不夠深刻，不足以使我自己有信心實施它。 另一方面，RAFT 更清晰。 如果可以完美地滿足我們的需求，即使當時沒有穩定的開源實現，我也有足夠的信心將其實現為我們架構的基礎。 實現共識算法最困難的部分是確保系統中沒有錯誤。 為了解決這個問題，我選擇了一種猴子測試方法，即在重新啟動之前使用睡眠方式隨機殺死進程。 為了進一步測試，我模擬了通過防火墻的網絡掉線和性能下降。 這種測試有助于我們發現許多錯誤。 一旦我們運行了幾天，沒有任何問題，我非常有信心實施正確。 ## 在應用程序或文件系統級別復制嗎？ 我們選擇將寫操作分配給所有計算機并在本地執行，而不是在文件系統上復制最終結果。 我們做出此選擇的原因有兩個： * 更快。 索引在所有計算機上并行完成，比復制可能很大的二進制文件要快 * 它與多個區域兼容。 如果我們在建立索引后復制文件，則需要一個將重寫整個索引的過程。 這意味著我們可能要傳輸大量數據。 如果您需要將數據傳輸到世界各地（例如紐約到新加坡），則傳輸的數據量非常低。 每臺機器將以正確的順序接收所有寫操作作業，并獨立于其他機器盡快處理它們。 **這意味著確保所有機器處于相同狀態，但不必同時處于同一狀態** 。 這是因為更改可能不會在同一時間在所有計算機上提交。 ## 一致性的妥協 在分布式計算中， [CAP 定理](http://en.wikipedia.org/wiki/CAP_theorem) 指出，分布式計算系統不可能同時提供以下三個功能： * 一致性：所有節點同時看到相同的數據。 * 可用性：確保每個請求都收到有關成功還是失敗的響應。 * 分區容限：盡管任意消息丟失或系統部分出現故障，系統仍可繼續運行。 根據該定理，我們在一致性 上折衷了 **。 我們不保證所有節點都能在同一時間看到完全相同的數據，但是它們都將收到更新。 換句話說，在少數情況下，機器不同步。 實際上，這不是問題，因為當客戶執行寫操作時，我們將該作業應用于所有主機。** **在第一臺機器和最后一臺機器上的應用時間之間相距不到一秒鐘，因此最終用戶通常看不到它。 唯一可能的矛盾是上一次收到的更新是否已經應用，這與我們客戶的用例兼容。** # 通用體系結構 ## 集群的定義 為了擁有高可用性基礎結構，必須在機器之間擁有分布式共識，但是遺憾的是存在很大的缺陷。 **此共識需要機器** **之間進行多次往返，因此每秒可能達成共識的數量與不同機器**之間的延遲直接相關。 他們需要接近才能每秒獲得大量共識。 為了能夠支持多個區域而不犧牲可能的寫入操作的數量，這意味著我們需要有多個集群，每個集群將包含三臺充當完美副本的機器。 每個區域只有一個集群是達成共識所需的最低要求，但仍遠非完美： * 我們無法使所有客戶都適合一臺機器。 * 我們擁有的客戶越多，每個唯一客戶每秒可以執行的寫操作數量就越少。 這是因為每秒的最大共識數是固定的。 為了解決此問題，我們決定在區域級別應用相同的概念： **每個區域將具有由三個計算機組成的幾個群集** 。 一個集群可以容納一個到幾個客戶，具體取決于他們擁有的數據大小。 這個概念與虛擬化在物理機上所做的事情很接近。 我們能夠將幾個客戶放在一個集群上，但一個客戶可以動態增長并更改其使用情況。 為此，我們需要開發和自動化以下過程： * 如果群集中的數據太多或寫入操作數量過多，則將其遷移到另一群集。 * 如果查詢量太大，則將新計算機添加到群集。 * 如果數據量太大，則更改分片的數量或將一個客戶分散在多個群集中。 如果我們擁有這些流程，則不會將客戶永久分配給集群。 分配將根據其自身的使用以及集群的使用而變化。 這意味著我們需要一種將客戶分配給集群的方法。 ## 將客戶分配給集群 管理此分配的標準方法是每個客戶擁有一個唯一的 DNS 條目。 這類似于 Amazon Cloudfront 的工作方式。 每個客戶都被分配一個格式為 customerID.cloudfront.net 的唯一 DNS 條目，然后可以根據該客戶針對不同的計算機集。 我們選擇了相同的方法。 **為每個客戶分配一個唯一的應用程序 ID，該 ID 鏈接到格式為 APPID.algolia.io 的 DNS 記錄**。 該 DNS 記錄以特定群集為目標，該群集中的所有計算機都是 DNS 記錄的一部分，因此可以通過 DNS 進行負載平衡。 我們還使用運行狀況檢查機制來檢測計算機故障，并將其從 DNS 解析中刪除。 即使 DNS 記錄上的 TTL 值非常低（TTL 是允許客戶端保留 DNS 答復的時間），運行狀況檢查機制仍不足以提供良好的 SLA。 問題在于主機可能會關閉，但用戶仍將主機保留在緩存中。 用戶將繼續向其發送查詢，直到緩存過期。 更糟糕的是，因為 TTL 并不是一門精確的科學。 在某些情況下，系統不遵守 TTL。 我們已經看到一些 DNS 服務器將一分鐘 TTL 轉換為 30 分鐘 TTL 的 DNS 記錄。 為了進一步提高高可用性并避免機器故障影響用戶，我們為每個客戶生成了另一組 DNS 記錄，格式為 APPID-1.algolia.io，APPID-2.algolia.io 和 APPID- 3.algolia.io。 這些 DNS 記錄的思想是允許我們的 API 客戶端在達到 TCP 連接超時（通常設置為一秒）時重試其他記錄。 我們的標準實現是對 DNS 記錄列表進行混洗，并按順序嘗試它們。 與我們的 API 客戶端中精心控制的重試和超時邏輯相結合，這被證明是比使用專門的負載平衡器更好，更便宜的解決方案。 后來，我們發現時髦的.IO TLD 并不是性能的理想選擇。 與.NET 相比，.IO 的任意播網絡中的 DNS 服務器更少，并且那里的服務器已經飽和。 這導致大量超時，從而減慢了名稱解析的速度。 此后，我們通過切換到 algolia.net 域解決了這些性能問題，同時通過繼續支持 algolia.io 來保持向后兼容性。 # 集群的可伸縮性如何？ 我們選擇使用多個集群使我們能夠添加更多客戶，而不會因為集群之間的隔離而對現有客戶造成太大的風險。 但是我們仍然擔心需要解決的一個集群的可伸縮性。 群集可伸縮性中的第一個限制因素是由于共識而導致的每秒寫入操作數。 為了緩解這一因素，我們從共識的角度出發，在 API 中引入了批處理方法，該方法將一組寫操作封裝在一個操作中。 問題在于，某些客戶仍然不分批地執行寫操作，這可能會對群集的其他客戶的索引速度產生負面影響。 為了減少對性能的影響，我們對體系結構進行了兩項更改： * 我們從共識的角度出發，通過在一個唯一的操作中自動聚合每個客戶的所有寫操作，從而在共識存在爭議時添加了批處理策略。 在實踐中，這意味著我們正在重新排列作業的順序，但不影響操作的語義。 例如，如果有 1,000 個待達成共識的作業，而 990 個來自一個客戶，則即使有其他客戶的作業交錯在一起，我們也會將 990 個寫入操作合并為一個。 * 我們添加了一個共識調度程序，該調度程序控制每秒為每個應用程序 ID 輸入共識的寫入操作數。 這避免了一個客戶能夠使用共識的所有帶寬。 在實施這些改進之前，**我們通過返回 429 HTTP 狀態代碼**嘗試了限速策略。 很快就很明顯，這對于我們的客戶來說太痛苦了，以至于不得不等待這種響應并實施重試策略。 如今，我們最大的客戶每天在三臺計算機的單個群集上執行超過 10 億次寫操作，平均每秒執行 11,500 次操作，突發次數超過 15 萬次。 第二個問題是找到最佳的硬件設置，并避免可能影響群集可伸縮性的任何潛在瓶頸（例如 CPU 或 I / O）。 從一開始，我們就選擇使用自己的裸機服務器，以完全控制我們的服務性能并避免浪費任何資源。 選擇正確的硬件被證明是一項艱巨的任務。 在 2012 年底，我們從一個小型設置開始，包括：Intel Xeon E3 1245v2、2 個 Intel RAID 320 系列，RAID 0 中的 120GB 和 32GB RAM。 該硬件價格合理，比云平臺更強大，使我們能夠在歐洲和美國東部啟動該服務。 此設置使我們能夠調整內核的 I / O 調度和虛擬內存，這對于我們利用所有可用的物理資源至關重要。 即使這樣，我們很快發現我們的限制是 RAM 和 I / O 的數量。 我們使用了大約 10GB 的 RAM 來建立索引，而僅剩下 20GB 的 RAM 用于緩存用于執行搜索查詢的文件。 我們的目標一直是在內存中存儲客戶索引，以便針對毫秒級的響應時間優化服務。 當前的硬件設置是為 20GB 的索引數據而設計的，該數據太小了。 首次設置后，我們嘗試了具有單插槽和雙插槽 CPU，128GB 和 256GB RAM 以及不同型號/大小的 SSD 的不同硬件機器。 我們終于找到了一臺包含 Intel Xeon E5 1650v2、128GB RAM 和 2x400GB Intel S3700 SSD 的機器的最佳設置。 SSD 的型號對于耐用性非常重要。 在找到可以在生產中使用多年的正確型號之前，我們燒掉了許多 SSD。 最后，我們構建的最終體系結構使我們僅需一個條件即可在所有領域進行良好的擴展：我們需要隨時擁有免費資源。 在 2015 年，要處理必須管理裸機服務器的痛苦似乎有些瘋狂，但是我們在為客戶提供的服務質量和價格方面所獲得的收益是值得的。 我們能夠提供一個完全打包的搜索引擎，該引擎可以復制到三個不同的位置（在內存索引中），并且在比 AWS 更高的位置上具有出色的性能！ # 操作復雜嗎？ ## 限制進程數 **每臺機器僅包含三個進程** 。 第一個是 Nginx 服務器，其中所有查詢解釋代碼均作為模塊嵌入其中。 為了回答查詢，我們在內存中映射了索引文件并直接在 nginx worker 中執行查詢，而無需與其他進程或機器進行通信。 唯一的例外是，當客戶數據不適合一臺機器時，這種情況很少發生。 第二個過程是 Redis 鍵/值存儲，我們使用它來檢查速率和限制以及存儲每個應用程序 ID 的實時日志和計數器。 這些計數器用于構建我們的實時信息中心，當您連接到帳戶時可以查看。 這對于可視化您的最后一個 API 調用和調試很有用。 最后一個過程是構建器。 這是負責處理所有寫入操作的過程。 當 nginx 進程接收到寫操作時，它將操作轉發給構建器以執行共識。 它還負責構建索引，并包含許多監視代碼，用于檢查我們的服務中的錯誤，例如崩潰，索引編制緩慢，索引編制錯誤等。根據問題的嚴重性，SMS 通過 Twilio 的 API 報告某些錯誤 而其他則直接報告給 PagerDuty。 每次在生產中檢測到新問題且未報告時，我們確保將來添加一個新探針以監視此類錯誤。 ## 易于部署 **此堆棧的簡單性使部署變得容易** 。 在部署任何代碼之前，我們應用一堆單元測試和非回歸測試。 一旦所有這些測試通過，我們便逐漸部署到集群。 我們的部署永遠不會影響生產，也不會對最終用戶可見。 同時，我們還希望以協商一致的方式產生主機故障，以便檢查一切是否按預期進行。 為了實現這兩個目標，我們獨立部署群集的每臺計算機，并應用以下過程： 1. 獲取新的 Nginx 和生成器二進制文件。 2. [正常重啟 nginx](http://nginx.org/en/docs/control.html#upgrade) Web 服務器，并使用新的二進制文件重新啟動 nginx，而不會丟失任何用戶查詢。 3. 殺死構建器并使用新的二進制文件將其啟動。 這會觸發每臺計算機部署 RAFT 失敗，從而使我們能夠確保故障轉移按預期進行。 操作系統的簡單性是我們體系結構的重要目標。 我們既不希望也不相信部署應該受到體系結構的限制。 ## 實現良好的全球覆蓋范圍 服務正在變得越來越全球化。 僅在全球一個地區提供搜索查詢遠非最佳。 例如，在美國東部地區托管搜索將在可用性方面有很大不同，具體取決于用戶從何處進行搜索。 對于美國東部用戶來說，延遲時間將從幾毫秒到亞洲用戶的數百毫秒，這還不包括飽和的海外光纖的帶寬限制。 我們已經看到一些公司在搜索引擎之上使用 CDN 來解決這些問題。 最終，這給我們帶來了比價值更大的問題，因為使緩存無效是一場噩夢，并且僅提高了很少一部分頻繁執行的查詢的速度。 我們很清楚，為了解決這個問題，我們需要將索引復制到不同的區域，并將它們加載到內存中，以便有效地回答用戶查詢。 我們需要的是在現有群集復制之上的 **區域間復制** 。 副本可以存儲在一臺機器上，因為該副本僅用于搜索查詢。 所有寫操作仍將轉到客戶的原始群集。 **每個客戶都可以選擇他們希望擁有的一組數據中心** 作為復制對象，因此特定區域中的復制計算機可以從多個群集中接收數據，并且一個群集可以 將數據發送到多個副本。 此架構的實現是基于我們基于共識的操作流建模的。 在達成共識之后，每個集群都將其自己的寫操作流轉換為每個副本的版本，以確保用無操作作業替換與此副本無關的作業。 然后，此操作流作為一批操作發送到所有副本，以避免盡可能多的延遲。 一次發送作業將導致重復的往返次數過多。 在群集上，寫操作將保留在計算機上，直到所有復制對其進行確認為止。 DSN 的最后一部分是將最終用戶直接重定向到最近的位置。 為此，我們以 APPID-dsn.algolia.net 的形式添加了另一個 DNS 記錄，該記錄負責解決最接近的數據中心的問題。 我們首先使用了 Amazon 的 Route53 DNS 服務，但很快達到了極限。 * 基于延遲的路由僅限于 AWS 區域，并且我們有印度，香港，加拿大和俄羅斯等 AWS 未覆蓋的位置。 * 基于地理位置的路由非常糟糕。 您需要為每個國家/地區指定 DNS 解析度。 這是許多托管 DNS 提供商所采用的經典方法，但是對于我們而言，這將是一個噩夢，無法提供足夠的相關性。 例如，我們在美國有幾個數據中心。 經過大量基準測試和討論，出于以下幾個原因，我們決定使用 [NSOne](http://www.nsone.net) 。 * 對我們來說，他們的 Anycast 網絡非常出色，并且比 AWS 更好的平衡。 例如，他們在印度和非洲擁有 POP。 * 他們的濾波器邏輯非常好。 對于每個客戶，我們可以指定與其關聯的機器（包括復制機器）列表，并使用地理位置過濾器按距離對它們進行排序。 這樣我們就可以保持最好的狀態。 * 它們支持 EDNS 客戶端子網。 這對我們來說很重要，以便更具針對性。 我們使用最終用戶的 IP 而不是其 DNS 服務器的 IP 進行解析。 在性能方面，我們已經能夠在第二級達到全球范圍內的全球同步。 您可以在 [Product Hunt 的搜索](http://www.producthunt.com/) （托管在美國東部，美國西部，印度，澳大利亞和歐洲）或 [Hacker News 上進行嘗試。 搜索](https://hn.algolia.com/) （托管在美國東部，美國西部，印度和歐洲）。 ## 結論 我們花費了大量時間來構建我們的分布式和可伸縮體系結構，并且遇到了許多不同的問題。 我希望本文能使您更??好地了解我們如何解決這些問題，并提供有關如何設計自己的服務的有用指南。 我看到越來越多的服務目前正面臨著與我們類似的問題，全世界的受眾都擁有多區域的基礎架構，但是卻擁有一些全球一致的信息，例如登錄名或內容。 為了獲得出色的用戶體驗，如今必須擁有多區域基礎架構。 例如，可以使用這種方法來分發在全球范圍內一致的只讀數據庫副本！ 如果您有任何問題或意見，我將很樂意回答。 [在 HackerNews 上](https://news.ycombinator.com/item?id=11185713) FWIW，Raft 和 Paxos 之間的主要區別在于，如果在故障轉移期間發生寫操作，則 Raft 保證數據丟失。 Paxos 直接將寫入與主選舉過程聯系在一起，以使寫入不會丟失。 兩者還可以在部分網絡故障的情況下鎖定到位； 根據具體實施情況，Raft 傾向于留在那里并接受數據一段時間。 因此，盡管 Raft 更簡單/更輕松，但這是因為它使您能夠以非常糟糕的方式破壞 Paxos 明智地處理的事情。 這篇文章將來會發表。 可能弄亂了一些提要閱讀器。 您是否考慮過使用 Kafka 在集群中實現“狀態機”復制？ 我是作者，并回復評論： 以色列：RAFT 和 Paxos 的保證是相同的：當共識成功時，就可以保證沒有數據丟失。 您能否詳細說明為什么您認為并非如此？ 凱恩：由于多個地區的部署，卡夫卡不是一個選擇。 我們需要對復制的序列 ID 分配進行更底層的控制 您在搜索引擎中使用什么技術？ @Jeyendran 如簡介中所述，這是我們自己的引擎，以低級 C ++開發，并作為模塊嵌入在 nginx 中。 由于以下幾個原因，我們不是基于像 lucene / sphinx 這樣的開源引擎： -我們處理關聯性的方式非常不同，這意味著對現有引擎 進行了巨大的重構-在即時搜索中具有非常好的性能 用例（鍵入時進行搜索），我們具有不同的數據結構。 我將嘗試寫一篇博客文章來解釋我們所有的算法/數據結構差異 可能是我讀過的最好的文章！ 我很高興看到其他人考慮了“三個進程”機制，并在 nginx 和其他進程之間使用了 mmap 文件。 和強大的）集群技術。 謝謝您的出色工作。 您提到過，在使用 RAFT 協議的一致性上存在折衷。 根據我的理解，RAFT 并沒有給出分區容限，因為每個狀態機都需要互相交談以復制狀態。 因此，這是 CAP 定理的 CA 系統，在這里我們可以最終保持一致。 我喜歡你的文章。 感謝分享 ：）） 嗯，是的，Raft 和 Paxos 都提供了類似的一致性保證。 甚至還有自動的正確性證明：https://github.com/uwplse/verdi/pull/16 該帖子說他們使用 Raft 來協調故障轉移，并且分別決定損害一致性，而不是他們使用 Raft 損害了的一致性*。 您可以維護有關某些事物（例如，當前哪個節點是主節點）的始終一致的信息，而不能維護其他事物（例如，您正在服務的索引的實際內容）。* 也許 Raft 不一致的想法來自對 https://aphyr.com/posts/316-jepsen-etcd-and-consul 的誤解，（正確地）它說 Raft 的兩個廣泛使用的實現缺少了使 讀取速度較慢，但??有必要避免以下情況：1）您在分區的少數一方 2）先前的主機太 3）選出新的主機，并且有人在第一秒內向其中寫入新數據，或者 因此，4）您在寫完之后閱讀。 兩種系統最終都提供了沒有異常的模式，這是由于 Raft 的實現不完整所致，而不是 Raft 本身的缺陷。 非常感謝您的帖子。 我學到了很多。