所以，首先，对不起我的英语。我不是母语人士。
问题是.. 我已经使用 Thrift 实现了一个带有分布式数据（3 个服务器）的 Cliente-Server 应用程序。现在（项目的最后阶段）是使用 Raft 的一些实现（因为我使用 Java，一个选项是模仿）来复制每个服务器。但是 Thrift 以他的方式创建服务器和客户端（类似于 Grafosd.Client 客户端 = new ...），而 Grafosd 是由 Thrift 生成的。此外，Thrift 将数据存储在 Handler? 中。并且 copycat 以不同的方式创建服务器和客户端（类似于 CopycatClient client = builder.build();）。并且数据存储在 StateMachine? 中。
所以我很难将两者结合起来。有人已经使用 Thrift Client-Server 和 Raft 协议的一些实现了吗？（不一定是山寨，可以是 Java 中 Raft 的任何实现）。
首先你要问自己为什么你的项目的第二阶段要使用共识算法？项目是否需要强一致性？您是否考虑过替代复制协议（八卦、主备份等）
无论您使用哪种 Raft 实现，大多数实现在系统内建模状态的方式都是作为状态机。对系统状态的更改必须通过 Raft 协议传递给领导者并复制到跟随者，并且如果要保持一致性/容错保证，对系统状态的查询也必须通过协议。
如果您想在服务器中嵌入 Copycat，只需使用LocalTransport允许您与进程内服务器通信的 which。CopycatServer不必在远程机器上运行。在 Thrift 服务器中嵌入 Copycat 客户端和服务器是完全现实和合理的。在您的 Thrift 服务器中，创建一个CopycatServer包含可以表示系统状态更改的状态机，以及一个CopycatClient使用 aLocalTransport与本地服务器通信的 a。
您也可以考虑使用 Atomix 来AtomixReplica为您处理本地客户端/服务器嵌入模式。它还包括大量的示例状态机和客户端 API。
但正如我所说，无论您使用 Copycat/Atomix 还是其他 Raft 实现，您仍然必须以相同的方式对状态更改进行建模。对系统状态的每次更改都必须提交给 Raft 领导者，在那里它被记录并复制到追随者并应用于状态机。状态机复制模型非常适合有状态系统。存储大量状态或需要将状态存储在外部数据库中的系统的替代方案是持久状态机。我发现这是许多用户在 Raft 中寻找的东西。但是您必须小心在 Raft 集群中如何实现持久状态机，否则您将面临重复写入的风险。
不过，您应该首先确定是否需要像 Raft 这样的复杂协议来解决您要解决的问题。首先回答这个问题是什么，以及它对复制协议的要求。你需要分区容错吗？你需要强一致性吗？您需要高可用性吗？吞吐量要求是否排除使用基于领导者的协议？为什么不直接写入任何已复制的外部数据库？
我是 Copycat 和 Atomix 的作者。当您回答其中一些问题并确定这是否确实是正确的方向时，请随时加入我们的聊天。
从我这边对你的问题的一些更一般的评论：
但是 Thrift 以他的方式创建服务器和客户端（类似于 Grafosd.Client 客户端 = new ...），而 Grafosd 是由 Thrift 生成的。
Thrift 本身（仅）是使用的序列化和 RPC 机制。更复杂的协议或 API 通常设计在 Thrift 之上，使用 Thrift - 但不在 Thrift 内部。这就像使用汽车将材料运送到建筑工地。决定架构的不是汽车。汽车只是完成工作的工具。
在这方面，Thrift（或任何其他类似机制）只是这种情况下的一种工具。我建议首先在头脑中弄清楚，哪一块拼图属于从你的系统设计中获得最佳效果的地方。
另外，Thrift 将数据存储在 Handler 中？
我建议始终使处理程序无状态。如果您需要一个状态，那很好，但将其存储在其他地方。Thrift 本身什么也不存储。处理程序实现掌握在服务器端开发人员的手中，可能需要存储状态或其他信息。