因此，首先，對我的英語感到抱歉。我不是以英語爲母語的人。集成分佈式數據系統（客戶端，服務器）的節儉實現與Raft協議
問題是，我已經有一個使用Thrift的分佈式數據（3臺服務器）的Cliente-Server應用程序的實現。現在（項目的最後一個階段）是使用Raft的一些實現（如使用Java的Im，選項是複製）來複制每個服務器。但是Thrift以他的方式創建服務器和客戶端（類似於Grafosd.Client客戶端= new ...），而Grafosd則由Thrift生成。另外，Thrift將數據存儲在處理程序中？並且copycat以不同的方式創建服務器和客戶端（類似於CopycatClient client = builder.build（）;）。並且數據存儲在StateMachine？中。
所以我很難整合兩者。有人已經使用Thrift Client-Server和一些Raft協議的實現？ （不需要模仿，它可以是Java中Raft的任何實現）。
首先你必須問自己，爲什麼你的項目的第二階段使用一致性算法？該項目是否需要很強的一致性？你有沒有考慮替代複製協議（八卦，主備份等）
無論哪個筏實施使用，系統內的道路大部分實現模型狀態是一個狀態機。系統狀態的變化必須通過Raft協議傳達給領導者，並複製給追隨者，如果要保持一致性/容錯能力保證，則系統狀態查詢也必須通過協議。
如果你想在服務器中嵌入山寨，只是用一個LocalTransport，讓您與進程服務器進行通信。 CopycatServer不必在遠程機器上運行。在Thrift服務器中嵌入Copycat客戶端和服務器是非常現實和合理的。在您的Thrift服務器中，創建一個CopycatServer，其中包含可代表系統狀態更改的狀態機，以及使用LocalTransport與本地服務器通信的CopycatClient。
您也可以考慮考慮使用ATOMIX其中AtomixReplica處理這個本地客戶機/服務器爲你嵌入圖案。它還包括大量示例狀態機和客戶端API。
但正如我所說的，無論您是使用Copycat/Atomix還是其他Raft實現，您仍然必須以相同的方式爲狀態更改建模。系統狀態的每次更改都必須提交給Raft領導者，並在其中記錄並複製到關注者並應用到狀態機。狀態機複製模型非常適合有狀態系統。存儲大量狀態或需要將狀態存儲在外部數據庫中的系統的替代方案是持久狀態機。我發現這是許多用戶在Raft中尋找的東西。但是你必須小心在Raft集羣中如何實現持久狀態機，否則你將冒着複製寫入的風險。
不過，您應該首先確定一個複雜的協議，如Raft對於您嘗試解決的問題是否必要。首先回答這個問題是什麼，以及它從複製協議中需要什麼。你需要分區容忍嗎？你需要很強的一致性嗎？你需要高可用性嗎？吞吐量要求是否排除使用基於領導者的協議？爲什麼不直接寫入任何複製的外部數據庫？
我是Copycat和Atomix的作者。當您回答其中一些問題並確定這是否確實是正確的方向時，請隨時加入我們的聊天室。
從我的身邊你的問題有些更普遍的評論：
但節儉創造了他的去路服務器和cliente（喜歡的東西Grafosd.Client客戶端=新...）和Grafosd由節儉產生。
Thrift本身（僅）是使用的序列化和RPC機制。更復雜的協議或API通常被設計節儉的頂部，使用節儉 - 但不是裏面節儉。這就像使用汽車將材料運輸到建築工地一樣。決定架構的不是汽車。汽車只是完成工作的手段。
在這方面，節儉（或任何其它類似機構）是隻在這方面的一個工具。我會建議先使其精神上清楚，這一塊拼圖屬於哪裏得到最佳的出你的系統的設計。
而且，舊貨店在處理程序中的數據？
我建議總是讓處理程序無狀態。如果你需要一個國家，這很好，但將它存儲在別的地方。節儉本身不存儲任何東西。這是處理器的實現，掌握在服務器端開發人員手中，可能需要存儲狀態或其他信息。
謝謝kuujo！ –